Message340931
| Author |
r.david.murray |
| Recipients |
barry, immerrr again, jaraco, jayvdb, r.david.murray, tanzer@swing.co.at |
| Date |
2019年04月26日.16:22:30 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1556295750.22.0.0231104181975.issue25545@roundup.psfhosted.org> |
| In-reply-to |
| Content |
This is one of the infelicities of the translation of the old API to python3: 'get_payload(decode=True)' actually means 'give me the bytes version of this payload", which in this case is the utf-8, which is what you got. get_payload() means "give me the payload as a string without doing CTE decoding". In a sort of accident-of-translation this turns out to mean "give me the unicode" in this particular case. If the payload had been base64 encoded, you'd have gotten a unicode string containing the base64 characters.
Which I grant you is all very confusing.
For a more consistent API, use the new one:
>>> import email.policy
>>> m = email.message_from_bytes(msg_bytes, policy=email.policy.default)
>>> bytes(m)
b'MIME-Version: 1.0\nContent-Type: text/plain;\n charset=utf-8\nContent-Transfer-Encoding: 8bit\nContent-Disposition: attachment;\n filename="camper_store.csv"\n\nBeyo\xc4\x9flu-\xc4\xb0st'
>>> m.get_content()
'Beyoğlu-İst'
Here we don't even pretend that you have any use for the encoded version, either CTE encoding or binary encoding: get_content gives you the "fully decoded" payload (decoded from CTE *and* decoded to unicode). |
|