-
Notifications
You must be signed in to change notification settings - Fork 1.1k
UnicodeEncodeError: 'ascii' codec can't encode characters in position #67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I thinks that these errors are quite similiar(in fact 2 of them are the same error to me): http://github.com/robhudson/django-debug-toolbar/issues#issue/43 All is about inproper handling non-ascii symbols. I also had problem with rosetta, but this worked for me:
Only changes I made was adding unicode(), so all objects are converted to unicode strings, not to ascii string(str()) is default used here(as i understand docs). Here the problem is with characters from POST data (translated strings :) ) |
I do not know if this is proper solution, but if not it may help you finding problem. |
Interesting stuff. I still don't really understand what could be wrong with the way that debug-toolbar is written right now. http://docs.djangoproject.com/en/dev/ref/unicode/#form-submission "Django adopts a "lazy" approach to decoding form data. The data in an HttpRequest object is only decoded when you access it. In fact, most of the data is not decoded at all. Only the HttpRequest.GET and HttpRequest.POST data structures have any decoding applied to them. Those two fields will return their members as Unicode data. All other attributes and methods of HttpRequest return data exactly as it was submitted by the client." It's crashing on render_to_string shortcut called with the request_vars.html template. It is crashing on the content of the .po translation file that was loaded from the filesystem. Normally, the rosetta toolbar loads this file and renders it itself. In this case, the debug-toolbar is getting in there and trying to render it as well. As far as I can tell, debug-toolbar is simply passing these through to the django template engine which is assuming they are ascii. I don't see why as I thought it would assume utf-8. I can see that it might be a good idea to coerce the strings into unicode strings as they are pulled from the request to the context. Perhaps it's best to use the smart_str function? |
I guess you were trying to link to this ssbarnea? Both modules are really important to me so I'm crossing my fingers for a fix =) |
nickers fix worked for me. |
I encountered a similar bug when using v0.8.3: My SQL contains Chinese words and it works without debug-toolbar, but it fails with it. File "/home/fcamel/python_ve/se/lib/python2.5/site-packages/debug_toolbar/panels/sql.py", line 122, in execute 'hash': sha_constructor(settings.SECRET_KEY + sql + _params).hexdigest(), UnicodeEncodeError: 'ascii' codec can't encode characters in position 124-126: ordinal not in range(128) The problem seems to be that sha_constructor cannot take unicode as input. I'm sure that all my SQLs are unicode objects, so I fixed it by encode the input to string: class DatabaseStatTracker(util.CursorDebugWrapper): """ Replacement for CursorDebugWrapper which stores additional information in `connection.queries`. """ def execute(self, sql, params=()): # ... 'hash': sha_constructor((settings.SECRET_KEY + sql + _params).encode('utf8')).hexdigest(), I guess a better fix is to detect the type and then covert it to str if it's unicode. |
Try the latest rosetta trunk. Fixed it for me. http://code.google.com/p/django-rosetta/issues/detail?id=71 |
I cannot reproduce the bug using debug-toolbar v0.8.3 with neither Rosetta v0.5.6 nor Rosetta trunk (r119). I can view the rosetta pages without any error with debug-toolbar. Follow your link, I saw mbonetti couldn't reproduce, either. Is it still a bug? |
I always got this error with debug-toolbar 0.8.3 and Rosetta 0.5.6. Using latest Rosetta trunk fixed it for me. |
*0.8.4 |
I tried updating to the latest of django-rosetta (0.5.6) and django-debug-toolbar (0.8.4). I ran makemessages and compilemessages. I can load the root url with both enabled. Once I pick a sublanguage though I still get the following stack trace:
So it looks like there is still something that is not right. Disabling the debug toolbar allows me to view the rosetta url properly. I'm still not sure I understand how these two projects interact well enough. |
I'm sorry I didn't realize you said using trunk fixed it. Let me try that instead of 0.8.4 |
Sorry, I haven't used L10N / I18N before. Could somebody provide a more detailed steps to reproduce the bug? I enabled rosettal with 0.5.9 (r119) and debug-toolbar 0.8.4 (8cb8aba) and can view the index page correctly. See http://img840.imageshack.us/i/rosettaanddebugtoolbar.png/ |
I can get to the index page. It's viewing a language po file that causes the issue I think. Try this: *Set up a project with a translation I'll try to reproduce it on a fresh project when I get a chance. I suspect it's a Rosetta bug. |
If you look at the stack trace below There have been significant improvements in this area since this ticket was opened 4 years ago and the bug may have been fixed in I'm going to leave this ticket open for the time being but I haven't attempted to reproduce it. If someone has the time to confirm whether it still exists or not, that'd help. |
Looking at the patches proposed for this issue, it's ultimately triggered by including non-ASCII data in the session. This explains the link with rosetta: it was probably storing a non-ASCII language name in the session. I believe this issue has been fixed, either in Django or in the Debug Toolbar, and I'll commit a test. |
This is a bit of a strange one. I have both django-debug-toolbar and django-rosetta installed. Once I go to the http://localhost:8000/rosetta/ url and pick a language for translation, I get this error. Once this error has come out, it won't be able to render any other pages without error. I am running this with postgresql and manage.py runserver:
The trace shows django-debug-toolbar in the trace so I am opening the issue here. Disabling the debug-toolbar code makes it work again.
Please let me know if you need more information than this to figure it out. Also, I don't really understand how the debug toolbar works with other plugins so if you think this is actually a bug in the other middleware, let me know and I will open it there.
The text was updated successfully, but these errors were encountered: