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
utf-7 inconsistent with surrogates #57542
Comments
The utf-7 codec happily encodes lone surrogates, but it won't decode them: >>> "\ud801".encode("utf-7")
b'+2AE-'
>>> "\ud801\ud801".encode("utf-7")
b'+2AHYAQ-'
>>> "\ud801".encode("utf-7").decode("utf-7")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/antoine/cpython/default/Lib/encodings/utf_7.py", line 12, in decode
return codecs.utf_7_decode(input, errors, True)
UnicodeDecodeError: 'utf7' codec can't decode bytes in position 0-4: second surrogate missing at end of shift sequence
>>> "\ud801\ud801".encode("utf-7").decode("utf-7")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/antoine/cpython/default/Lib/encodings/utf_7.py", line 12, in decode
return codecs.utf_7_decode(input, errors, True)
UnicodeDecodeError: 'utf7' codec can't decode bytes in position 0-6: second surrogate missing I don't know which behaviour is better but round-tripping is certainly a desirable property of any codec. |
RFC 2152 talks about encoding 16-bit unicode, and clarifies Surrogate pairs (UTF-16) are converted by treating each half So lone surrogates clearly should be supported. This text could be interpreted as saying that decoding surrogate pairs should also keep them (rather than combining them). However, the RFC also assumes that the decoded form will use 16-bit code units; for Python, I think we should continue combining surrogate pairs on decoding UTF-7 when we find them. |
FWIW Wikipedia says "Other characters must be encoded in UTF-16 (hence U+10000 and higher would be encoded into surrogates) and then in modified Base64." So one possible interpretation is that while encoding a non-BMP char, it should be first converted in a surrogate pair and then each of the surrogates should be encoded just like any other 16bit code unit. The RFC doesn't say anything about lone surrogates, but I think that the fact that surrogates are used internally doesn't necessarily mean that the codec should be able to encode/decode them when they are not paired. The other UTF-* codecs reject them, but that's because it is explicitly forbidden by their respective standards. So I'm +1 about recombining them while decoding, and ±0 about allowing lone surrogates. |
Here is a patch. |
Can you please regenerate the patch against default's head? |
It's a patch for 3.2. |
Please don't use git-style diffs then, since otherwise the review can't figure out what the patch applies to (and neither could I figure that out). |
Here is a non-git diff then :) |
LGTM. |
New changeset ddfcb0de564f by Antoine Pitrou in branch '3.2': New changeset 250091e60f28 by Antoine Pitrou in branch 'default': New changeset 050772822bde by Antoine Pitrou in branch '2.7': |
I made a little fix to the patch for wide unicode builds and then committed it. Thank you! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: