]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
[3.14] Correctly fold unknown-8bit originating from encoded words. (GH-142517) (...
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Wed, 24 Dec 2025 18:20:05 +0000 (19:20 +0100)
committerGitHub <noreply@github.com>
Wed, 24 Dec 2025 18:20:05 +0000 (13:20 -0500)
commit68098110367bf23fc03cd4a5813c266bd234e6f7
treefc1c7c419516aa39ab7b49efbcf8dbb0c0e3ab5b
parentb921374c78db9bef15057a937f12083a714a47f2
[3.14] Correctly fold unknown-8bit originating from encoded words. (GH-142517) (#143146)

The unknown-8bit trick was designed to deal with unknown bytes in an
ASCII message, and it works fine for that.  However, I also tried to
extend it to handle bytes that can't be decoded using the charset
specified in an encoded word, and there it fails because there can be
other non-ASCII characters that were *successfully* decoded.  The fix is
simple: do the unknown-8bit encoding using the utf-8 codec.  This is
especially appropriate since anyone trying to do recovery on an unknown
byte string will probably attempt utf-8 first.
(cherry picked from commit 1e17ccd030a2285ad53db5952360fffa33a8a877)

Co-authored-by: R. David Murray <rdmurray@bitdance.com>
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Lib/email/_encoded_words.py
Lib/test/test_email/test__header_value_parser.py
Misc/NEWS.d/next/Library/2025-12-10-10-00-06.gh-issue-142517.fG4hbe.rst [new file with mode: 0644]