Opened 17 years ago
Closed 17 years ago
#5640 closed (fixed)
Request to improve error handling in utils.encoding.force_unicode.
Reported by: | Owned by: | Malcolm Tredinnick | |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Keywords: | unicode, force_unicode, UnicodeDecodeError | |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
migrating a large django project to trunk version > 5609 (i.e. after Unicode branch was merged) can be very painful due to a bug(?!) in utils.encoding.force_unicode
basically, following the instructions here http://code.djangoproject.com/wiki/UnicodeBranch#PortingApplicationsTheQuickChecklist is the right thing to do, but it is very difficult in a larger project to catch all the strings that might need and u''
before them.
Make the slightest oversight, and you lose the ability to debug your models/views/templates as utils.encoding.force_unicode will throw an UnicodeDecodeError exception like this one:
MOD_PYTHON ERROR ProcessId: 9493 Interpreter: 'mcc' ServerName: 'legolas.svt.se' DocumentRoot: '/Library/WebServer/Documents' URI: '/kluster/errors/' Location: '/kluster' Directory: None Filename: '/Library/WebServer/Documents/kluster' PathInfo: '/errors/' Phase: 'PythonHandler' Handler: 'django.core.handlers.modpython' Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch default=default_handler, arg=req, silent=hlist.silent) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/mod_python/importer.py", line 1229, in _process_target result = _execute_target(config, req, object, arg) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/mod_python/importer.py", line 1128, in _execute_target result = object(arg) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/handlers/modpython.py", line 178, in handler return ModPythonHandler()(req) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/handlers/modpython.py", line 151, in __call__ response = self.get_response(request) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/handlers/base.py", line 53, in get_response response = self._real_get_response(request) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/handlers/base.py", line 115, in _real_get_response return debug.technical_500_response(request, *sys.exc_info()) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/views/debug.py", line 151, in technical_500_response return HttpResponseServerError(t.render(c), mimetype='text/html') File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", line 176, in render return self.nodelist.render(context) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", line 732, in render bits.append(self.render_node(node, context)) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", line 745, in render_node return node.render(context) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/defaulttags.py", line 135, in render nodelist.append(node.render(context)) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/defaulttags.py", line 229, in render return self.nodelist_true.render(context) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", line 732, in render bits.append(self.render_node(node, context)) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", line 745, in render_node return node.render(context) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/defaulttags.py", line 135, in render nodelist.append(node.render(context)) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", line 781, in render return self.filter_expression.resolve(context) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", line 599, in resolve obj = func(obj, *arg_vals) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/defaultfilters.py", line 25, in _dec args[0] = force_unicode(args[0]) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/utils/encoding.py", line 41, in force_unicode s = unicode(s, encoding, errors) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 3679-3681: invalid data
from this traceback, it is very difficult for laymen (like me) to figure out what is wrong and trace the cause of the error (in my case: a non-ascii string in settings.py that didn't have a u in front of it). This severly hampers the migration of larger projects to django trunk post r5609.
My patch just catches the exception in force_unicode and enforces unicode conversion with the 'ignore' flag. This is certainly not the optimal solution, but at least it allows for debugging models/views/templates!
Attachments (1)
Change History (3)
by , 17 years ago
Attachment: | force_unicode.diff added |
---|
comment:1 by , 17 years ago
Description: | modified (diff) |
---|---|
Has patch: | unset |
Owner: | changed from | to
Summary: | utils.encoding.force_unicode should never throw UnicodeDecodeError → Request to improve error handling in utils.encoding.force_unicode. |
Triage Stage: | Unreviewed → Design decision needed |
Hiding genuine errors is not the solution here, so this patch can't go in. Porting an application is a one-time job, so I'm reluctant to even add a setting for this.
The solution is probably to write your own version of force_unicode and assign that to encoding.force_unicode during your porting phase. We might be able to make the error a bit more self-helpful, though.
Changing the title to reflect the real issue, since force_unicode should raise UnicodeDecodeError when there's a problem. That's not a bug; the data it's being given is invalid.
comment:2 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
patch for utils.encoding.force_unicode