-
Notifications
You must be signed in to change notification settings - Fork 122
Add extended charset support for writing #166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
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. 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. |
|
@emersion Could you elaborate on your rationale here? Any chance you could reconsider this? For anyone who has a requirement to write emails in other charsets, which is common in many parts of the world, we're having to maintain a fork of this library. There's already support for conversion in reading, why not also writing? |
|
Sorry, no. I strongly believe that everyone should just use UTF-8. (Note, nobody forces you to use this library, and yeah feel free to fork.) |
|
Thanks, I'm still having trouble understanding the reasoning here. Why is writing different from reading? If everyone should just use UTF-8, then why support reading other charsets? |
|
There is a great deal of emails stored in files, databases and such with legacy encodings. |
|
OK, and why not support writing in different charsets to better interoperate with the great deal of systems that use legacy encodings? |
|
Systems can change, messages can't. |
|
That's not really a meaningful difference when I don't control the third party system. |
Adds a
CharsetWriterfunc to mirrorCharsetReader, but for writing. The main use case for this (that prompted me to make this PR) is the ability to useEntity'sWriteTofunc for all messages that the library already supports for reading.The existing write behavior for
utf-8andus-asciiis persisted; this primarily just adds support for other charsets.