#27895 closed Bug (wontfix)
Test Client fails to decode json response with unicode characters
Reported by: | Aniruddha Maru | Owned by: | Aniruddha Maru |
---|---|---|---|
Component: | Testing framework | Version: | 1.10 |
Severity: | Normal | Keywords: | |
Cc: | Claude Paroz, Fabio Bonelli | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Since application/json
response ought to be encoded with utf-8
charset per spec RFC 7159, they should be decoded as such.
The problematic line is here:
response._json = json.loads(response.content.decode(), **extra)
Which ought to be changed to:
response._json = json.loads(response.content.decode('utf-8'), **extra)
Attachments (2)
Change History (19)
comment:1 by , 8 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 8 years ago
comment:3 by , 8 years ago
I think Django makes the assumption that when Unicode characters are sent JSON-encoded on the wire, those characters are escaped (\\u00e9
).
Is that a wrong assumption?
comment:4 by , 8 years ago
Claude, could you provide an explanation of why Django would make that assumption? I'm not knowledgeable to confirm or reject it.
comment:5 by , 8 years ago
Tim, I'm not talking about master or Python 3, but with Python 2, calling decode()
without specifying an encoding will default to 'ascii' decoding.
comment:6 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Since response.json
is new in 1.9, even if this is valid, it doesn't qualify for a backport at this time. Marking as "fixed" since Django's master branch only supports Python 3.
comment:7 by , 8 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
Triage Stage: | Unreviewed → Accepted |
I do not totally agree. If this is recognized as a bug, as 1.11 still supports Python 2 and considering we are still in beta phase, this should be fixed for 1.11.
The proposed patch is simple and has a test. I'm available to create the PR.
comment:8 by , 8 years ago
The guideline for the post-beta period is only to backport release blocking bugs (if this is considered a blocker, it would normally also be fixed in 1.10) but I'm fine with whatever you want to do here.
comment:9 by , 8 years ago
Aniruddha, could you gave the use case of using ensure_ascii=False
in the JsonResponse
?
comment:10 by , 8 years ago
Tim, it's really straightforward: we have browser based API documentation, and unicode data. Since json supports utf-8 encoding, it's pretty standard to always return unicode, rather than have an encode-decode cycle.
Here's some more context of other people who've talked about this bug:
https://github.com/tomchristie/django-rest-framework/issues/2891
https://github.com/tomchristie/django-rest-framework/issues/2891#issuecomment-178932902
Django rest framework also offers a flag to disable this behavior: http://www.django-rest-framework.org/api-guide/settings/#unicode_json, which is enabled by default.
comment:11 by , 8 years ago
Okay, thanks. Can you create the pull request against stable/1.11.x? I think you could modify the existing json view to return some non-ASCII content rather than adding another view.
comment:13 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Reclosing. A pull request was never provided for 1.11.
comment:14 by , 7 years ago
Cc: | added |
---|---|
Resolution: | fixed |
Status: | closed → new |
Pull request for 1.11: https://github.com/django/django/pull/9061
comment:15 by , 7 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
As this isn't a regression or a bug in a new feature in 1.11, it doesn't qualify for a backport to stable/1.11.x. See our supported versions policy.
comment:16 by , 7 years ago
You gave somewhat of a mixed signal with comment:11.
Anyway, this bug report has still a patch attached for master. Would you accept a PR against that branch?
comment:17 by , 7 years ago
Sorry for the confusion. 6 months ago when I made that comment, 1.11 wasn't released so less critical bug fixes were more acceptable.
Master doesn't support Python 2 so as far as I understand, this issue doesn't affect it.
This is only relevant for Py2.