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
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