Opened 16 years ago
Closed 16 years ago
#8910 closed (fixed)
Unicodedecodeerror with inline models when using speical characers and python 2.3.4
Reported by: | joshg | Owned by: | nobody |
---|---|---|---|
Component: | Uncategorized | Version: | 1.0-beta |
Severity: | Keywords: | python2.3 unicode | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I am using SVN checkout 8972 of Django with Python 2.3.4 and mod_python . In one of my models http://dpaste.com/hold/76255/ I have an inline model named StandardOptionsInline
.
When I add special characters like ® (Registered Trademark Symbol) to the inlined model StandardOptionsInline
I get the following error:
UnicodeDecodeError - 'ascii' codec can't decode byte 0xc2 in position 0: ordinal not in range(128)
http://dpaste.com/hold/76259/.
However, if I edit the model that the inline model is based off of StandardOptions
directly using the Admin interface, I can add fields with special characters like ®.
I have found that if I use Python 2.5 and the Django development server this issue does not occur. My solution will be upgrading to Python 2.5.
Thanks,
Josh
Attachments (2)
Change History (6)
by , 16 years ago
Attachment: | test_admin_views.diff added |
---|
comment:1 by , 16 years ago
Has patch: | set |
---|---|
Version: | 1.0 → 1.0-beta-1 |
comment:2 by , 16 years ago
Triage Stage: | Unreviewed → Accepted |
---|
When attaching patches to tickets, please only attach one that includes both the fix, tests and documentation (if applicable).
by , 16 years ago
Attachment: | admin_options.diff added |
---|
comment:3 by , 16 years ago
Changed the admin_options patch a to only encapsulate the model object. I is not necessary to encapsulate unicode strings.
I will remember to only add one patch for the tests and fix next time :).
comment:4 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This is yet another UnicodeDecode issue caused by lack of force_unicode encapsulation.
As explained here: