原典 RFC2388
ftp://ftp.nic.ad.jp/rfc/rfc2388.txt
翻訳 98.9.14
http://www.bekkoame.ne.jp/%7Epoetlabo/WWW/rfc2388J.html
訳文に関するご意見はHTML研究室専用掲示板へどうぞ
Copyleft: 1998, 魔術幻燈
Network Working Group
Request for Comments: 2388
Category: Standards Track
L. Masintert
Xerox Corporation
August 1998
この文書は、インターネット社会のためのインターネット標準過程作法を決めるもので、改良のための議論や教示を求めます。この作法の標準化の状況と現状については、『Internet Official Protocol Standards 』(STD 1)の最新版を参照してください。この書き付けの配布は無制限です。
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.
Copyright (C) The Internet Society (1998). All Rights Reserved.
この仕様書は、インターネット伝送種別multipart/form-dataを定義するものです。これは、利用者が書式へ書き込んだ結果を返すための値のセットとして、種々さまざまな作法で転送し、種々さまざまなアプリケイションで使うことができます。
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.
MultiPart/Form-Dataの定義はそのようなアプリケーションの一つに由来するものです。これは当初 [RFC 1867]で設定され、後に[HTML40]に組み入れられました。[HTML40]では書式はHTMLで表現され、書式の値はHTTPか電子メールで送られます。この表現は、数多くの web ブラウザや web サーバで幅広く実装されています。
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はHTML以外の表現形式（表計算ソフト、PDFなど）で表示される書式で利用し、電子メールかHTTP以外の方法で送ることも可能です。この文書は、使用されるアプリケーションには依存しない書式の値の表現形式を定めるものです。
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伝送種別は、[RFC 2046] で概説された多元 MIME データ流れに関する全ての規則に従います。書式には、書式に記入する利用者によって供述されるはずの一揃いの項目があります。それぞれの項目には名前があります。与えられた書式の範囲内では、名前は重複しません。
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"は、一連の部品からなります。各部品は、性質タイプが"form-data"であり、性質が"name"の（追加的な）パラメーターを含み、そのパラメーターの値が書式での元のフィールド名である内容-性質ヘッダ[RFC 2183]を含むことになっています。例えば、部品には次のような頭を含めてかまいません。
"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:
Content-Disposition: form-data; name="user"
この値は"user"項目の記載に対応します。
with the value corresponding to the entry of the "user" field.
非ASCII 文字セットによる元の項目の名前は、[RFC 2047] で描写された標準方式を使って、"name"パラメーターの値の範囲内で符号化してかまいません。
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.
全ての多元MIME種別と同様、それぞれの部品は追加的な "Content-Type" を持ち、その既定値はtext/plainです。
書式に記入することによってファイルの内容が返されるとき、既知のものであるか、 "application/octet-stream" であるならば、ファイル入力は適切なメディアタイプであることがわかります。
単一の書式記載の結果としてマルチファイルが返されたなら、それは"multipart/form-data"の中に埋め込まれた"multipart/mixed"部品として表わされるべきです。
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".
各部品は符号化してかまいません。また、もしその部品が既定の符号化になっていなければ、"content-transfer-encoding"ヘッダを補充します。
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.
他の多元種別と同様、境界線にはデータ中に見い出されないようなものが選ばれます。書式のそれぞれの項目は、送信アプリケーションと書式で定められた順序で、多元ストリームの一部として送られます。各部品は元の書式にあるINPUT名で区別されます。伝送種別が（ファイルの拡張子やOSの種別情報から判断できる場合など）既知のものであるか、"application/octet-stream"であるなら、各部品には適切なcontent-typeを貼りつけておくべきです。
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".
書式の項目の値が単一のファイルでなく組になったファイルであるとき、その値を "multipart/mixed"形式を用いて一緒に転送することが可能です。
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.
HTTP作法ではバイナリを転送することができますが、メール転送の既定値は7ビット符号です。一部品の供出される値は符号化される必要があるかもしれません。また、値が既定の符号化になっていないときには、"content-transfer-encoding"ヘッダが補充されるかもしれません。[詳しくは RFC 2046 の第5項を見てください。]
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.]
書式は利用者からのファイル入力を要請することができます。書式ソフトウェアは[RFC 2184]にあるとおり、ファイル名や他のファイル属性を取り込むことができます。
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].
手元にある元のファイル名が"content-disposition: form-data"ヘッダか、或いはマルチファイルの場合は副部品の"content-disposition: file"ヘッダのいずれかで、"filename"パラメーターとして附加されることもあるでしょう。
送信アプリケーションがファイル名を附加することもあります。すなわち、送り主のオペレーティング・システム上のファイル名がUS-ASCIIでないときは、ファイル名前は近似されるか、 [RFC 2231] の方法を使って符号化されることがあります。
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.
これは、書式から供給されたファイルが、TeXファイルとその.sty補助スタイル記述など、相互参照を含んでいるような場合には便利です。
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.
multipart/form-dataの各部分は、content-typeを持つはずです。項目の要素の一つが文章になっていたら、その文章のcharsetパラメーターは使われた文字符号化方式を示します。
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.
例えば、記入項目を持つ書式に利用者が「Joe owes <eu>100」と打ち込んだとして、<eu>がEuro symbolのとき書式データは以下のように返されるでしょう。
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:
--AaB03x
content-disposition: form-data; name="field1"
content-type: text/plain;charset=windows-1250
content-transfer-encoding: quoted-printable
Joe owes =80100.
--AaB03x
書式データのあるものは、他のMIME機構を使って圧縮あるいは暗号化されてかまいません。これは書式データを生成するアプリケーションの機能です。
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 トップ-レベルタイプ『総計』を使うことを提案している人は少なくありません。
例えば、 可変長バイナリデータを表わすのに多元スタイル境界線に頼るよりもaggregate/mixed か "packet"のcontent-transfer-encoding にするのです。
これは確かに有用ですが、"multipart"機構は十分に確立されたものであり、送っているクライアントと受けるサーバの両方で実装が簡単であり、バイナリデータのマルチ結合を取り扱う他の方法と同じくらい効果的です。
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.
multipart/form-data符号化は、数多くの項目に短い値がある場合には、高いoverheadと作業能率の低下を招きます。しかしながら実際の書式使用時には、例えばHTMLでは、平均overheadは大したことはありません。
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.
筋書きによっては、受け手側ソフトウェアを操作する利用者は、手元にあるファイルでなく離れた場所にあるデータのURL指定を望むかもしれません。このような場合に、その外部データそのものでなくポインタを、書見機が受け手側へ送るようにできる方法があるでしょうか？この能力は、例えば受け手側に、"message/external-body" タイプのデータに "access-type" をセットして、それに"uri"とメッセージ本体にある外部データのURLを、送り手側へ送らせるような実装ができるでしょう。
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.
MIMEヘッダは一般に7ビットデータのみからなるUS-ASCII文字セットでなければならないことに注意してください。従って、項目の名がこれ以外の文字セットによる文字を含んでいるときには、項目の名は[RFC 2047]にある方式によって符号化されることになります。
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.
書式での項目の配列と"multipart/form-data"で返された値の配列との関係は、この仕様書では定義しませんし、書式が同一の名によるマルチ項目を持つ場合の取り扱いについても定義しません。
HTMLに基く書式が、受け取った順に結果を送り返せるのに対して、書式項目の自然な配列を定義していないであろうシステムもありますので、中間段階で結果を並べ換えることはないでしょう。
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.
多くのWebアプリケーションでは、書式からデータを返すのに"application/x-url-encoded" 方式を使います。この形式は次に示すとおり、たいへん簡潔です。
Many web applications use the "application/x-url-encoded" method for returning data from forms. This format is quite compact, e.g.:
name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send
しかしながらこれでは、囲ったデータにcontent typeを貼って文字セットを入れたり他の符号化機構を使ったりする余裕がありません。
however, there is no opportunity to label the enclosed data with content type, apply a charset, or use other encoding mechanisms.
今日の多くの form-interpreting プログラム（基本的にはweb ブラウザ）は、multipart/form-data を実行し、生成できます。しかし現存するアプリケーションのためには、別にapplication/x-url-encoded フォーマットでもいいようにしておく必要があるでしょう。
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.
この仕様書は、multipart/form-data を伝達されるべき書式に結び付けるための具体的な機構は与えません。
この分離は意図的なものです。というのは、同じデータを伝えるための多くの異なる書式が使用されるであろうからです。
実際、アプリケーションは各々異なる書式のための具体的な書式加工処理リソース（ HTML では、 FORM タグ中の ACTION 属性）を供給することでしょう。
代わりに、書式についてのデータを"hidden field"（書式の一部であるが書式-データプロセッサーに対して固定的な値を伝える項目）で符号化できます。
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.)
この文書で述べられるデータ形式は、これを使う作法やその構成要素で紹介される以外の新規な安全性への配慮を齎すものではありません。
content-dispositionを解釈する際、不注意に受取人アドレス空間中のファイルを書き換えてしまわないことが重要です。
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.
利用者から書式情報を求める利用者アプリケーションは、利用者が不本意にか知らないうちに請求者や第三者へ情報を送ることがないように気を付けなければなりません。
例えば、書式は「 spam 」情報を求めて知りもしない団体に送ってしまったり、個人的な情報を求めて利用者が知らない誰かに送ってしまうことが有り得ます。
これが書式伝達結果のデータ表現よりも主に書式自体の表現と解釈の問題であるのに対し、個人的な情報の輸送は、望まれない詮索にさらされない方法でなされなければなりません。
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.
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.
Copyright (C) The Internet Society (1998). All Rights Reserved.
この文書とその翻訳については、写しを取ったり、配って回ったりしてかまいません。これらについて批評もしくは説明したり、あるいはその普及を助ける等の派生的作業については、上記の著作権表示とこの文章を含むものはすべて、その全部または一部を、一切の制約なしに、用意し、謄写し、出版・配布してかまいません。
しかしながら、この文書自体は、いかなる方法にせよ変更してはなりません。インターネット標準化過程において定義されている著作権のための手続きに従ってインターネット標準を開発するために必要とされる、あるいは英語以外の言語に翻訳する必要があるという場合を除き、著作権表示あるいはインターネット協会の参考文献あるいは他のインターネット組織への参照を抹消するなどの改竄を禁じます。
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.
この文書とここに含まれる情報は、「AS IS（あるがまま）」の原則に則って提供され、インターネット協会と IETF は、明示されているか否かに関わらず、内容について保証しません。
無保証の範囲には、ここにある情報の使用がいかなる権利も侵害しないという保証や市場性あるいは特定の目的に対する適合性についてのあらゆる暗黙の保証をはじめとするすべての保証が含まれます。
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.