email.Message.set_charset and Content-Transfer-Encoding

D

David Bolen

I've noticed that using set_charset() on an email.Message instance will not
replace any existing Content-Transfer-Encoding header but will install one
if it isn't yet present.

Thus, if you initially create a message without a charset, it defaults to
us-ascii, and creates both Content-Type and Content-Transfer-Encoding
headers (the latter of which defaults to "7bit").

If you then later attempt to change the charset (say, to "iso-8859-1")
with set_charset(), it adjusts the Content-Type header, but leaves the
Content-Transfer-Encoding header alone, which I would think is no
longer accurate, since it is the new charset's body encoding that will
eventually be used when flattening the message, which would then no longer
match the encoding header.

It's also different than if you had passed in an iso-8859-1 charset
originally when constructing the message instance, in which case the
encoding would have been selected as quoted-printable.

The documentation for set_charset seemed to imply (at least to me)
that eventual headers generated by a generator would be affected by
the change in charset, so having it stay at 7bit was confusing.

Is anyone aware of a reason why the encoding shouldn't adjust in
response to a set_charset call similar to how a supplied charset
initially establishes it at message creation time?

-- David
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top