Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 6266 greenbytes
Updates: 2616 June 2011
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 6266 greenbytes
Updates: 2616 June 2011
Category: Standards Track
ISSN: 2070-1721
Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
在超文本传输协议（HTTP）中使用内容处置标头字段
Abstract
摘要
RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects.
RFC2616定义了内容处置响应头字段，但指出它不是HTTP/1.1标准的一部分。本规范接管了HTTP中使用的内容处置的定义和注册，并阐明了国际化方面。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6266.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6266.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Notational Conventions ..........................................3
3. Conformance and Error Handling ..................................3
4. Header Field Definition .........................................3
4.1. Grammar ....................................................4
4.2. Disposition Type ...........................................5
4.3. Disposition Parameter: 'Filename' ..........................5
4.4. Disposition Parameter: Extensions ..........................6
4.5. Extensibility ..............................................7
5. Examples ........................................................7
6. Internationalization Considerations .............................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
8.1. Registry for Disposition Values and Parameters .............8
8.2. Header Field Registration ..................................8
9. Acknowledgements ................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
Appendix A. Changes from the RFC 2616 Definition ..................11
Appendix B. Differences Compared to RFC 2183 ......................11
Appendix C. Alternative Approaches to Internationalization ........11
C.1. RFC 2047 Encoding ..........................................12
C.2. Percent Encoding ...........................................12
C.3. Encoding Sniffing ..........................................12
Appendix D. Advice on Generating Content-Disposition Header
Fields ................................................13
1. Introduction ....................................................2
2. Notational Conventions ..........................................3
3. Conformance and Error Handling ..................................3
4. Header Field Definition .........................................3
4.1. Grammar ....................................................4
4.2. Disposition Type ...........................................5
4.3. Disposition Parameter: 'Filename' ..........................5
4.4. Disposition Parameter: Extensions ..........................6
4.5. Extensibility ..............................................7
5. Examples ........................................................7
6. Internationalization Considerations .............................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
8.1. Registry for Disposition Values and Parameters .............8
8.2. Header Field Registration ..................................8
9. Acknowledgements ................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
Appendix A. Changes from the RFC 2616 Definition ..................11
Appendix B. Differences Compared to RFC 2183 ......................11
Appendix C. Alternative Approaches to Internationalization ........11
C.1. RFC 2047 Encoding ..........................................12
C.2. Percent Encoding ...........................................12
C.3. Encoding Sniffing ..........................................12
Appendix D. Advice on Generating Content-Disposition Header
Fields ................................................13
RFC 2616 defines the Content-Disposition response header field (Section 19.5.1 of [RFC2616]) but points out that it is not part of the HTTP/1.1 Standard (Section 15.5):
RFC 2616定义了内容处置响应头字段（RFC2616的第19.5.1节），但指出它不是HTTP/1.1标准的一部分（第15.5节）：
Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementers.
内容处置不是HTTP标准的一部分，但由于它被广泛实施，我们正在为实施者记录其使用和风险。
This specification takes over the definition and registration of Content-Disposition, as used in HTTP. Based on interoperability testing with existing user agents (UAs), it fully defines a profile of the features defined in the Multipurpose Internet Mail Extensions (MIME) variant ([RFC2183]) of the header field, and also clarifies internationalization aspects.
此规范接管了HTTP中使用的内容处置的定义和注册。基于与现有用户代理（UAs）的互操作性测试，它完全定义了标题字段的多用途Internet邮件扩展（MIME）变体（[RFC2183]）中定义的功能的概要文件，并阐明了国际化方面。
Note: This document does not apply to Content-Disposition header fields appearing in payload bodies transmitted over HTTP, such as when using the media type "multipart/form-data" ([RFC2388]).
注意：本文档不适用于通过HTTP传输的有效负载正文中出现的内容处置头字段，例如使用媒体类型“multipart/form data”（[RFC2388]）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification uses the augmented BNF (ABNF) notation defined in Section 2.1 of [RFC2616], including its rules for implied linear whitespace (LWS).
本规范使用[RFC2616]第2.1节中定义的增广BNF（ABNF）符号，包括其隐含线性空白（LWS）规则。
This specification defines conformance criteria for both senders (usually, HTTP origin servers) and recipients (usually, HTTP user agents) of the Content-Disposition header field. An implementation is considered conformant if it complies with all of the requirements associated with its role.
该规范定义了内容处置头字段的发送方（通常为HTTP源服务器）和接收方（通常为HTTP用户代理）的一致性标准。如果一个实现符合与其角色相关的所有需求，那么它被认为是一致的。
This specification also defines certain forms of the header field value to be invalid, using both ABNF and prose requirements (Section 4), but it does not define special handling of these invalid field values.
本规范还使用ABNF和散文要求（第4节）将某些形式的标题字段值定义为无效，但未定义对这些无效字段值的特殊处理。
Senders MUST NOT generate Content-Disposition header fields that are invalid.
发件人不得生成无效的内容处置标头字段。
Recipients MAY take steps to recover a usable field value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behavior (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them.
收件人可以采取步骤从无效的标头字段恢复可用字段值，但不应立即拒绝消息，除非这是明确需要的行为（例如，实现是验证器）。因此，对无效字段的默认处理是忽略它们。
The Content-Disposition response header field is used to convey additional information about how to process the response payload, and also can be used to attach additional metadata, such as the filename to use when saving the response payload locally.
Content Disposition response header字段用于传递有关如何处理响应负载的附加信息，还可用于附加附加元数据，例如在本地保存响应负载时要使用的文件名。
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "inline" | "attachment" | disp-ext-type
; case-insensitive
disp-ext-type = token
disposition-type = "inline" | "attachment" | disp-ext-type
; case-insensitive
disp-ext-type = token
disposition-parm = filename-parm | disp-ext-parm
处置参数=文件名参数| disp ext parm
filename-parm = "filename" "=" value
| "filename*" "=" ext-value
filename-parm = "filename" "=" value
| "filename*" "=" ext-value
disp-ext-parm = token "=" value
| ext-token "=" ext-value
ext-token = <the characters in token, followed by "*">
disp-ext-parm = token "=" value
| ext-token "=" ext-value
ext-token = <the characters in token, followed by "*">
Defined in [RFC2616]:
在[RFC2616]中定义：
token = <token, defined in [RFC2616], Section 2.2>
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
value = <value, defined in [RFC2616], Section 3.6>
; token | quoted-string
token = <token, defined in [RFC2616], Section 2.2>
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
value = <value, defined in [RFC2616], Section 3.6>
; token | quoted-string
Defined in [RFC5987]:
在[RFC5987]中定义：
ext-value = <ext-value, defined in [RFC5987], Section 3.2>
ext-value = <ext-value, defined in [RFC5987], Section 3.2>
Content-Disposition header field values with multiple instances of the same parameter name are invalid.
具有相同参数名称的多个实例的内容处置标头字段值无效。
Note that due to the rules for implied linear whitespace (Section 2.1 of [RFC2616]), OPTIONAL whitespace can appear between words (token or quoted-string) and separator characters.
注意，由于隐含线性空格的规则（RFC2616的第2.1节），可选空格可以出现在单词（标记或带引号的字符串）和分隔符之间。
Furthermore, note that the format used for ext-value allows specifying a natural language (e.g., "en"); this is of limited use for filenames and is likely to be ignored by recipients.
此外，请注意，用于ext value的格式允许指定自然语言（例如，“en”）；这对文件名的使用有限，收件人可能会忽略它。
If the disposition type matches "attachment" (case-insensitively), this indicates that the recipient should prompt the user to save the response locally, rather than process it normally (as per its media type).
如果处置类型与“附件”匹配（不区分大小写），则表示收件人应提示用户在本地保存响应，而不是正常处理响应（根据其媒体类型）。
On the other hand, if it matches "inline" (case-insensitively), this implies default processing. Therefore, the disposition type "inline" is only useful when it is augmented with additional parameters, such as the filename (see below).
另一方面，如果它匹配“inline”（不区分大小写），则意味着默认处理。因此，处置类型“inline”只有在使用附加参数（如文件名）进行扩充时才有用（见下文）。
Unknown or unhandled disposition types SHOULD be handled by recipients the same way as "attachment" (see also [RFC2183], Section 2.8).
收件人应以与“附件”相同的方式处理未知或未处理的处置类型（另请参见[RFC2183]，第2.8节）。
The parameters "filename" and "filename*", to be matched case-insensitively, provide information on how to construct a filename for storing the message payload.
参数“filename”和“filename*”（不区分大小写匹配）提供了有关如何构造用于存储消息负载的文件名的信息。
Depending on the disposition type, this information might be used right away (in the "save as..." interaction caused for the "attachment" disposition type), or later on (for instance, when the user decides to save the contents of the current page being displayed).
根据处置类型的不同，此信息可能会立即使用（在“附件”处置类型引起的“另存为…”交互中），或稍后使用（例如，当用户决定保存当前显示页面的内容时）。
The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in [RFC5987], allowing the use of characters not present in the ISO-8859-1 character set ([ISO-8859-1]).
参数“filename”和“filename*”的不同之处在于，“filename*”使用[RFC5987]中定义的编码，允许使用ISO-8859-1字符集（[ISO-8859-1]）中不存在的字符。
Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when both "filename" and "filename*" are present in a single header field value, recipients SHOULD pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see Section 5 for an example).
在此规范之前的许多用户代理实现都不理解“filename*”参数。因此，当“文件名”和“文件名*”同时出现在单个标题字段值中时，收件人应选择“文件名*”并忽略“文件名”。通过这种方式，发送方可以通过发送更具表现力的“filename*”参数和“filename”参数作为旧版收件人的备用参数来避免特定于特殊大小写的用户代理（示例请参见第5节）。
It is essential that recipients treat the specified filename as advisory only, and thus be very careful in extracting the desired information. In particular:
收件人必须将指定的文件名仅视为建议文件，因此在提取所需信息时必须非常小心。特别地：
o Recipients MUST NOT be able to write into any location other than one to which they are specifically entitled. To illustrate the problem, consider the consequences of being able to overwrite well-known system locations (such as "/etc/passwd"). One strategy to achieve this is to never trust folder name information in the filename parameter, for instance by stripping all but the last path segment and only considering the actual filename (where 'path segments' are the components of the field value delimited by the path separator characters "\" and "/").
o 收件人不得在其有权访问的位置以外的任何位置进行书写。为了说明问题，考虑能够覆盖众所周知的系统位置（例如“/ETC/PASSWD”）的后果。实现这一点的一种策略是永远不要信任filename参数中的文件夹名称信息，例如，除去最后一个路径段以外的所有路径段，只考虑实际的文件名（“路径段”是由路径分隔符“\”和“/”分隔的字段值的组成部分）。
o Many platforms do not use Internet Media Types ([RFC2046]) to hold type information in the file system, but rely on filename extensions instead. Trusting the server-provided file extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients that make use of file extensions to determine the media type MUST ensure that a file extension is used that is safe, optimally matching the media type of the received payload.
o 许多平台不使用Internet媒体类型（[RFC2046]）在文件系统中保存类型信息，而是依赖文件扩展名。信任服务器提供的文件扩展名可能会在以后打开保存的文件时引入权限升级（请考虑“.exe”）。因此，使用文件扩展名来确定媒体类型的收件人必须确保使用的文件扩展名是安全的，与接收到的有效负载的媒体类型最佳匹配。
o Recipients SHOULD strip or replace character sequences that are known to cause confusion both in user interfaces and in filenames, such as control characters and leading and trailing whitespace.
o 收件人应删除或替换已知会在用户界面和文件名中造成混淆的字符序列，如控制字符、前导和尾随空格。
o Other aspects recipients need to be aware of are names that have a special meaning in the file system or in shell commands, such as "." and "..", "~", "|", and also device names. Recipients SHOULD ignore or substitute names like these.
o 收件人需要注意的其他方面是在文件系统或shell命令中具有特殊含义的名称，例如“.”和“.”、“~”、“|”以及设备名称。收件人应该忽略或替换这些名称。
Note: Many user agents do not properly handle the escape character "\" when using the quoted-string form. Furthermore, some user agents erroneously try to perform unescaping of "percent" escapes (see Appendix C.2), and thus might misinterpret filenames containing the percent character followed by two hex digits.
注意：当使用带引号的字符串形式时，许多用户代理无法正确处理转义字符“\”。此外，一些用户代理错误地尝试执行“百分比”转义的取消（见附录C.2），因此可能会误解包含百分比字符和两个十六进制数字的文件名。
To enable future extensions, recipients SHOULD ignore unrecognized parameters (see also [RFC2183], Section 2.8).
要启用将来的扩展，收件人应忽略无法识别的参数（另请参见[RFC2183]，第2.8节）。
Note that Section 9 of [RFC2183] defines IANA registries both for disposition types and disposition parameters. This registry is shared by different protocols using Content-Disposition, such as MIME and HTTP. Therefore, not all registered values may make sense in the context of HTTP.
请注意，[RFC2183]的第9节为处置类型和处置参数定义了IANA注册表。此注册表由使用内容配置（如MIME和HTTP）的不同协议共享。因此，并非所有注册值在HTTP上下文中都有意义。
Direct the UA to show "save as" dialog, with a filename of "example.html":
指示UA显示文件名为“example.html”的“另存为”对话框：
Content-Disposition: Attachment; filename=example.html
Content-Disposition: Attachment; filename=example.html
Direct the UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html" for a subsequent save operation:
指示UA表现为内容处置标题字段不存在，但要记住文件名“an example.html”以进行后续保存操作：
Content-Disposition: INLINE; FILENAME= "an example.html"
Content-Disposition: INLINE; FILENAME= "an example.html"
Note: This uses the quoted-string form so that the space character can be included.
注意：这使用带引号的字符串形式，以便可以包含空格字符。
Direct the UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):
指示UA显示“另存为”对话框，文件名包含Unicode字符U+20AC（欧元符号）：
Content-Disposition: attachment;
filename*= UTF-8''%e2%82%ac%20rates
Content-Disposition: attachment;
filename*= UTF-8''%e2%82%ac%20rates
Here, the encoding defined in [RFC5987] is also used to encode the non-ISO-8859-1 character.
这里，[RFC5987]中定义的编码也用于编码非ISO-8859-1字符。
This example is the same as the one above, but adding the "filename" parameter for compatibility with user agents not implementing RFC 5987:
此示例与上面的示例相同，但添加了“filename”参数以与未实现RFC 5987的用户代理兼容：
Content-Disposition: attachment;
filename="EURO rates";
filename*=utf-8''%e2%82%ac%20rates
Content-Disposition: attachment;
filename="EURO rates";
filename*=utf-8''%e2%82%ac%20rates
Note: Those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after "filename".
注意：不支持RFC 5987编码的用户代理在“文件名”之后出现时忽略“文件名*”。
The "filename*" parameter (Section 4.3), using the encoding defined in [RFC5987], allows the server to transmit characters outside the ISO-8859-1 character set, and also to optionally specify the language in use.
“filename*”参数（第4.3节）使用[RFC5987]中定义的编码，允许服务器在ISO-8859-1字符集之外传输字符，还可以选择指定使用的语言。
Future parameters might also require internationalization, in which case the same encoding can be used.
未来的参数可能还需要国际化，在这种情况下，可以使用相同的编码。
Using server-supplied information for constructing local filenames introduces many risks. These are summarized in Section 4.3.
使用服务器提供的信息构建本地文件名会带来许多风险。第4.3节对此进行了总结。
Furthermore, implementers ought to be aware of the security considerations applying to HTTP (see Section 15 of [RFC2616]), and also the parameter encoding defined in [RFC5987] (see Section 5).
此外，实现者应该了解应用于HTTP的安全注意事项（参见[RFC2616]第15节），以及[RFC5987]中定义的参数编码（参见第5节）。
This specification does not introduce any changes to the registration procedures for disposition values and parameters that are defined in Section 9 of [RFC2183].
本规范未对[RFC2183]第9节中定义的处置值和参数的注册程序进行任何更改。
This document updates the definition of the Content-Disposition HTTP header field in the permanent HTTP header field registry (see [RFC3864]).
本文档更新了永久HTTP标头字段注册表中内容处置HTTP标头字段的定义（请参见[RFC3864]）。
Header field name: Content-Disposition
标题字段名称：内容处置
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 4)
规范文件：本规范（第4节）
Related information: none
相关信息：无
Thanks to Adam Barth, Rolf Eike Beer, Stewart Bryant, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Alexey Melnikov, Henrik Nordstrom, and Mark Nottingham for their valuable feedback.
感谢亚当·巴特、罗尔夫·艾克·比尔、斯图尔特·布莱恩特、比约恩·霍尔曼、阿尔弗雷德·霍恩斯、罗尔·劳里茨森、阿列克谢·梅尔尼科夫、亨里克·诺德斯特罗姆和马克·诺丁汉的宝贵反馈。
[ISO-8859-1] International Organization for Standardization, "Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-1:1998, 1998.
[ISO-8859-1]国际标准化组织，“信息技术——8位单字节编码图形字符集——第1部分：拉丁字母表1”，ISO/IEC 8859-1:1998，1998。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, August 2010.
[RFC5987]Reschke，J.，“超文本传输协议（HTTP）头字段参数的字符集和语言编码”，RFC 5987，2010年8月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，Ed.，“在互联网消息中传达呈现信息：内容处置标题字段”，RFC 2183，1997年8月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998.
[RFC2388]Masinter，L.“从表单返回值：多部分/表单数据”，RFC 23881998年8月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[US-ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII]美国国家标准协会，“编码字符集——信息交换用7位美国标准代码”，ANSI X3.41986。
Compared to Section 19.5.1 of [RFC2616], the following normative changes reflecting actual implementations have been made:
与[RFC2616]第19.5.1节相比，做出了以下反映实际实施的规范性变更：
o According to RFC 2616, the disposition type "attachment" only applies to content of type "application/octet-stream". This restriction has been removed, because recipients in practice do not check the content type, and it also discourages properly declaring the media type.
o 根据RFC 2616，处置类型“附件”仅适用于类型“应用程序/八位字节流”的内容。此限制已被删除，因为实际上收件人不检查内容类型，并且不鼓励正确声明媒体类型。
o RFC 2616 only allows "quoted-string" for the filename parameter. This would be an exceptional parameter syntax, and also doesn't reflect actual use.
o RFC 2616仅允许文件名参数使用“带引号的字符串”。这将是一种特殊的参数语法，也不能反映实际使用情况。
o The definition for the disposition type "inline" ([RFC2183], Section 2.1) has been re-added with a suggestion for its processing.
o 重新添加了处置类型“内联”（[RFC2183]，第2.1节）的定义，并对其处理提出了建议。
o This specification requires support for the extended parameter encoding defined in [RFC5987].
o 本规范要求支持[RFC5987]中定义的扩展参数编码。
Section 2 of [RFC2183] defines several additional disposition parameters: "creation-date", "modification-date", "quoted-date-time", and "size". The majority of user agents do not implement these; thus, they have been omitted from this specification.
[RFC2183]第2节定义了几个额外的处置参数：“创建日期”、“修改日期”、“引用日期时间”和“大小”。大多数用户代理不实现这些功能；因此，本规范中省略了它们。
By default, HTTP header field parameters cannot carry characters outside the ISO-8859-1 ([ISO-8859-1]) character encoding (see [RFC2616], Section 2.2). For the "filename" parameter, this of course is an unacceptable restriction.
默认情况下，HTTP头字段参数不能携带ISO-8859-1（[ISO-8859-1]）字符编码之外的字符（请参阅[RFC2616]，第2.2节）。对于“filename”参数，这当然是一个不可接受的限制。
Unfortunately, user agent implementers have not managed to come up with an interoperable approach, although the IETF Standards Track specifies exactly one solution ([RFC2231], clarified and profiled for HTTP in [RFC5987]).
不幸的是，尽管IETF标准跟踪只指定了一个解决方案（[RFC2231]，在[RFC5987]中对HTTP进行了澄清和分析），但用户代理实现者尚未设法提出一种可互操作的方法。
For completeness, the sections below describe the various approaches that have been tried, and explain how they are inferior to the RFC 5987 encoding used in this specification.
为完整起见，以下各节描述了已经尝试过的各种方法，并解释了它们如何低于本规范中使用的RFC 5987编码。
RFC 2047 defines an encoding mechanism for header fields, but this encoding is not supposed to be used for header field parameters -- see Section 5 of [RFC2047]:
RFC 2047定义了头字段的编码机制，但这种编码不应用于头字段参数——请参阅[RFC2047]的第5节：
An 'encoded-word' MUST NOT appear within a 'quoted-string'.
“编码字”不得出现在“带引号的字符串”中。
...
...
An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'.
“编码字”不得用于MIME内容类型或内容处置字段的参数中，或任何结构化字段正文中，但“注释”或“短语”中除外。
In practice, some user agents implement the encoding, some do not (exposing the encoded string to the user), and some get confused by it.
在实践中，有些用户代理实现编码，有些不实现（向用户公开编码字符串），有些则会被它弄糊涂。
Some user agents accept percent-encoded ([RFC3986], Section 2.1) sequences of characters. The character encoding being used for decoding depends on various factors, including the encoding of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter.
一些用户代理接受字符的百分比编码（[RFC3986]，第2.1节）序列。用于解码的字符编码取决于各种因素，包括引用页面的编码、用户代理的区域设置、其配置以及参数的实际值。
In practice, this is hard to use because those user agents that do not support it will display the escaped character sequence to the user. For those user agents that do implement this, it is difficult to predict what character encoding they actually expect.
实际上，这很难使用，因为不支持它的用户代理将向用户显示转义字符序列。对于实现此功能的用户代理，很难预测他们实际期望的字符编码。
Some user agents inspect the value (which defaults to ISO-8859-1 for the quoted-string form) and switch to UTF-8 when it seems to be more likely to be the correct interpretation.
一些用户代理检查该值（引用的字符串形式默认为ISO-8859-1），并在更可能是正确解释时切换到UTF-8。
As with the approaches above, this is not interoperable and, furthermore, risks misinterpreting the actual value.
与上述方法一样，这是不可互操作的，而且有可能误解实际价值。
To successfully interoperate with existing and future user agents, senders of the Content-Disposition header field are advised to:
要成功与现有和未来的用户代理进行互操作，建议内容处置标头字段的发件人：
o Include a "filename" parameter when US-ASCII ([US-ASCII]) is sufficiently expressive.
o 当US-ASCII（[US-ASCII]）具有足够的表达能力时，包括一个“filename”参数。
o Use the 'token' form of the filename parameter only when it does not contain disallowed characters (e.g., spaces); in such cases, the quoted-string form should be used.
o 仅当文件名参数不包含不允许的字符（例如空格）时，才使用文件名参数的“令牌”形式；在这种情况下，应使用带引号的字符串形式。
o Avoid including the percent character followed by two hexadecimal characters (e.g., %A9) in the filename parameter, since some existing implementations consider it to be an escape character, while others will pass it through unchanged.
o 避免在文件名参数中包含百分比字符，后面跟着两个十六进制字符（例如，%A9），因为一些现有的实现认为它是一个转义字符，而另一些则将通过不变。
o Avoid including the "\" character in the quoted-string form of the filename parameter, as escaping is not implemented by some user agents, and "\" can be considered an illegal path character.
o 避免在filename参数的带引号的字符串形式中包含“\”字符，因为某些用户代理不实现转义，并且“\”可以被视为非法路径字符。
o Avoid using non-ASCII characters in the filename parameter. Although most existing implementations will decode them as ISO-8859-1, some will apply heuristics to detect UTF-8, and thus might fail on certain names.
o 避免在文件名参数中使用非ASCII字符。尽管大多数现有的实现将它们解码为ISO-8859-1，但有些将应用启发式方法来检测UTF-8，因此可能会在某些名称上失败。
o Include a "filename*" parameter where the desired filename cannot be expressed faithfully using the "filename" form. Note that legacy user agents will not process this, and will fall back to using the "filename" parameter's content.
o 包括一个“filename*”参数，其中所需的文件名不能使用“filename”格式如实表示。请注意，传统用户代理将不会处理此问题，而会退回到使用“filename”参数的内容。
o When a "filename*" parameter is sent, to also generate a "filename" parameter as a fallback for user agents that do not support the "filename*" form, if possible. This can be done by substituting characters with US-ASCII sequences (e.g., Unicode character point U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) by "ae"). Note that this may not be possible in some locales.
o 发送“filename*”参数时，如果可能，还可以生成一个“filename”参数，作为不支持“filename*”表单的用户代理的后备方案。这可以通过用US-ASCII序列替换字符来实现（例如，Unicode字符点U+00E4（带DIARESIS的拉丁小写字母A）替换为“ae”）。请注意，在某些地区，这可能是不可能的。
o When a "filename" parameter is included as a fallback (as per above), "filename" should occur first, due to parsing problems in some existing implementations.
o 当包含“filename”参数作为回退时（如上所述），由于某些现有实现中的解析问题，“filename”应该首先出现。
o Use UTF-8 as the encoding of the "filename*" parameter, when present, because at least one existing implementation only implements that encoding.
o 使用UTF-8作为“filename*”参数的编码（如果存在），因为至少有一个现有实现只实现该编码。
Note that this advice is based upon UA behavior at the time of writing, and might be superseded. At the time of publication of this document, <http://purl.org/NET/http/content-disposition-tests> provides an overview of current levels of support in various implementations.
请注意，本建议基于撰写本文时UA的行为，可能会被取代。在本文件出版时<http://purl.org/NET/http/content-disposition-tests>概述了各种实现中的当前支持级别。
Author's Address
作者地址
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/