2

通过检查一些电子邮件的来源，我发现许多电子邮件使用“编码字”（RFC 2047）格式对文件名参数值进行编码。但是，根据 RFC 2047，此编码方法不应用于标头参数值。相反，参数值，例如 Content-Disposition 标头中的文件名参数，应使用RFC 2231建议的编码方法。

因此，我的问题是为什么这么多电子邮件不符合 RFC 标准。使用 RFC 2047 格式对标头参数值进行编码是否正确？所有的电子邮件代理都能正确解析这些电子邮件吗？

4

1 回答 1

3

可悲的事实是，许多流行的电子邮件客户端都违反了相关的 RFC。

事实上，正如您所猜测的那样，MIME 正文部分中的文件名应该使用 RFC2231，但在野外的许多实现使用 RFC2047 或许多其他非正式的、临时的，或者最坏的情况是无法确定的文件名编码。

至于“为什么”，我真的不认为这是可以回答的。从根本上说，我认为我们不能做得比猜测它在某种程度上是一个错误更好。

常见且易于识别的不正确编码似乎在流行客户端之间相当透明地工作；但根据定义，如果不遵守规范，则无法保证接收者可以正确猜测其意图。

作为参考，这里是一个模型消息，它有望通过验证（-：

From: me <tripleee@example.org>
To: =?utf-8?B?G=C3=B6del?= <goedel@example.net>
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被标头的参数取代，但是许多实现仍然保守地指定两者，以防某个地方的某些客户端仍然无法理解filenameContent-Disposition:Content-Disposition:

于 2018-08-07T05:57:32.423 回答