这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@jtb6
Copy link

@jtb6 jtb6 commented Mar 3, 2023

Adds a CharsetWriter func to mirror CharsetReader, but for writing. The main use case for this (that prompted me to make this PR) is the ability to use Entity's WriteTo func for all messages that the library already supports for reading.

The existing write behavior for utf-8 and us-ascii is persisted; this primarily just adds support for other charsets.

@emersion
Copy link
Owner

emersion commented Mar 3, 2023

This feature has been rejected in the past.

Why would one want to use anything other than UTF-8 when writing messages?

@jtb6
Copy link
Author

jtb6 commented Mar 3, 2023

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

@emersion
Copy link
Owner

emersion commented Mar 6, 2023

That doesn't seem like a compelling explanation to me, sorry.

@emersion emersion closed this Mar 6, 2023
@ab
Copy link

ab commented Mar 3, 2025

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

@emersion
Copy link
Owner

emersion commented Mar 3, 2025

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

@ab
Copy link

ab commented Mar 4, 2025

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?

@emersion
Copy link
Owner

emersion commented Mar 4, 2025

There is a great deal of emails stored in files, databases and such with legacy encodings.

@ab
Copy link

ab commented Mar 4, 2025

OK, and why not support writing in different charsets to better interoperate with the great deal of systems that use legacy encodings?

@emersion
Copy link
Owner

emersion commented Mar 4, 2025

Systems can change, messages can't.

@ab
Copy link

ab commented Mar 5, 2025

That's not really a meaningful difference when I don't control the third party system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants