Closed jtb6 closed 1 year ago
This feature has been rejected in the past.
Why would one want to use anything other than UTF-8 when writing messages?
@emersion For Latin languages, I agree that UTF-8 feels like it's a strictly better choice, and has almost universal adoption. Globally, there are some other encodings that have a decent amount of use (i.e. GB18030
for Chinese, Shift JIS
& EUC-JP
for Japanese, etc.). I agree that UTF-8 is equally a good choice for representing those languages, but I feel like the consumer of the library should be welcome to opt in to whatever charset they might want to use (or need to use, if integrating with a legacy system).
Again, I agree with you that UTF-8 is probably the best choice if I'm choosing to craft and send an email. My argument for this change is that we let the developer using the library make that choice, since we can't assume that UTF-8 always meets the needs of their project. (In particular, I am such a developer trying to support crafting emails of various charsets, which is not possible without this change)
That doesn't seem like a compelling explanation to me, sorry.
Adds a
CharsetWriter
func to mirrorCharsetReader
, but for writing. The main use case for this (that prompted me to make this PR) is the ability to useEntity
'sWriteTo
func for all messages that the library already supports for reading.The existing write behavior for
utf-8
andus-ascii
is persisted; this primarily just adds support for other charsets.