当不遵守 RFC 时，MIME 主题解码
主题 mime 字段采用 ASCII 格式。 ASCII 表中排除的每个字符都必须进行 Q/编码或 base64/编码。标头中的 Content-Type 字段也与主题的编码方式无关。我说得对吗？
然而（不幸的是）某些客户端（例如 Microsoft Outlook 6）会在标头中插入以任何内容（例如 BIG5）编码的字符串，而没有使用 q/base64 编码指定该字符串是 BIG5 格式。我该如何处理这些编码错误的电子邮件？有没有标准的方法来解析这些？
我的目标是拥有尽可能最大的兼容性，即使使用第三部分付费程序；我怎样才能做到这一点？ （抱歉我的英语有问题）
Subject mime field is in ASCII. Every character excluded by the ASCII table has to be Q/encoded or base64/encoded. Content-Type field in the header has also nothing to do with the way subject is encoded. Am I correct?
However (and unfortunately) some clients (read Microsoft Outlook 6 for example) insert a string encoded in whatever (BIG5 for example) in the header, without specifying with q/base64 encoding that the string is in BIG5. How can i handle these wrongly-encoded emails? Is there a standard way, to parse these?
My goal is to have the biggest compatibility possible, even by using 3rd part paid programs; how can i do that? (sorry for my buggy english)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
主题标头编码与 Content-Type 标头无关。没有“完美”的方式来处理Subject。我只是通过一个 hack 来实现这一点，尝试查看文本的所有字符是否都适合 big5，如果不适合，则按顺序尝试下一个编码。
Big5、utf-8、latin-1、q/base64 以及最后的 ascii
Subject header encoding has nothing to do with Content-Type header. There is no "perfect" way to handle Subject. I've implemented this just by a hack that tries to see if all characters of text fit in big5, if not then try next encoding in order.
Big5, utf-8, latin-1, q/base64 and finally ascii