Skip to main content

Appendix A. Changes from the RFC 2616 Definition (与RFC 2616定义的变化)

与[RFC2616]第19.5.1节相比，已经进行了以下反映实际实现的规范性更改:

  • 根据RFC 2616，处置类型"attachment"仅适用于类型为"application/octet-stream"的内容。此限制已被移除，因为接收者在实践中不检查内容类型，并且它也不鼓励正确声明媒体类型。

  • RFC 2616仅允许filename参数使用"quoted-string"。这将是一个异常的参数语法，并且也不反映实际使用情况。

  • [RFC2183]第2.1节中"inline"处置类型的定义已重新添加，并建议其处理方式。

  • 本规范要求支持[RFC5987]中定义的扩展参数编码。

Appendix B. Differences Compared to RFC 2183 (与RFC 2183的差异)

[RFC2183]的第2节定义了几个额外的处置参数: "creation-date"、"modification-date"、"quoted-date-time"和"size"。大多数用户代理没有实现这些；因此，它们已从本规范中省略。

Appendix C. Alternative Approaches to Internationalization (国际化的替代方法)

默认情况下，HTTP头字段参数不能携带ISO-8859-1 ([ISO-8859-1])字符编码之外的字符(参见[RFC2616]第2.2节)。对于"filename"参数，这当然是一个不可接受的限制。

不幸的是，用户代理实现者尚未设法提出一种可互操作的方法，尽管IETF标准跟踪明确规定了一种解决方案([RFC2231]，在[RFC5987]中为HTTP进行了澄清和配置)。

为了完整起见，以下各节描述了已尝试的各种方法，并解释了它们如何不如本规范中使用的RFC 5987编码。

C.1. RFC 2047 Encoding (RFC 2047编码)​

RFC 2047为头字段定义了一种编码机制，但此编码不应该用于头字段参数 -- 参见[RFC2047]第5节:

'encoded-word'禁止(MUST NOT)出现在'quoted-string'中。

...

'encoded-word'禁止(MUST NOT)用于MIME Content-Type或Content-Disposition字段的参数中，或任何结构化字段主体中，除非在'comment'或'phrase'内。

在实践中，一些用户代理实现了编码，一些没有实现(向用户暴露编码的字符串)，还有一些被它混淆。

C.2. Percent Encoding (百分号编码)​

一些用户代理接受百分号编码([RFC3986]第2.1节)的字符序列。用于解码的字符编码取决于各种因素，包括引用页面的编码、用户代理的区域设置、其配置，以及参数的实际值。

在实践中，这很难使用，因为那些不支持它的用户代理会向用户显示转义的字符序列。对于那些确实实现了这一点的用户代理，很难预测它们实际期望的字符编码。

C.3. Encoding Sniffing (编码嗅探)​

一些用户代理检查值(对于quoted-string形式默认为ISO-8859-1)，并在看起来更可能是正确解释时切换到UTF-8。

与上述方法一样，这不具有互操作性，并且还有错误解释实际值的风险。

Appendix D. Advice on Generating Content-Disposition Header Fields (生成Content-Disposition头字段的建议)

为了成功与现有和未来的用户代理互操作，Content-Disposition头字段的发送者应该:

  • 当US-ASCII ([US-ASCII])足够表达时，包含"filename"参数。

  • 仅当filename参数不包含不允许的字符(例如，空格)时，使用它的'token'形式；在这种情况下，应该使用quoted-string形式。

  • 避免在filename参数中包含百分号字符后跟两个十六进制字符(例如，%A9)，因为一些现有实现将其视为转义字符，而其他实现会原样传递。

  • 避免在filename参数的quoted-string形式中包含""字符，因为一些用户代理未实现转义，并且""可以被视为非法路径字符。

  • 避免在filename参数中使用非ASCII字符。尽管大多数现有实现会将它们解码为ISO-8859-1，但有些会应用启发式方法来检测UTF-8，因此可能会在某些名称上失败。

  • 当无法使用"filename"形式忠实地表达所需文件名时，包含"filename*"参数。请注意，旧版用户代理不会处理此内容，并将回退到使用"filename"参数的内容。

  • 当发送"filename*"参数时，还要为不支持"filename*"形式的用户代理生成"filename"参数作为回退(如果可能)。这可以通过用US-ASCII序列替换字符来完成(例如，Unicode代码点U+00E4 (LATIN SMALL LETTER A WITH DIAERESIS, 带分音符的拉丁小写字母A)用"ae"表示)。请注意，在某些区域设置中这可能不可行。

  • 当包含"filename"参数作为回退时(如上所述)，"filename"应该首先出现，因为在一些现有实现中存在解析问题。

  • 当存在时，使用UTF-8作为"filename*"参数的编码，因为至少有一个现有实现仅实现该编码。

注意: 此建议基于编写时的UA行为，并可能被取代。在本文档发布时，http://purl.org/NET/http/content-disposition-tests提供了各种实现中当前支持级别的概述。

Last updated on