Network Working Group L. Masinter
Request for Comments: 2388 Xerox Corporation
Category: Standards Track August 1998
Network Working Group L. Masinter
Request for Comments: 2388 Xerox Corporation
Category: Standards Track August 1998
Returning Values from Forms: multipart/form-data
从表单返回值：多部分/表单数据
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This specification defines an Internet Media Type, multipart/form-data, 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.
本规范定义了一种互联网媒体类型，即多部分/表单数据，可由多种应用程序使用，并可通过多种协议传输，作为用户填写表单时返回一组值的方式。
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 [HTML40], where forms are expressed in HTML, and in which the form values are sent via HTTP or electronic mail. This representation is widely implemented in numerous web browsers and web servers.
多部分/表单数据的定义源自其中一个应用程序，最初在[RFC1867]中提出，随后并入[HTML40]，其中表单以HTML表示，表单值通过HTTP或电子邮件发送。这种表示在许多web浏览器和web服务器中广泛实现。
However, multipart/form-data can be used for forms that are presented using representations other than HTML (spreadsheets, Portable Document Format, etc), and for transport using other means than electronic mail or HTTP. This document defines the representation of form values independently of the application for which it is used.
但是，多部分/表单数据可用于使用HTML以外的表示（电子表格、可移植文档格式等）表示的表单，以及使用电子邮件或HTTP以外的其他方式传输的表单。本文档定义了表单值的表示形式，与所使用的应用程序无关。
The media-type multipart/form-data follows the rules of all multipart MIME data streams as outlined in [RFC 2046]. In forms, there are a series of fields to be supplied by the user who fills out the form. Each field has a name. Within a given form, the names are unique.
媒体类型多部分/表单数据遵循[RFC 2046]中概述的所有多部分MIME数据流的规则。在表单中，填写表单的用户将提供一系列字段。每个字段都有一个名称。在给定的表单中，名称是唯一的。
"multipart/form-data" contains a series of parts. Each part is expected to contain a content-disposition header [RFC 2183] where the disposition type is "form-data", and where the disposition contains an (additional) parameter of "name", where the value of that parameter is the original field name in the form. For example, a part might contain a header:
“多部分/表单数据”包含一系列部分。每个部分都应包含一个内容处置头[RFC 2183]，其中处置类型为“表单数据”，处置包含一个（附加）参数“名称”，其中该参数的值为表单中的原始字段名。例如，零件可能包含标题：
Content-Disposition: form-data; name="user"
Content-Disposition: form-data; name="user"
with the value corresponding to the entry of the "user" field.
与“用户”字段的条目对应的值。
Field names originally in non-ASCII character sets may be encoded within the value of the "name" parameter using the standard method described in RFC 2047.
最初在非ASCII字符集中的字段名可以使用RFC 2047中描述的标准方法在“name”参数的值内编码。
As with all multipart MIME types, each part has an optional "Content-Type", which defaults to text/plain. If the contents of a file are returned via filling out a form, then the file input is identified as the appropriate media type, if known, or "application/octet-stream". If multiple files are to be returned as the result of a single form entry, they should be represented as a "multipart/mixed" part embedded within the "multipart/form-data".
与所有多部分MIME类型一样，每个部分都有一个可选的“内容类型”，默认为text/plain。如果通过填写表单返回文件内容，则文件输入被标识为适当的媒体类型（如果已知），或“应用程序/八位字节流”。如果要返回多个文件作为单个表单条目的结果，则应将其表示为嵌入在“多部分/表单数据”中的“多部分/混合”部分。
Each part may be encoded and the "content-transfer-encoding" header supplied if the value of that part does not conform to the default encoding.
如果每个部分的值不符合默认编码，则可以对每个部分进行编码，并提供“内容传输编码”标题。
As with other multipart types, a boundary is selected that does not occur in any of the data. Each field of the form is sent, in the order defined by the sending appliction and form, as a part of the multipart stream. Each part identifies the INPUT name within the original form. Each part should be labelled with an appropriate content-type if the media type is known (e.g., inferred from the file extension or operating system typing information) or as "application/octet-stream".
与其他多部分类型一样，选择的边界不会出现在任何数据中。表单的每个字段都作为多部分流的一部分，按照发送应用程序和表单定义的顺序发送。每个部分在原始表单中标识输入名称。如果媒体类型已知（例如，从文件扩展名或操作系统键入信息推断），或被称为“应用程序/八位字节流”，则每个部分都应标有适当的内容类型。
If the value of a form field is a set of files rather than a single file, that value can be transferred together using the "multipart/mixed" format.
如果表单字段的值是一组文件而不是单个文件，则可以使用“多部分/混合”格式将该值一起传输。
While the HTTP protocol can transport arbitrary binary data, the default for mail transport is the 7BIT encoding. The value supplied for a part may need to be encoded and the "content-transfer-encoding" header supplied if the value does not conform to the default encoding. [See section 5 of RFC 2046 for more details.]
虽然HTTP协议可以传输任意二进制数据，但邮件传输的默认值是7BIT编码。为零件提供的值可能需要编码，如果值不符合默认编码，则需要提供“内容传输编码”标题。[详见RFC 2046第5节。]
Forms may request file inputs from the user; the form software may include the file name and other file attributes, as specified in [RFC 2184].
表格可要求用户输入文件；表单软件可能包括[RFC 2184]中规定的文件名和其他文件属性。
The original local file name may be supplied as well, either as a "filename" parameter either of the "content-disposition: form-data" header or, in the case of multiple files, in a "content-disposition: file" header of the subpart. The sending application MAY supply a file name; if the file name of the sender's operating system is not in US-ASCII, the file name might be approximated, or encoded using the method of RFC 2231.
原始本地文件名也可以作为“内容处置：表格数据”标题中的“文件名”参数提供，或者，在多个文件的情况下，在子部分的“内容处置：文件”标题中提供。发送应用程序可以提供文件名；如果发送方操作系统的文件名不是US-ASCII格式，则可以使用RFC 2231的方法近似或编码文件名。
This is a convenience for those cases where the files supplied by the form might contain references to each other, e.g., a TeX file and its .sty auxiliary style description.
对于表单提供的文件可能包含相互引用的情况，例如TeX文件及其.sty辅助样式描述，这是一种方便。
Each part of a multipart/form-data is supposed to have a content-type. In the case where a field element is text, the charset parameter for the text indicates the character encoding used.
多部分/表单数据的每个部分都应该有一个内容类型。在字段元素为文本的情况下，文本的charset参数表示使用的字符编码。
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:
例如，用户键入“Joe owes<eu>100”（其中<eu>为欧元符号）的文本字段中的表单可能会将表单数据返回为：
--AaB03x
content-disposition: form-data; name="field1"
content-type: text/plain;charset=windows-1250
content-transfer-encoding: quoted-printable
--AaB03x
content-disposition: form-data; name="field1"
content-type: text/plain;charset=windows-1250
content-transfer-encoding: quoted-printable
Joe owes =80100. --AaB03x
乔欠下了80100英镑--AaB03x
Some of the data in forms may be compressed or encrypted, using other MIME mechanisms. This is a function of the application that is generating the form-data.
表单中的一些数据可以使用其他MIME机制进行压缩或加密。这是生成表单数据的应用程序的函数。
Various people have suggested using new mime top-level type "aggregate", e.g., aggregate/mixed or a content-transfer-encoding of "packet" to express indeterminate-length binary data, rather than relying on the multipart-style boundaries. While this would be useful, the "multipart" mechanisms are well established, simple to implement on both the sending client and receiving server, and as efficient as other methods of dealing with multiple combinations of binary data.
许多人建议使用新的mime顶级类型“聚合”，例如聚合/混合或“数据包”的内容传输编码来表示长度不确定的二进制数据，而不是依赖于多部分样式的边界。虽然这很有用，但“多部分”机制已经建立得很好，在发送客户端和接收服务器上都易于实现，并且与处理二进制数据的多种组合的其他方法一样高效。
The multipart/form-data encoding has a high overhead and performance impact if there are many fields with short values. However, in practice, for the forms in use, for example, in HTML, the average overhead is not significant.
如果有许多字段的值较短，则多部分/表单数据编码具有较高的开销和性能影响。然而，在实践中，对于正在使用的表单，例如HTML中的表单，平均开销并不显著。
In some scenarios, the user operating the form software might want to specify a URL for remote data rather than a local file. In this case, is there a way to allow the browser to send to the client a pointer to the external data rather than the entire contents? This capability could be implemented, for example, by having the client send to the server data of type "message/external-body" with "access-type" set to, say, "uri", and the URL of the remote data in the body of the message.
在某些情况下，操作表单软件的用户可能希望为远程数据指定URL，而不是本地文件。在这种情况下，是否有一种方法允许浏览器向客户端发送指向外部数据而不是整个内容的指针？例如，可以通过让客户端向服务器发送“消息/外部主体”类型的数据，并将“访问类型”设置为（比如）“uri”，以及消息主体中远程数据的URL来实现该功能。
Note that MIME headers are generally required to consist only of 7- bit data in the US-ASCII character set. Hence field names should be encoded according to the method in RFC 2047 if they contain characters outside of that set.
请注意，MIME头通常只需要由US-ASCII字符集中的7位数据组成。因此，如果字段名包含该集合之外的字符，则应根据RFC 2047中的方法对其进行编码。
The relationship of the ordering of fields within a form and the ordering of returned values within "multipart/form-data" is not defined by this specification, nor is the handling of the case where a form has multiple fields with the same name. While HTML-based forms may send back results in the order received, and intermediaries should not reorder the results, there are some systems which might not define a natural order for form fields.
本规范未定义表单中字段的顺序与“多部分/表单数据”中返回值的顺序之间的关系，也未定义表单具有多个同名字段的情况的处理。虽然基于HTML的表单可能会按收到的顺序发回结果，中介机构不应该对结果重新排序，但有些系统可能不会为表单字段定义自然顺序。
Many web applications use the "application/x-url-encoded" method for returning data from forms. This format is quite compact, e.g.:
许多web应用程序使用“application/x-url-encoded”方法从表单返回数据。这种格式非常紧凑，例如：
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 content type, apply a charset, or use other encoding mechanisms.
但是，没有机会使用内容类型标记封闭数据、应用字符集或使用其他编码机制。
Many form-interpreting programs (primarly web browsers) now implement and generate multipart/form-data, but an existing application might need to optionally support both the application/x-url-encoded format as well.
许多表单解释程序（主要是web浏览器）现在实现并生成多部分/表单数据，但现有应用程序可能还需要可选地支持application/x-url编码格式。
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 which is part of the form but which has a fixed value to be transmitted back to the form-data processor.)
本规范未提供多部分/表单数据与导致其传输的表单关联的特定机制。这种分离是有意的；许多不同的形式可用于传输相同的数据。实际上，应用程序可以为每个不同的表单提供特定的表单处理资源（在HTML中，表单标记中的ACTION属性）。或者，关于表单的数据可以编码在“隐藏字段”（作为表单一部分但有固定值要传输回表单数据处理器的字段）中
The data format described in this document introduces no new security considerations outside of those introduced by the protocols that use it and of the component elements. It is important when interpreting content-disposition to not overwrite files in the recipients address space inadvertently.
本文档中描述的数据格式除了使用它的协议和组件元素引入的安全注意事项外，没有引入任何新的安全注意事项。在解释内容配置时，不要无意中覆盖收件人地址空间中的文件，这一点很重要。
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 'spam' information to be sent to an unintended third party, or private information to 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 result of form transmission, 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 user's file space, the possibility that a user might be sent an automated script that fills out a form and then sends the user's local file to another address arises. Thus, additional caution is required when executing automated scripting where form-data might include user's files.
随着表单数据的引入，可以合理地从用户的文件空间发回文件内容，用户可能会收到一个自动脚本，该脚本填写表单，然后将用户的本地文件发送到另一个地址。因此，在表单数据可能包含用户文件的情况下，执行自动脚本时需要额外小心。
Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304
美国加利福尼亚州帕洛阿尔托郊狼山路3333号帕洛阿尔托研究中心
Fax: +1 650 812 4333
EMail: masinter@parc.xerox.com
Fax: +1 650 812 4333
EMail: masinter@parc.xerox.com
Appendix A. Media type registration for multipart/form-data
附录A.多部分/表格数据的媒体类型注册
Media Type name: multipart
媒体类型名称：多部分
Media subtype name: form-data
媒体子类型名称：表单数据
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: No additional considerations other than as for other multipart types.
编码注意事项：除了其他多部分类型之外，没有其他注意事项。
Security Considerations Applications which 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 by the recipient. This is a consideration for any application that generates a multipart/form-data.
安全注意事项接收表单并处理表单的应用程序必须小心，不要向请求表单处理站点提供收件人不打算发送的数据。这是任何生成多部分/表单数据的应用程序都要考虑的问题。
The multipart/form-data type introduces no new security considerations for recipients beyond what might occur with any of the enclosed parts.
多部分/表单数据类型不会为收件人引入任何新的安全注意事项，除了随附的任何部分可能出现的安全注意事项之外。
References
工具书类
[RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC 2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，1996年11月。
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC 2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC 2231] Freed, N., and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC 2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 2231，1997年11月。
[RFC 1806] Troost, R., and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[RFC 1806]Troost，R.和S.Dorner，“在互联网消息中传达呈现信息：内容处置标题”，RFC 1806，1995年6月。
[RFC 1867] Nebel, E., and L. Masinter, "Form-based File Upload in HTML", RFC 1867, November 1995.
[RFC 1867]Nebel，E.和L.Masinter，“基于表单的HTML文件上传”，RFC 18671995年11月。
[RFC 2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC 2183]Troost，R.，Dorner，S.，和K.Moore，“在Internet消息中传递表示信息：内容处置头字段”，RFC 2183，1997年8月。
[RFC 2184] Freed, N., and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997.
[RFC 2184]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 2184，1997年8月。
[HTML40] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
Specification", World Wide Web Consortium Technical Report
"REC-html40", December, 1997. <http://www.w3.org/TR/REC-
html40/>
[HTML40] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
Specification", World Wide Web Consortium Technical Report
"REC-html40", December, 1997. <http://www.w3.org/TR/REC-
html40/>
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。