如何在MIME消息中对Content-Disposition标头的文件名参数值进行编码? [英] How to encode the filename parameter value of the Content-Disposition header in MIME message?

问题描述

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

By checking the source of some emails, I found that many emails use 'Encoded Words' (RFC 2047) format to encode the filename parameter values. However, according to RFC 2047, this encoding method should not be used to header parameter values. Instead, the parameter value, such as the filename parameter in Content-Disposition header, should use the encoding method suggested by RFC 2231.

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

Thus, my question is why so many emails don't comply with the RFC standards. Is it a right way to encode the header parameter value with RFC 2047 format? Can all the email agents parse these emails properly?

推荐答案

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

The sad truth is that many popular email clients are in violation of pertinent RFCs.

实际上，正如您推测的那样，MIME正文部分中的文件名应使用RFC2231，但是许多野外的实现都使用RFC2047或许多其他非正式的，临时的，或者甚至是不确定的文件名编码.

Indeed, as you surmise, filenames in MIME body parts should use RFC2231, but many implementations out in the wild use RFC2047 or a number of other informal, ad-hoc, or at worst indeterminable filename encodings.

至于为什么"，我真的不认为这是可以回答的.从根本上讲，我认为我们不能做得比在某种程度上猜测这是一个错误要好.

As for the "why", I don't really think this is answerable. Fundamentally I think we can't do better than guess it's a mistake at some level.

常见且易于识别的不正确编码似乎在受欢迎的客户之间相当透明地工作；但是根据定义，不遵守规范会消除保证接收者可以正确猜出预期目的的任何保证.

Common and easily identified incorrect encodings seem to work fairly transparently between popular clients; but by definition, failure to adhere to the specification removes any guarantee that the recipient can correctly guess what was intended.

作为参考，这是一条模型消息，应希望通过验证(-:

For reference, here is a model message which should hopefully pass validation (-:

From: me <[e-mail]>
To: =?utf-8?B?G=C3=B6del?= <[e-mail]>
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 参数被 Content-Disposition的 filename 参数取代:标头，但是如果某些客户端仍然无法理解 Content-Disposition:

For the record, the Content-Type: header's name parameter is superseded by the filename parameter of the Content-Disposition: header, but many implenentations still conservatively specify both, in case some client somewhere still doesn't grok Content-Disposition:

这篇关于如何在MIME消息中对Content-Disposition标头的文件名参数值进行编码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！