Question

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

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

Answer 1

可悲的事实是，许多流行的电子邮件客户端都违反了相关的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参数被filename标头的Content-Disposition:参数取代，但是在某些情况下，许多实现仍然保守地指定了两者某个地方的客户仍然不满意Content-Disposition:

如何在MIME消息中编码Content-Disposition标头的文件名参数值？

1 个答案: