Opened 15 years ago
Closed 15 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)
Changed 15 years ago by
Attachment: | test_admin_views.diff added |
---|
comment:1 Changed 15 years ago by
Has patch: | set |
---|---|
Version: | 1.0 → 1.0-beta-1 |
comment:2 Changed 15 years ago by
Triage Stage: | Unreviewed → Accepted |
---|
When attaching patches to tickets, please only attach one that includes both the fix, tests and documentation (if applicable).
Changed 15 years ago by
Attachment: | admin_options.diff added |
---|
comment:3 Changed 15 years ago by
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 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
This is yet another UnicodeDecode issue caused by lack of force_unicode encapsulation.
As explained here: