Internet Engineering Task Force (IETF) L. Masinter
Request for Comments: 7578 Adobe
Obsoletes: 2388 July 2015
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) L. Masinter
Request for Comments: 7578 Adobe
Obsoletes: 2388 July 2015
Category: Standards Track
ISSN: 2070-1721
Returning Values from Forms: multipart/form-data
从表单返回值：多部分/表单数据
Abstract
摘要
This specification defines the multipart/form-data media type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. This document obsoletes RFC 2388.
本规范定义了多部分/表单数据媒体类型，可由多种应用程序使用，并通过多种协议传输，作为用户填写表单时返回一组值的方式。本文件废除了RFC 2388。
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/rfc7578.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7578.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Percent-Encoding Option . . . . . . . . . . . . . . . . . . . 3
3. Advice for Forms and Form Processing . . . . . . . . . . . . 3
4. Definition of multipart/form-data . . . . . . . . . . . . . . 4
4.1. "Boundary" Parameter of multipart/form-data . . . . . . . 4
4.2. Content-Disposition Header Field for Each Part . . . . . 4
4.3. Multiple Files for One Form Field . . . . . . . . . . . . 5
4.4. Content-Type Header Field for Each Part . . . . . . . . . 5
4.5. The Charset Parameter for "text/plain" Form Data . . . . 5
4.6. The _charset_ Field for Default Charset . . . . . . . . . 6
4.7. Content-Transfer-Encoding Deprecated . . . . . . . . . . 6
4.8. Other "Content-" Header Fields . . . . . . . . . . . . . 7
5. Operability Considerations . . . . . . . . . . . . . . . . . 7
5.1. Non-ASCII Field Names and Values . . . . . . . . . . . . 7
5.1.1. Avoid Non-ASCII Field Names . . . . . . . . . . . . . 7
5.1.2. Interpreting Forms and Creating multipart/form-data
Data . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. Parsing and Interpreting Form Data . . . . . . . . . 8
5.2. Ordered Fields and Duplicated Field Names . . . . . . . . 8
5.3. Interoperability with Web Applications . . . . . . . . . 8
5.4. Correlating Form Data with the Original Form . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Media Type Registration for multipart/form-data . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 2388 . . . . . . . . . . . . . . . 14
Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Percent-Encoding Option . . . . . . . . . . . . . . . . . . . 3
3. Advice for Forms and Form Processing . . . . . . . . . . . . 3
4. Definition of multipart/form-data . . . . . . . . . . . . . . 4
4.1. "Boundary" Parameter of multipart/form-data . . . . . . . 4
4.2. Content-Disposition Header Field for Each Part . . . . . 4
4.3. Multiple Files for One Form Field . . . . . . . . . . . . 5
4.4. Content-Type Header Field for Each Part . . . . . . . . . 5
4.5. The Charset Parameter for "text/plain" Form Data . . . . 5
4.6. The _charset_ Field for Default Charset . . . . . . . . . 6
4.7. Content-Transfer-Encoding Deprecated . . . . . . . . . . 6
4.8. Other "Content-" Header Fields . . . . . . . . . . . . . 7
5. Operability Considerations . . . . . . . . . . . . . . . . . 7
5.1. Non-ASCII Field Names and Values . . . . . . . . . . . . 7
5.1.1. Avoid Non-ASCII Field Names . . . . . . . . . . . . . 7
5.1.2. Interpreting Forms and Creating multipart/form-data
Data . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. Parsing and Interpreting Form Data . . . . . . . . . 8
5.2. Ordered Fields and Duplicated Field Names . . . . . . . . 8
5.3. Interoperability with Web Applications . . . . . . . . . 8
5.4. Correlating Form Data with the Original Form . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Media Type Registration for multipart/form-data . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 2388 . . . . . . . . . . . . . . . 14
Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
In many applications, it is possible for a user to be presented with a form. The user will fill out the form, including information that is typed, generated by user input, or included from files that the user has selected. When the form is filled out, the data from the form is sent from the user to the receiving application.
在许多应用程序中，用户可以看到表单。用户将填写表单，包括键入的、由用户输入生成的或从用户选择的文件中包含的信息。填写表单时，表单中的数据将从用户发送到接收应用程序。
The definition of multipart/form-data is derived from one of those applications, originally set out in [RFC1867] and subsequently incorporated into HTML 3.2 [W3C.REC-html32-19970114], where forms are expressed in HTML, and the form data is sent via HTTP or electronic mail. This representation is widely implemented in numerous web browsers and web servers.
多部分/表单数据的定义源自其中一个应用程序，最初在[RFC1867]中提出，随后并入HTML 3.2[W3C.REC-html32-19970114]，其中表单以HTML表示，表单数据通过HTTP或电子邮件发送。这种表示在许多web浏览器和web服务器中广泛实现。
However, multipart/form-data is also used for forms that are presented using representations other than HTML (spreadsheets, PDF, etc.) and for transport using means other than electronic mail or HTTP; it is used in distributed applications that do not involve forms at all or do not have users filling out the form. For this reason, this document defines a general syntax and semantics independent of the application for which it is used, with specific rules for web applications noted in context.
但是，多部分/表单数据也用于使用HTML（电子表格、PDF等）以外的表示形式表示的表单，以及使用电子邮件或HTTP以外的方式传输的表单；它用于完全不涉及表单或没有用户填写表单的分布式应用程序中。因此，本文档定义了一个通用语法和语义，它独立于所使用的应用程序，并在上下文中说明了web应用程序的特定规则。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Within this specification, "percent-encoding" (as defined in [RFC3986]) is offered as a possible way of encoding characters in file names that are otherwise disallowed, including non-ASCII characters, spaces, control characters, and so forth. The encoding is created replacing each non-ASCII or disallowed character with a sequence, where each byte of the UTF-8 encoding of the character is represented by a percent-sign (%) followed by the (case-insensitive) hexadecimal of that byte.
在本规范中，“百分比编码”（如[RFC3986]中所定义）是一种可能的方式，用于编码文件名中不允许的字符，包括非ASCII字符、空格、控制字符等。创建编码时，使用序列替换每个非ASCII或不允许的字符，其中字符UTF-8编码的每个字节由百分号（%）表示，后跟该字节的（不区分大小写）十六进制。
The representation and interpretation of forms and the nature of form processing is not specified by this document. However, for forms and form processing that result in the generation of multipart/form-data, some suggestions are included.
本文件未规定表格的表示和解释以及表格处理的性质。但是，对于导致生成多部分/表单数据的表单和表单处理，包含一些建议。
In a form, there is generally a sequence of fields, where each field is expected to be supplied with a value, e.g., by a user who fills out the form. Each field has a name. After a form has been filled out and the form's data is "submitted", the form processing results in a set of values for each field -- the "form data".
在表单中，通常有一系列字段，其中每个字段都应提供一个值，例如，由填写表单的用户提供。每个字段都有一个名称。填写表单并“提交”表单数据后，表单处理将为每个字段生成一组值——“表单数据”。
In forms that work with multipart/form-data, field names could be arbitrary Unicode strings; however, restricting field names to ASCII will help avoid some interoperability issues (see Section 5.1).
在使用多部分/表单数据的表单中，字段名可以是任意Unicode字符串；但是，将字段名限制为ASCII将有助于避免一些互操作性问题（参见第5.1节）。
Within a given form, ensuring field names are unique is also helpful. Some fields may have default values or presupplied values in the form itself. Fields with presupplied values might be hidden or invisible; this allows using generic processing for form data from a variety of actual forms.
在给定的表单中，确保字段名是唯一的也很有帮助。某些字段在表单本身中可能具有默认值或预先应用的值。具有预先应用值的字段可能是隐藏的或不可见的；这允许对来自各种实际表单的表单数据使用通用处理。
The media type multipart/form-data follows the model of multipart MIME data streams as specified in Section 5.1 of [RFC2046]; changes are noted in this document.
媒体类型多部分/表单数据遵循[RFC2046]第5.1节规定的多部分MIME数据流模型；本文件中记录了变更。
A multipart/form-data body contains a series of parts separated by a boundary.
多部分/表单数据体包含由边界分隔的一系列部分。
As with other multipart types, the parts are delimited with a boundary delimiter, constructed using CRLF, "--", and the value of the "boundary" parameter. The boundary is supplied as a "boundary" parameter to the multipart/form-data type. As noted in Section 5.1 of [RFC2046], the boundary delimiter MUST NOT appear inside any of the encapsulated parts, and it is often necessary to enclose the "boundary" parameter values in quotes in the Content-Type header field.
与其他多部分类型一样，零件由边界分隔符分隔，该分隔符使用CRLF、“--”和“boundary”参数的值构造。边界作为“边界”参数提供给多部分/表单数据类型。如[RFC2046]第5.1节所述，边界分隔符不得出现在任何封装部件内，通常需要在内容类型标题字段中将“边界”参数值括在引号中。
Each part MUST contain a Content-Disposition header field [RFC2183] where the disposition type is "form-data". The Content-Disposition header field MUST also contain an additional parameter of "name"; the value of the "name" parameter is the original field name from the form (possibly encoded; see Section 5.1). For example, a part might contain a header field such as the following, with the body of the part containing the form data of the "user" field:
每个部分必须包含一个内容处置标题字段[RFC2183]，其中处置类型为“表单数据”。内容处置头字段还必须包含附加参数“名称”；“name”参数的值是表单中的原始字段名（可能已编码；请参阅第5.1节）。例如，一个部件可能包含如下标题字段，部件主体包含“用户”字段的表单数据：
Content-Disposition: form-data; name="user"
Content-Disposition: form-data; name="user"
For form data that represents the content of a file, a name for the file SHOULD be supplied as well, by using a "filename" parameter of the Content-Disposition header field. The file name isn't mandatory for cases where the file name isn't available or is meaningless or private; this might result, for example, when selection or drag-and-drop is used or when the form data content is streamed directly from a device.
对于表示文件内容的表单数据，还应使用content Disposition标头字段的“filename”参数提供文件名。对于文件名不可用或无意义或私有的情况，文件名不是强制性的；例如，当使用选择或拖放时，或者当表单数据内容直接从设备流式传输时，可能会出现这种情况。
If a "filename" parameter is supplied, the requirements of Section 2.3 of [RFC2183] for the "receiving MUA" (i.e., the receiving Mail User Agent) apply to receivers of multipart/form-data as well: do not use the file name blindly, check and possibly change to match local file system conventions if applicable, and do not use directory path information that may be present.
如果提供了“文件名”参数，[RFC2183]第2.3节对“接收MUA”（即，接收邮件用户代理）的要求也适用于多部分/表单数据的接收者：不要盲目使用文件名，检查并可能更改以匹配本地文件系统约定（如果适用），并且不要使用可能存在的目录路径信息。
In most multipart types, the MIME header fields in each part are restricted to US-ASCII; for compatibility with those systems, file names normally visible to users MAY be encoded using the percent-encoding method in Section 2, following how a "file:" URI [URI-SCHEME] might be encoded.
在大多数多部分类型中，每个部分中的MIME头字段仅限于US-ASCII；为了与这些系统兼容，用户通常可见的文件名可以使用第2节中的百分比编码方法进行编码，遵循“文件：”URI[URI-SCHEME]的编码方式。
NOTE: The encoding method described in [RFC5987], which would add a "filename*" parameter to the Content-Disposition header field, MUST NOT be used.
注意：不得使用[RFC5987]中描述的编码方法，该方法将向内容处置标题字段添加“filename*”参数。
Some commonly deployed systems use multipart/form-data with file names directly encoded including octets outside the US-ASCII range. The encoding used for the file names is typically UTF-8, although HTML forms will use the charset associated with the form.
一些通常部署的系统使用文件名直接编码的多部分/表单数据，包括US-ASCII范围之外的八位字节。用于文件名的编码通常是UTF-8，尽管HTML表单将使用与表单关联的字符集。
The form data for a form field might include multiple files.
表单字段的表单数据可能包含多个文件。
[RFC2388] suggested that multiple files for a single form field be transmitted using a nested "multipart/mixed" part. This usage is deprecated.
[RFC2388]建议使用嵌套的“多部分/混合”部分传输单个表单字段的多个文件。这种用法已被弃用。
To match widely deployed implementations, multiple files MUST be sent by supplying each file in a separate part but all with the same "name" parameter.
为了匹配广泛部署的实现，必须通过在单独的部分中提供每个文件来发送多个文件，但所有文件都具有相同的“name”参数。
Receiving applications intended for wide applicability (e.g., multipart/form-data parsing libraries) SHOULD also support the older method of supplying multiple files.
接收具有广泛适用性的应用程序（例如，多部分/表单数据解析库）也应支持提供多个文件的旧方法。
Each part MAY have an (optional) "Content-Type" header field, which defaults to "text/plain". If the contents of a file are to be sent, the file data SHOULD be labeled with an appropriate media type, if known, or "application/octet-stream".
每个部分可能有一个（可选）“内容类型”标题字段，默认为“文本/普通”。如果要发送文件内容，则应使用适当的媒体类型（如果已知）或“应用程序/八位字节流”标记文件数据。
In the case where the form data is text, the charset parameter for the "text/plain" Content-Type MAY be used to indicate the character encoding used in that part. For example, a form with a text field in which a user typed "Joe owes <eu>100", where <eu> is the Euro symbol, might have form data returned as:
在表单数据为文本的情况下，“text/plain”内容类型的charset参数可用于指示该部分中使用的字符编码。例如，用户键入“Joe owes<eu>100”（其中<eu>是欧元符号）的文本字段中的表单可能会将表单数据返回为：
--AaB03x
content-disposition: form-data; name="field1"
content-type: text/plain;charset=UTF-8
content-transfer-encoding: quoted-printable
--AaB03x
content-disposition: form-data; name="field1"
content-type: text/plain;charset=UTF-8
content-transfer-encoding: quoted-printable
Joe owes =E2=82=AC100. --AaB03x
乔·欧文斯=E2=82=AC100--AaB03x
In practice, many widely deployed implementations do not supply a charset parameter in each part, but rather, they rely on the notion of a "default charset" for a multipart/form-data instance. Subsequent sections will explain how the default charset is established.
实际上，许多广泛部署的实现并不在每个部分中提供字符集参数，而是依赖于多部分/表单数据实例的“默认字符集”概念。后续章节将解释如何建立默认字符集。
Some form-processing applications (including HTML) have the convention that the value of a form entry with entry name "_charset_" and type "hidden" is automatically set when the form is opened; the value is used as the default charset of text field values (see form-charset in Section 5.1.2). In such cases, the value of the default charset for each "text/plain" part without a charset parameter is the supplied value. For example:
一些表单处理应用程序（包括HTML）的约定是，当表单打开时，自动设置条目名为“\u charset\”且类型为“hidden”的表单条目的值；该值用作文本字段值的默认字符集（参见第5.1.2节中的表格字符集）。在这种情况下，没有字符集参数的每个“文本/普通”部分的默认字符集的值就是提供的值。例如：
--AaB03x content-disposition: form-data; name="_charset_"
--AaB03x内容配置：表单数据；name=“\u字符集”
iso-8859-1 --AaB03x-- content-disposition: form-data; name="field1"
iso-8859-1--AaB03x--内容处理：表单数据；name=“field1”
...text encoded in iso-8859-1 ... AaB03x--
…以iso-8859-1编码的文本。。。AaB03x--
Previously, it was recommended that senders use a Content-Transfer-Encoding encoding (such as "quoted-printable") for each non-ASCII part of a multipart/form-data body because that would allow use in transports that only support a "7bit" encoding. This use is deprecated for use in contexts that support binary data such as HTTP. Senders SHOULD NOT generate any parts with a Content-Transfer-Encoding header field.
以前，建议发送方对多部分/表单数据体的每个非ASCII部分使用内容传输编码（如“可打印引用”），因为这将允许在仅支持“7bit”编码的传输中使用。不推荐在支持二进制数据（如HTTP）的上下文中使用此用法。发件人不应生成包含内容传输编码头字段的任何部件。
Currently, no deployed implementations that send such bodies have been discovered.
目前，尚未发现发送此类实体的已部署实现。
The multipart/form-data media type does not support any MIME header fields in parts other than Content-Type, Content-Disposition, and (in limited circumstances) Content-Transfer-Encoding. Other header fields MUST NOT be included and MUST be ignored.
多部分/表单数据媒体类型不支持除内容类型、内容处置和（在有限的情况下）内容传输编码以外的部分中的任何MIME头字段。其他标题字段不能包含，必须忽略。
Normally, MIME header fields in multipart bodies are required to consist only of 7-bit data in the US-ASCII character set. While [RFC2388] suggested that non-ASCII field names be encoded according to the method in [RFC2047], this practice doesn't seem to have been followed widely.
通常，多部分正文中的MIME头字段只需要由US-ASCII字符集中的7位数据组成。虽然[RFC2388]建议按照[RFC2047]中的方法对非ASCII字段名进行编码，但这种做法似乎并未得到广泛遵循。
This specification makes three sets of recommendations for three different states of workflow.
本规范针对工作流的三种不同状态提出了三组建议。
For broadest interoperability with existing deployed software, those creating forms SHOULD avoid non-ASCII field names. This should not be a burden because, in general, the field names are not visible to users. The field names in the underlying need not match what the user sees on the screen.
为了与现有部署的软件实现最广泛的互操作性，那些创建表单的人应该避免使用非ASCII字段名。这不应该是一个负担，因为一般来说，字段名对用户不可见。基础字段中的字段名不必与用户在屏幕上看到的内容匹配。
If non-ASCII field names are unavoidable, form or application creators SHOULD use UTF-8 uniformly. This will minimize interoperability problems.
如果非ASCII字段名不可避免，则表单或应用程序创建者应统一使用UTF-8。这将最大限度地减少互操作性问题。
Some applications of this specification will supply a character encoding to be used for interpretation of the multipart/form-data body. In particular, HTML 5 [W3C.REC-html5-20141028] uses
本规范的某些应用程序将提供用于解释多部分/表单数据体的字符编码。特别是，html5[W3C.REC-html5-20141028]使用
o the content of a "_charset_" field, if there is one;
o “\u字符集”字段的内容（如果有）；
o the value of an accept-charset attribute of the <form> element, if there is one;
o <form>元素的accept字符集属性的值（如果有）；
o the character encoding of the document containing the form, if it is US-ASCII compatible;
o 包含表单的文档的字符编码（如果与US-ASCII兼容）；
o otherwise, UTF-8.
o 否则，UTF-8。
Call this value the form-charset. Any text, whether field name, field value, or ("text/plain") form data that uses characters outside the ASCII range MAY be represented directly encoded in the form-charset.
将此值称为表单字符集。任何使用ASCII范围以外字符的文本，无论是字段名、字段值还是（“文本/普通”）表单数据，都可以直接在表单字符集中表示。
While this specification provides guidance for the creation of multipart/form-data, parsers and interpreters should be aware of the variety of implementations. File systems differ as to whether and how they normalize Unicode names, for example. The matching of form elements to form-data parts may rely on a fuzzier match. In particular, some multipart/form-data generators might have followed the previous advice of [RFC2388] and used the "encoded-word" method of encoding non-ASCII values, as described in [RFC2047]:
虽然本规范为多部分/表单数据的创建提供了指导，但解析器和解释器应该了解各种实现。例如，文件系统在是否规范化Unicode名称以及如何规范化Unicode名称方面存在差异。表单元素与表单数据部分的匹配可能依赖于更模糊的匹配。特别是，一些多部分/表单数据生成器可能遵循[RFC2388]之前的建议，并使用了编码非ASCII值的“编码字”方法，如[RFC2047]中所述：
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
Others have been known to follow [RFC2231], to send unencoded UTF-8, or even to send strings encoded in the form-charset.
其他人已经知道遵循[RFC2231]，发送未编码的UTF-8，甚至发送以字符集形式编码的字符串。
For this reason, interpreting multipart/form-data (even from conforming generators) may require knowing the charset used in form encoding in cases where the _charset_ field value or a charset parameter of a "text/plain" Content-Type header field is not supplied.
因此，在未提供_charset_字段值或“text/plain”内容类型标题字段的charset参数的情况下，解释多部分/表单数据（甚至来自一致的生成器）可能需要了解表单编码中使用的字符集。
Form processors given forms with a well-defined ordering SHOULD send back results in order. (Note that there are some forms that do not define a natural order.) Intermediaries MUST NOT reorder the results. Form parts with identical field names MUST NOT be coalesced.
表单处理者给定具有明确顺序的表单应按顺序发回结果。（请注意，有些表单没有定义自然顺序。）中介机构不得对结果重新排序。具有相同字段名的表单部分不得合并。
Many web applications use the "application/x-www-form-urlencoded" method for returning data from forms. This format is quite compact, for example:
许多web应用程序使用“application/x-www-form-urlencoded”方法从表单返回数据。这种格式非常紧凑，例如：
name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send
name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send
However, there is no opportunity to label the enclosed data with a content type, apply a charset, or use other encoding mechanisms.
但是，没有机会使用内容类型标记封闭数据、应用字符集或使用其他编码机制。
Many form-interpreting programs (primarily web browsers) now implement and generate multipart/form-data, but a receiving application might also need to support the "application/x-www-form-urlencoded" format.
许多表单解释程序（主要是web浏览器）现在实现并生成多部分/表单数据，但接收应用程序可能还需要支持“application/x-www-form-urlencoded”格式。
This specification provides no specific mechanism by which multipart/ form-data can be associated with the form that caused it to be transmitted. This separation is intentional; many different forms might be used for transmitting the same data. In practice, applications may supply a specific form processing resource (in HTML, the ACTION attribute in a FORM tag) for each different form. Alternatively, data about the form might be encoded in a "hidden field" (a field that is part of the form but that has a fixed value to be transmitted back to the form-data processor).
本规范未提供多部分/表单数据与导致其传输的表单关联的特定机制。这种分离是有意的；许多不同的形式可用于传输相同的数据。实际上，应用程序可以为每个不同的表单提供特定的表单处理资源（在HTML中，表单标记中的ACTION属性）。或者，关于表单的数据可以编码在“隐藏字段”（作为表单的一部分但具有固定值以传输回表单数据处理器的字段）中。
The media type registration of multipart/form-data has been updated to point to this document, using the template in Section 8. In addition, the registrations of the "name" parameter and the "form-data" value in the "Content Disposition Values and Parameters" registry have been updated to both point to this document.
已使用第8节中的模板更新多部分/表单数据的媒体类型注册，以指向本文档。此外，“内容处置值和参数”注册表中的“名称”参数和“表格数据”值的注册已更新到指向本文档的两个位置。
All form-processing software should treat user supplied form-data with sensitivity, as it often contains confidential or personally identifying information. There is widespread use of form "auto-fill" features in web browsers; these might be used to trick users to unknowingly send confidential information when completing otherwise innocuous tasks. multipart/form-data does not supply any features for checking integrity, ensuring confidentiality, avoiding user confusion, or other security features; those concerns must be addressed by the form-filling and form-data-interpreting applications.
所有表格处理软件应敏感地处理用户提供的表格数据，因为它通常包含机密或个人识别信息。web浏览器中广泛使用表单“自动填充”功能；这些可能被用来欺骗用户在完成其他无害任务时在不知不觉中发送机密信息。多部分/表单数据不提供任何用于检查完整性、确保机密性、避免用户混淆或其他安全功能的功能；表格填写和表格数据解释应用程序必须解决这些问题。
Applications that receive forms and process them must be careful not to supply data back to the requesting form-processing site that was not intended to be sent.
接收表单并处理表单的应用程序必须小心，不要将不打算发送的数据返回到请求表单处理站点。
It is important when interpreting the filename of the Content-Disposition header field to not inadvertently overwrite files in the recipient's file space.
在解释内容处置头字段的文件名时，不要无意中覆盖收件人文件空间中的文件，这一点很重要。
User applications that request form information from users must be careful not to cause a user to send information to the requestor or a third party unwillingly or unwittingly. For example, a form might request that spam information be sent to an unintended third party or private information be sent to someone that the user might not actually intend. While this is primarily an issue for the representation and interpretation of forms themselves (rather than the data representation of the form data), the transportation of private information must be done in a way that does not expose it to unwanted prying.
从用户处请求表单信息的用户应用程序必须小心，不要导致用户不情愿或无意地向请求者或第三方发送信息。例如，表单可能会请求将垃圾邮件信息发送给非预期的第三方，或者将私人信息发送给用户可能并不真正想要的人。虽然这主要是表单本身的表示和解释（而不是表单数据的数据表示）的问题，但私有信息的传输必须以不使其暴露于不必要的窥探的方式进行。
With the introduction of form-data that can reasonably send back the content of files from a user's file space, the possibility arises that a user might be sent an automated script that fills out a form and then sends one of the user's local files to another address. Thus, additional caution is required when executing automated scripting where form-data might include a user's files.
随着表单数据的引入，可以合理地从用户的文件空间发回文件内容，可能会向用户发送一个自动脚本来填写表单，然后将用户的一个本地文件发送到另一个地址。因此，在表单数据可能包含用户文件的情况下，执行自动脚本时需要额外小心。
Files sent via multipart/form-data may contain arbitrary executable content, and precautions against malicious content are necessary.
通过多部分/表单数据发送的文件可能包含任意可执行内容，因此有必要预防恶意内容。
The considerations of Sections 2.3 and 5 of [RFC2183], with respect to the "filename" parameter of the Content-Disposition header field, also apply to its usage here.
[RFC2183]第2.3节和第5节中关于内容处置标题字段“filename”参数的注意事项也适用于此处的使用。
This section is the media type registration using the template from [RFC6838].
本节介绍使用[RFC6838]中的模板进行的媒体类型注册。
Type name: multipart
类型名称：多部分
Subtype name: form-data
子类型名称：表单数据
Required parameters: boundary
所需参数：边界
Optional parameters: none
可选参数：无
Encoding considerations: Common use is BINARY. In limited use (or transports that restrict the encoding to 7bit or 8bit), each part is encoded separately using Content-Transfer-Encoding; see Section 4.7.
编码注意事项：常用的是二进制。在有限使用（或将编码限制为7位或8位的传输）中，使用内容传输编码对每个部分进行单独编码；见第4.7节。
Security considerations: See Section 7 of this document.
安全注意事项：见本文件第7节。
Interoperability considerations: This document makes several recommendations for interoperability with deployed implementations, including Section 4.7.
互操作性注意事项：本文档对与已部署实现的互操作性提出了一些建议，包括第4.7节。
Published specification: This document.
已发布规范：本文件。
Applications that use this media type: Numerous web browsers, servers, and web applications.
使用此媒体类型的应用程序：许多web浏览器、服务器和web应用程序。
Fragment identifier considerations: None; fragment identifiers are not defined for this type.
片段标识符注意事项：无；未为此类型定义片段标识符。
Additional information:
其他信息：
Additional information:
其他信息：
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: Author of this document.
联系人和电子邮件地址，以获取更多信息：本文档作者。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: none
使用限制：无
Author: Author of this document.
作者：本文件的作者。
Change controller: IETF
更改控制器：IETF
Provisional registration: N/A
临时注册：不适用
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2046]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，DOI 10.17487/RFC2046，1996年11月<http://www.rfc-editor.org/info/rfc2046>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, <http://www.rfc-editor.org/info/rfc2047>.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，DOI 10.17487/RFC2047，1996年11月<http://www.rfc-editor.org/info/rfc2047>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, DOI 10.17487/RFC2183, August 1997, <http://www.rfc-editor.org/info/rfc2183>.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，Ed.，“在互联网消息中传达呈现信息：内容处置标题字段”，RFC 2183，DOI 10.17487/RFC2183，1997年8月<http://www.rfc-editor.org/info/rfc2183>.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, <http://www.rfc-editor.org/info/rfc2231>.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 2231，DOI 10.17487/RFC2231，1997年11月<http://www.rfc-editor.org/info/rfc2231>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC1867] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC 1867, DOI 10.17487/RFC1867, November 1995, <http://www.rfc-editor.org/info/rfc1867>.
[RFC1867]Nebel，E.和L.Masinter，“基于表单的HTML文件上传”，RFC 1867，DOI 10.17487/RFC1867，1995年11月<http://www.rfc-editor.org/info/rfc1867>.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, DOI 10.17487/RFC2388, August 1998, <http://www.rfc-editor.org/info/rfc2388>.
[RFC2388]Masinter，L.，“从表单返回值：多部分/表单数据”，RFC 2388，DOI 10.17487/RFC2388，1998年8月<http://www.rfc-editor.org/info/rfc2388>.
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, <http://www.rfc-editor.org/info/rfc5987>.
[RFC5987]Reschke，J.，“超文本传输协议（HTTP）头字段参数的字符集和语言编码”，RFC 5987，DOI 10.17487/RFC5987，2010年8月<http://www.rfc-editor.org/info/rfc5987>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<http://www.rfc-editor.org/info/rfc6838>.
[URI-SCHEME] Kerwin, M., "The file URI Scheme", Work in Progress, draft-ietf-appsawg-file-scheme-02, May 2015.
[URI-SCHEME]Kerwin，M.，“文件URI方案”，正在进行的工作，草稿-ietf-appsawg-file-SCHEME-022015年5月。
[W3C.REC-html32-19970114] Raggett, D., "HTML 3.2 Reference Specification", W3C Recommendation REC-html32-19970114, January 1997, <http://www.w3.org/TR/REC-html32-19970114>.
[W3C.REC-html32-19970114]Raggett，D.，“HTML3.2参考规范”，W3C建议REC-html32-19970114，1997年1月<http://www.w3.org/TR/REC-html32-19970114>.
[W3C.REC-html5-20141028] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C Recommendation REC-html5-20141028, October 2014, <http://www.w3.org/TR/2014/REC-html5-20141028>.
[W3C.REC-html5-20141028]希克森，I.，伯容，R.，福克纳，S.，莱塞德，T.，纳瓦拉，E.，奥康纳，E.，和S.普菲弗，“html5”，W3C建议REC-html5-20141028，2014年10月<http://www.w3.org/TR/2014/REC-html5-20141028>.
The handling of non-ASCII field names has changed -- the method described in RFC 2047 is no longer recommended; instead, it is suggested that senders send UTF-8 field names directly and that file names be sent directly in the form-charset.
非ASCII字段名的处理方式已经改变——不再推荐RFC 2047中描述的方法；相反，建议发送方直接发送UTF-8字段名，并以字符集的形式直接发送文件名。
The handling of multiple files submitted as the result of a single form field (e.g., HTML's <input type=file multiple> element) results in each file having its own top-level part with the same name parameter; the method of using a nested "multipart/mixed" from [RFC2388] is no longer recommended for creators and is not required for receivers as there are no known implementations of senders.
处理作为单个表单字段的结果提交的多个文件（例如，HTML的<input type=file multiple>元素）会导致每个文件都有自己的顶级部分，并且具有相同的名称参数；不再建议创建者使用[RFC2388]中的嵌套“多部分/混合”方法，也不要求接收者使用该方法，因为没有已知的发送者实现。
The _charset_ convention and use of an explicit "form-data" charset is documented; also, "boundary" is now a required parameter in Content-Type.
_字符集u约定和显式“表单数据”字符集的使用已记录在案；此外，“边界”现在是内容类型中的必需参数。
The relationship of the ordering of fields within a form and the ordering of returned values within multipart/form-data was not defined before, nor was the handling of the case where a form has multiple fields with the same name.
表单中字段的顺序与多部分/表单数据中返回值的顺序之间的关系以前没有定义，对于表单具有多个同名字段的情况的处理也没有定义。
Various editorial changes were made; they include removing the obsolete discussion of alternatives from the appendix, updating the references, and moving the outline of form processing into the introduction.
进行了各种编辑修改；它们包括从附录中删除对备选方案的过时讨论，更新参考文献，以及将表单处理的概要移到引言中。
There are numerous alternative ways in which form data can be encoded; many are listed in Section 5.2 of [RFC2388]. The multipart/ form-data encoding is verbose, especially if there are many fields with short values. In most use cases, this overhead isn't significant.
有许多可供选择的方式对表单数据进行编码；[RFC2388]第5.2节列出了许多。多部分/表单数据编码是冗长的，特别是当有许多字段具有短值时。在大多数用例中，这种开销并不显著。
More problematic are the differences introduced when implementors opted to not follow [RFC2388] when encoding non-ASCII field names (perhaps because "may" should have been "MUST"). As a result, parsers need to be more complex for matching against the possible outputs of various encoding methods.
更成问题的是，在编码非ASCII字段名时，实现者选择不遵循[RFC2388]时引入的差异（可能是因为“可能”应该是“必须”）。因此，解析器需要更加复杂，以便与各种编码方法的可能输出进行匹配。
Acknowledgements
致谢
Many thanks to the those who reviewed this document -- Alexey Melnikov, Salvatore Loreto, Chris Lonvick, Kathleen Moriarty, Barry Leiba, Julian Reschke, Tom Petch, Ned Freed, Cedric Brancourt, as well as others, including Ian Hickson, who requested it be produced in the first place.
非常感谢审阅本文件的人员——阿列克谢·梅尔尼科夫、萨尔瓦托·洛雷托、克里斯·朗维克、凯瑟琳·莫里亚蒂、巴里·莱巴、朱利安·雷什克、汤姆·佩奇、内德·弗里德、塞德里克·布兰科，以及其他人，包括伊恩·希克森，他们首先要求制作本文件。
Author's Address
作者地址
Larry Masinter Adobe
拉里·马斯特·奥多比
Email: masinter@adobe.com
URI: http://larry.masinter.net
Email: masinter@adobe.com
URI: http://larry.masinter.net