]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
[3.13] 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:19:28 +0000 (19:19 +0100)
committerGitHub <noreply@github.com>
Wed, 24 Dec 2025 18:19:28 +0000 (13:19 -0500)
commit88025560aa2c275b811907ef21e9cb7e09cdcdca
tree513b00e4ebe231b426b07e18be3f02b148f31c03
parent86504f26bd7a7fa3b5157d20c3212b740910d07e
[3.13] Correctly fold unknown-8bit originating from encoded words. (GH-142517) (#143147)

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]