[要約] RFC 7578は、multipart/form-data形式のフォームからの値の返却方法についての仕様です。このRFCの目的は、フォームデータの送信と受信のための標準化を提供することです。
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
フォームから値を返す：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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
multipart / form-dataの定義は、[RFC1867]で最初に設定されたアプリケーションの1つから派生し、フォームがHTMLで表現されるHTML 3.2 [W3C.REC-html32-19970114]に組み込まれ、フォームデータ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.
ただし、multipart / form-dataは、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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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エンコーディングの各バイトは、パーセント記号（％）の後にそのバイトの（大文字と小文字を区別しない）16進数が続きます。
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.
フォームの表現と解釈、およびフォーム処理の性質は、このドキュメントでは指定されていません。ただし、multipart / form-dataが生成されるフォームおよびフォーム処理については、いくつかの提案が含まれています。
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).
multipart / form-dataで機能するフォームでは、フィールド名は任意の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.
メディアタイプmultipart / form-dataは、[RFC2046]のセクション5.1で指定されているマルチパートMIMEデータストリームのモデルに従います。変更点はこのドキュメントに記載されています。
A multipart/form-data body contains a series of parts separated by a boundary.
multipart / form-dataボディには、境界で区切られた一連のパーツが含まれます。
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」パラメーターの値を使用して構築された境界区切り文字で区切られます。境界は、multipart / form-dataタイプへの「boundary」パラメーターとして提供されます。 [RFC2046]のセクション5.1に記載されているように、境界区切り文字はカプセル化された部分の内部に表示してはならず、「境界」パラメーター値をContent-Typeヘッダーフィールドで引用符で囲む必要があることがよくあります。
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:
各パーツには、Content-Dispositionヘッダーフィールドが含まれている必要があります[RFC2183]。ここで、処理タイプは「フォームデータ」です。 Content-Dispositionヘッダーフィールドには、「name」の追加パラメーターも含める必要があります。 「name」パラメータの値は、フォームの元のフィールド名です（エンコードされている可能性があります。セクション5.1を参照）。たとえば、パーツには次のようなヘッダーフィールドが含まれ、パーツの本文には「ユーザー」フィールドのフォームデータが含まれます。
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」パラメーターを使用して、ファイルの名前も指定する必要があります（SHOULD）。ファイル名が使用できない、または意味がないかプライベートである場合、ファイル名は必須ではありません。これは、たとえば、選択またはドラッグアンドドロップが使用された場合、またはフォームデータコンテンツがデバイスから直接ストリーミングされた場合に発生する可能性があります。
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.
「filename」パラメータが指定されている場合、「RFA2183」のセクション2.3の「受信MUA」（つまり、受信メールユーザーエージェント）に関する要件は、multipart / form-dataの受信者にも適用されます。ファイルを使用しないでください盲目的に名前を付け、該当する場合はローカルファイルシステムの規則に合わせてチェックし、場合によっては変更し、存在する可能性のあるディレクトリパス情報を使用しないでください。
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に制限されています。それらのシステムとの互換性のために、ユーザーに通常表示されるファイル名は、「file：」URI [URI-SCHEME]のエンコード方法に従って、セクション2のパーセントエンコード方式を使用してエンコードされる場合があります。
NOTE: The encoding method described in [RFC5987], which would add a "filename*" parameter to the Content-Disposition header field, MUST NOT be used.
注：Content-Dispositionヘッダーフィールドに「filename *」パラメーターを追加する、[RFC5987]で説明されているエンコード方法は、使用してはなりません（MUST NOT）。
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範囲外のオクテットを含め、ファイル名が直接エンコードされたmultipart / form-dataを使用しています。 HTMLフォームはフォームに関連付けられた文字セットを使用しますが、ファイル名に使用されるエンコードは通常UTF-8です。
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]は、単一のフォームフィールドの複数のファイルを、ネストされた「multipart / mixed」パーツを使用して送信することを提案しました。この使用法は非推奨です。
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.
広く展開されている実装と一致させるには、各ファイルを別々の部分に指定して、すべて同じ「名前」パラメーターを指定して、複数のファイルを送信する必要があります。
Receiving applications intended for wide applicability (e.g., multipart/form-data parsing libraries) SHOULD also support the older method of supplying multiple files.
幅広い適用性を目的とした受信アプリケーション（例：multipart / form-data解析ライブラリ）は、複数のファイルを提供する古い方法もサポートする必要があります（SHOULD）。
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".
各パーツには（オプションの）「Content-Type」ヘッダーフィールドがあり、デフォルトは「text / plain」です。ファイルの内容を送信する場合、ファイルデータには、適切なメディアタイプ（わかっている場合）または「application / octet-stream」でラベルを付ける必要があります（SHOULD）。
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」Content-Typeのcharsetパラメータを使用して、その部分で使用される文字エンコーディングを示すことができます（MAY）。たとえば、ユーザーが「Joe owes <eu> 100」と入力したテキストフィールドを含むフォーム（<eu>はユーロ記号）には、フォームデータが次のように返される場合があります。
--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
Joe owes = 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を含む）には、フォームを開いたときに、エントリ名が "_charset_"でタイプが "hidden"のフォームエントリの値が自動的に設定されるという規則があります。値はテキストフィールド値のデフォルトの文字セットとして使用されます（セクション5.1.2のform-charsetを参照）。そのような場合、charsetパラメータのない各「text / plain」部分のデフォルトのcharsetの値が、提供される値です。例えば：
--AaB03x content-disposition: form-data; name="_charset_"
--AaB03x content-disposition：form-data; name = "_ charset_"
iso-8859-1 --AaB03x-- content-disposition: form-data; name="field1"
iso-8859-1 --AaB03x-- content-disposition：form-data; 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部分ごとに送信側がContent-Transfer-Encodingエンコーディング（「quoted-printable」など）を使用することが推奨されていました。 7ビット」エンコーディング。この使用は、HTTPなどのバイナリデータをサポートするコンテキストでの使用は非推奨です。送信者は、Content-Transfer-Encodingヘッダーフィールドを持つパーツを生成してはなりません（SHOULD NOT）。
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.
multipart / form-dataメディアタイプは、Content-Type、Content-Disposition、および（限られた状況では）Content-Transfer-Encoding以外のパーツの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]は[ASCII以外のフィールド名を[RFC2047]の方法に従ってエンコードすることを提案しましたが、この方法は広く行われていないようです。
This specification makes three sets of recommendations for three different states of workflow.
この仕様は、ワークフローの3つの異なる状態に対して3セットの推奨事項を作成します。
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を統一して使用する必要があります（SHOULD）。これにより、相互運用性の問題が最小限に抑えられます。
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
この仕様の一部のアプリケーションは、multipart / form-data本体の解釈に使用される文字エンコードを提供します。特に、HTML 5 [W3C.REC-html5-20141028]は
o the content of a "_charset_" field, if there is one;
o 「_charset_」フィールドの内容（存在する場合）。
o the value of an accept-charset attribute of the <form> element, if there is one;
o <form>要素のaccept-charset属性の値（存在する場合）。
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範囲外の文字を使用するフィールド名、フィールド値、または（ "text / plain"）フォームデータのテキストは、フォーム文字セットで直接エンコードして表すことができます（MAY）。
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]:
この仕様はmultipart / form-dataの作成に関するガイダンスを提供しますが、パーサーとインタープリターはさまざまな実装に注意する必要があります。たとえば、ファイルシステムは、Unicode名を正規化するかどうか、および正規化する方法が異なります。フォーム要素とフォームデータパーツのマッチングは、あいまいなマッチングに依存する場合があります。特に、一部のmultipart / form-dataジェネレーターは、[RFC2388]の以前のアドバイスに従って、[RFC2047]で説明されているように、非ASCII値をエンコードする「エンコードされたワード」メソッドを使用した可能性があります。
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を送信する、またはform-charsetでエンコードされた文字列を送信することさえ知られています。
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.
このため、（適合ジェネレーターからであっても）multipart / form-dataを解釈するには、「text / plain」Content-Typeヘッダーフィールドの_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
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ブラウザー）がmultipart / form-dataを実装および生成するようになりましたが、受信アプリケーションも「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).
この仕様は、multipart / form-dataを送信するフォームに関連付けることができる特定のメカニズムを提供しません。この分離は意図的なものです。同じデータを送信するために、多くの異なる形式が使用される場合があります。実際には、アプリケーションは、フォームごとに特定のフォーム処理リソース（HTMLでは、FORMタグの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.
multipart / form-dataのメディアタイプ登録は、セクション8のテンプレートを使用して、このドキュメントを指すように更新されました。さらに、「name」パラメーターの登録と「Content Disposition」の「form-data」値値とパラメータ」レジストリは、このドキュメントを指すように更新されました。
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ブラウザでは、フォームの「自動入力」機能が広く使用されています。これらは、ユーザーをだまして、他の無害なタスクを完了するときに、知らずに機密情報を送信するように仕向ける可能性があります。 multipart / form-dataは、整合性のチェック、機密性の保証、ユーザーの混乱の回避、またはその他のセキュリティ機能を提供しません。これらの懸念は、フォーム入力およびフォームデータ解釈アプリケーションで対処する必要があります。
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.
Content-Dispositionヘッダーフィールドのファイル名を解釈するときに、受信者のファイルスペース内のファイルを誤って上書きしないことが重要です。
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.
ユーザーのファイルスペースからファイルのコンテンツを合理的に送信できるフォームデータの導入により、ユーザーはフォームに入力してユーザーのローカルファイルの1つを別のローカルファイルに送信する自動スクリプトを送信される可能性があります。住所。したがって、フォームデータにユーザーのファイルが含まれる可能性がある自動スクリプトを実行する場合は、さらに注意が必要です。
Files sent via multipart/form-data may contain arbitrary executable content, and precautions against malicious content are necessary.
multipart / form-dataを介して送信されるファイルには、任意の実行可能なコンテンツが含まれる可能性があり、悪意のあるコンテンツに対する予防策が必要です。
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の考慮事項は、Content-Dispositionヘッダーフィールドの「filename」パラメーターに関して、ここでの使用にも適用されます。
This section is the media type registration using the template from [RFC6838].
このセクションは、[RFC6838]のテンプレートを使用したメディアタイプの登録です。
Type name: multipart
タイプ名：マルチパート
Subtype name: form-data
サブタイプ名：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.
エンコードに関する考慮事項：一般的な使用法はBINARYです。限られた用途（またはエンコードを7ビットまたは8ビットに制限するトランスポート）では、各部分はContent-Transfer-Encodingを使用して個別にエンコードされます。セクション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
Person & email address to contact for further information: Author of this document.
詳細について連絡する人と電子メールアドレス：このドキュメントの作成者。
Intended usage: COMMON
使用目的：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、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、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]ムーアK。、「MIME（多目的インターネットメール拡張）パート3：非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、編、「インターネットメッセージでのプレゼンテーション情報の伝達：Content-Dispositionヘッダーフィールド」、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、「Uniform Resource Identifier（URI）：Generic Syntax」、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。、「Returning Values from Forms：multipart / form-data」、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]カーウィン、M。、「ファイルURIスキーム」、作業中、draft-ietf-appsawg-file-scheme-02、2015年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。、「HTML 3.2 Reference Specification」、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] Hickson、I.、Berjon、R.、Faulkner、S.、Leithead、T.、Navara、E.、O'Connor、E.、and S. Pfeiffer、 "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フィールド名を直接送信し、ファイル名をform-charsetで直接送信することをお勧めします。
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]のネストされた「multipart / mixed」を使用する方法は、送信者の既知の実装がないため、作成者には推奨されておらず、受信者には必要ありません。
The _charset_ convention and use of an explicit "form-data" charset is documented; also, "boundary" is now a required parameter in Content-Type.
_charset_規約と明示的な「フォームデータ」文字セットの使用法が文書化されています。また、「boundary」はContent-Typeの必須パラメーターになりました。
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.
フォーム内のフィールドの順序とmultipart / form-data内の戻り値の順序の関係は以前には定義されておらず、フォームに同じ名前の複数のフィールドがある場合の処理も行われていませんでした。
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に記載されています。 multipart / form-dataエンコーディングは冗長です。特に、短い値を持つフィールドが多い場合はそうです。ほとんどの使用例では、このオーバーヘッドは重要ではありません。
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