通过查看一些邮件的来源，我发现很多邮件都使用了“Encoded Words”（RFC 2047 https://www.ietf.org/rfc/rfc2047.txt) 格式对文件名参数值进行编码。然而，根据 RFC 2047，这种编码方法不应用于标头参数值。相反，参数值（例如 Content-Disposition 标头中的文件名参数）应使用建议的编码方法RFC 2231 https://www.ietf.org/rfc/rfc2231.txt.
因此，我的问题是为什么这么多电子邮件不符合 RFC 标准。使用 RFC 2047 格式对标头参数值进行编码是否正确？所有电子邮件代理都能正确解析这些电子邮件吗？
可悲的事实是，许多流行的电子邮件客户端都违反了相关的 RFC。
事实上，正如您所猜测的，MIME 正文部分中的文件名应该使用 RFC2231，但许多实际实现使用 RFC2047 或许多其他非正式的、临时的或最坏的不确定的文件名编码。
至于“为什么”，我真的认为这是无法回答的。从根本上说，我认为我们不能比猜测这在某种程度上是一个错误更好。
常见且容易识别的错误编码似乎在流行客户端之间相当透明地工作；但根据定义，不遵守规范就无法保证接收者可以正确地猜猜意图是什么。
作为参考，这里是一个模型消息，应该希望通过验证（-：
From: me <[email protected] /cdn-cgi/l/email-protection>
To: =?utf-8?B?G=C3=B6del?= <[email protected] /cdn-cgi/l/email-protection>
Subject: File name and recipient are identical,
but encoded differently
Mime-Version: 1.0
Content-type: application/octet-stream;
name*=UTF-8''G%C3%B6del
Content-disposition: attachment;
filename*=UTF-8''G%C3%B6del
Content-transfer-encoding: base64
R8O2ZGVsCg==
根据记录，Content-Type:标头的name参数被取代filename的参数Content-Disposition:标头，但许多实现仍然保守地指定两者，以防某些地方的某些客户端仍然不明白Content-Disposition:
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
