Merged revisions 81758-81759 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r81758 | ezio.melotti | 2010-06-05 20:51:07 +0300 (Sat, 05 Jun 2010) | 15 lines
Update PyUnicode_DecodeUTF8 from RFC 2279 to RFC 3629.
1) #8271: when a byte sequence is invalid, only the start byte and all the
valid continuation bytes are now replaced by U+FFFD, instead of replacing
the number of bytes specified by the start byte.
See http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf (pages 94-95);
2) 5- and 6-bytes-long UTF-8 sequences are now considered invalid (no changes
in behavior);
3) Add code and tests to reject surrogates (U+D800-U+DFFF) as defined in
RFC 3629, but leave it commented out since it's not backward compatible;
4) Change the error messages "unexpected code byte" to "invalid start byte"
and "invalid data" to "invalid continuation byte";
5) Add an extensive set of tests in test_unicode;
6) Fix test_codeccallbacks because it was failing after this change.
........
r81759 | ezio.melotti | 2010-06-05 22:21:32 +0300 (Sat, 05 Jun 2010) | 1 line
Add a NEWS entry for r81758 and clarify a comment.
........
diff --git a/Misc/NEWS b/Misc/NEWS
index f876d3a..a60abca 100644
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -12,6 +12,14 @@
Core and Builtins
-----------------
+- Issue #8271: during the decoding of an invalid UTF-8 byte sequence, only the
+ start byte and the continuation byte(s) are now considered invalid, instead
+ of the number of bytes specified by the start byte.
+ E.g.: '\xf1\x80AB'.decode('utf-8', 'replace') now returns u'\ufffdAB' and
+ replaces with U+FFFD only the start byte ('\xf1') and the continuation byte
+ ('\x80') even if '\xf1' is the start byte of a 4-bytes sequence.
+ Previous versions returned a single u'\ufffd'.
+
- Issue #9058: Remove assertions about INT_MAX in UnicodeDecodeError.
- Issue #8941: decoding big endian UTF-32 data in UCS-2 builds could crash