Opened 17 years ago
Closed 17 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 , 17 years ago
| Attachment: | test_admin_views.diff added |
|---|
comment:1 by , 17 years ago
| Has patch: | set |
|---|---|
| Version: | 1.0 → 1.0-beta-1 |
comment:2 by , 17 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 , 17 years ago
| Attachment: | admin_options.diff added |
|---|
comment:3 by , 17 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 , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This is yet another UnicodeDecode issue caused by lack of force_unicode encapsulation.
As explained here: