[要約] RFC 2388は、フォームからの値を返すためのmultipart/form-dataの仕様を定めています。このRFCの目的は、フォームデータを効果的に送信し、処理するための標準化を提供することです。
Network Working Group L. Masinter
Request for Comments: 2388 Xerox Corporation
Category: Standards Track August 1998
Returning Values from Forms: multipart/form-data
フォームから値を返す：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.
Copyright（C）The Internet Society（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.
この仕様は、インターネットメディアタイプmultipart / form-dataを定義しています。これは、さまざまなアプリケーションで使用でき、ユーザーが入力した結果として値のセットを返す方法として、さまざまなプロトコルで転送できます。形。
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.
MultiPart / Form-Dataの定義は、[RFC1867]で最初に設定され、フォームがHTMLで表現され、フォーム値がHTTPまたは電子を介して送信される[HTML40]に組み込まれた、これらのアプリケーションの1つから導出されます。郵便物。この表現は、数多くの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.
ただし、multipart / form-dataは、HTML以外の表現（スプレッドシート、Portable Document Formatなど）を使用して表示されるフォームや、電子メールや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.
メディアタイプmultipart / form-dataは、[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:
「multipart / form-data」には一連のパーツが含まれています。各部分には、コンテンツタイプヘッダー[RFC 2183]が含まれることが期待されます。ここで、タイプは「フォームデータ」であり、ディスポジションには「名前」の（追加の）パラメーターが含まれます。このパラメーターの値は元の値です。フォームのフィールド名。たとえば、パーツにヘッダーが含まれている場合があります。
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タイプと同様に、各パートにはオプションの「Content-Type」があり、デフォルトはtext / plainです。フォームへの入力によってファイルのコンテンツが返される場合、ファイル入力は、適切なメディアタイプ（既知の場合）または「application / octet-stream」として識別されます。単一のフォームエントリの結果として複数のファイルが返される場合、それらは「multipart / form-data」内に埋め込まれた「multipart / mixed」パーツとして表される必要があります。
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.
各部分の値がデフォルトのエンコーディングに準拠していない場合は、各部分がエンコードされ、「content-transfer-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".
他のマルチパートタイプと同様に、どのデータにも発生しない境界が選択されます。フォームの各フィールドは、送信アプリケーションとフォームによって定義された順序で、マルチパートストリームの一部として送信されます。各部分は、元のフォーム内のINPUT名を識別します。メディアタイプがわかっている場合（たとえば、ファイル拡張子やオペレーティングシステムのタイプ情報から推測される場合）、または「アプリケーション/オクテットストリーム」として、各部分に適切なコンテンツタイプのラベルを付ける必要があります。
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.
フォームフィールドの値が単一のファイルではなくファイルのセットである場合、その値は「multipart / mixed」形式を使用して一緒に転送できます。
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エンコーディングです。値がデフォルトのエンコーディングに準拠していない場合は、パーツに提供される値をエンコードし、「content-transfer-encoding」ヘッダを提供する必要がある場合があります。 [詳細については、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.
元のローカルファイル名も、「content-disposition：form-data」ヘッダーの「filename」パラメーターとして、または複数のファイルの場合は「content-disposition：file」ヘッダーで指定できます。サブパートの。送信アプリケーションはファイル名を提供してもよい（MAY）。送信者のオペレーティングシステムのファイル名が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.
multipart / form-dataの各部分は、コンテンツタイプを持つことになっています。フィールド要素がテキストの場合、テキストの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
Joe owes =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トップレベルタイプ「aggregate」、たとえば、aggregate / mixedまたは「packet」のcontent-transfer-encodingを使用することを提案しています。これは便利ですが、「マルチパート」メカニズムは確立されており、送信側クライアントと受信側サーバーの両方で簡単に実装でき、バイナリデータの複数の組み合わせを処理する他の方法と同じくらい効率的です。
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.
multipart / form-dataエンコーディングは、短い値のフィールドが多い場合、オーバーヘッドが大きくなり、パフォーマンスに影響します。ただし、実際には、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を指定する場合があります。この場合、ブラウザがコンテンツ全体ではなく外部データへのポインタをクライアントに送信できるようにする方法はありますか？この機能は、たとえば、「access-type」が「uri」に設定されたタイプ「message / external-body」のデータをクライアントに送信し、リモートデータの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.
フォーム内のフィールドの順序と「multipart / form-data」内の戻り値の順序の関係は、この仕様では定義されていません。また、フォームに同じ名前の複数のフィールドがある場合の処理も定義されていません。 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
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ブラウザー）がmultipart / form-dataを実装および生成するようになりましたが、既存のアプリケーションはapplication / x-url-encoded形式の両方をオプションでサポートする必要がある場合もあります。
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.)
この仕様では、multipart / form-dataを送信の原因となったフォームに関連付けることができる特定のメカニズムは提供されていません。この分離は意図的なものです。同じデータを送信するために、多くの異なる形式が使用される場合があります。実際には、アプリケーションは、フォームごとに特定のフォーム処理リソース（HTMLでは、FORMタグの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.
このドキュメントで説明するデータ形式では、それを使用するプロトコルおよびコンポーネント要素によって導入されるもの以外に、新しいセキュリティ上の考慮事項は導入されていません。 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 '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
Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto、CA 94304
Fax: +1 650 812 4333
EMail: masinter@parc.xerox.com
Appendix A. Media type registration for multipart/form-data
付録A. multipart / form-dataのメディアタイプ登録
Media Type name: multipart
メディアタイプ名：マルチパート
Media subtype name: form-data
メディアサブタイプ名：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.
セキュリティ上の考慮事項フォームを受信してフォームを処理するアプリケーションは、受信者が送信することを意図していないデータを要求元のフォーム処理サイトに返さないように注意する必要があります。これは、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.
multipart / form-dataタイプでは、囲まれたパーツで発生する可能性があること以外に、受信者に新しいセキュリティ上の考慮事項はありません。
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、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、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（Multipurpose Internet Mail Extensions）Part Three：Message Header Extensions for Non-ASCII Text」、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、「Communicating Presentation Information in Internet Messages：The Content-Disposition Header」、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、「Form-based File Upload in HTML」、RFC 1867、1995年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、「インターネットメッセージでのプレゼンテーション情報の伝達：Content-Dispositionヘッダーフィールド」、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/>
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。