#?SuikaWiki/0.9 page-icon="HTML"
'''Returning Values from Forms [INS[フォームから返される値]]: multipart/form-data'''
-Network Working Group
-Request for Comments: 2388
-Category: Standards Track
- L. Masinter
- Xerox Corporation
- August 1998
*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.
*Copyright Notice
> Copyright (C) The Internet Society (1998). All Rights Reserved.
*1. Abstract
> 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.
この仕様書は、 [CODE(MIME)[[[multipart/form-data]]]]
という、利用者がフォーム (入力欄)
に記入した結果を値の集合として返す手段として、
種々様々の応用が種々様々のプロトコルによって転送することのできるインターネット媒体型を定義します。
*2. Introduction
> 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 の定義は、そのような応用の1つから派生したもので、
元々は [[RFC1867]] で出発し、後に [[HTML4.0]]
に組み込まれた、フォームは [[HTML]] で表現され、
そのフォーム値が [[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.
しかしながら、 [CODE(MIME)[multipart/form-data]]
は HTML 以外の表現 (表計算, 可搬文書書式 (PDF) など)
を使って提示されるフォームについてや、電子メイル又は HTTP
以外の手段を使った転送についても用いることができます。
この文書は、その使用する応用からは独立したフォーム値の表現を定義します。
*3. Definition of multipart/form-data
> 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.
媒体型 [CODE(MIME)[multipart/form-data]] は、 [[RFC2046]]
で概説されている全複数部分 (multipart) MIME データ流の規則に従います。
フォームには、フォームに記入した利用者によって供給された欄 (field)
の系列があります。各欄には名前があります。
あるフォームの中では、名前は唯一無二です。
> "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:
[CODE(MIME)[multipart/form-data]] は部分 (part) の系列を含みます。
各部分は配置型が [CODE(MIME)[[[form-data]]]] である
[CODE(MIME)[content-disposition]] (内容配置) 頭 (header)
を含むことを想定します。この配置指定は (追加の)
引数 [CODE(MIME)[[[name]]]] を含んでおり、
この引数の値が元のフォーム中の欄の名前です。
例えば、ある部分は次のような頭を含んでいるかもしれません。
>
-[SAMP(MIME)[[[Content-Disposition]]: form-data; name="user"]]
> with the value corresponding to the entry of the "user" field.
この部分は [SAMP[user]] 欄の項目に対応する値を持っています。
> 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]] 文字集合で書かれていた欄名は、 [CODE(MIME)[name]]
引数の値の中では [[RFC2057]] で説明されている標準の方式を使って符号化しても構いません
(may)。
> 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 型について、各部分は任意選択の
[CODE(MIME)[[[Content-Type]]]] があって、その既定値は
[CODE(MIME)[[[text/plain]]]] になっています。
ファイルの内容がフォームの記入によって返される時には、
適切な媒体型が分かっていればそれで識別するか、
又は [CODE(MIME)[[[application/octet-stream]]]]
とします。単一のフォーム項目の結果として複数のファイル群を返す時には、
[CODE(MIME)[multipart/form-data]] 中に埋め込まれた
[CODE(MIME)[[[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.
各部分の値が既定の符号化に適合しないなら、
その部分は符号化して [CODE(MIME)[content-transfer-encoding]]
頭をつけても構いません。
*4. Use of multipart/form-data
**4.1 Boundary
> 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".
他の複数部分型同様に、境界 (boundary)
はデータのどこにも現れないものを選びます。
フォームの各欄は、送信する応用とフォームにより定義された順序により、
複数部分流の部分として送信します。
各部分は元のフォーム中の''入力''名を識別します。
各部分の媒体型が分かっている場合
(例えばファイル拡張子やオペレーティング・システムの型情報から推測できる場合)
には適当な内容型で、そうでない場合には [CODE(MIME)[application/octet-stream]]
として札付けするべきです。
**4.2 Sets of files
> 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.
フォーム欄の値が単一のファイルではなく複数のファイルの集合であるなら、
その値は [CODE(MIME)[multipart/mixed]] 書式を使って一緒に転送できます。
**4.3 Encoding
> 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 プロトコルは任意のバイナリ・データを転送できますが、
メイル転送の既定値は [CODE(MIME)[7BIT]] 符号化です。
部分に供給される値は、その値が既定符号化に適合しなければ、
符号化して [CODE(MIME)[content-transfer-encoding]]
頭をつける必要があるかもしれません。
(詳細については RFC 2046 の5章を参照。)
**4.4 Other attributes
> 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].
フォームは利用者からのファイル入力を要求するかもしれません。
フォーム・ソフトウェアは [[RFC2184]] で規定されているようにしてファイル名や他のファイル属性を含めても構いません。
> 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.
元の局所ファイル名は、 [CODE(MIME)[content-disposition: form-data]]
頭の [CODE(MIME)[[[filename]]]] 引数として、又は複数ファイル群の場合には、
その小部分の [CODE(MIME)[content-disposition: file]]
頭において、同様に供給してもかまいません。
送信する応用はファイル名を供給しても'''構いません'''。
送信者のオペレーティング・システムのファイル名が [[US-ASCII]]
でないなら、ファイル名は近似するか、 [[RFC2231]]
の方法を使って符号化しても構いません。
> 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 追加スタイル記述のような場合には便利です。
**4.5 Charset of text in form data
> 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.
[CODE(MIME)[multipart/form-data]] の各部分は [CODE(MIME)[content-type]]
を持つことになっています。
欄要素が文 (text) である場合には、その文の
[CODE(MIME)[[[charset]]]] 引数は使用されている文字符号化を示します。
> For example, a form with a text field in which a user typed 'Joe owes
100' where is the Euro symbol might have form data returned as:
例えば、 [CODE[]] をユーロ記号として、
利用者が [SAMP[Joe owes 100]] (Joe は 100 ユーロ借りている)
と打鍵した文欄のあるフォームでは次のようなフォーム・データが返されるでしょう。
[PRE[
--AaB03x
content-disposition: form-data; name="field1"
content-type: text/plain;charset=windows-1250
content-transfer-encoding: quoted-printable
Joe owes =80100.
--AaB03x
]PRE]
*5. Operability considerations
**5.1 Compression, encryption
> 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 の機構を使って圧縮したり暗号化されたりすることがあるかもしれません。
これは [CODE[form-data]] を生成する応用の機能です。
**5.2 Other data encodings rather than 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.
色々な人が、新しい mime 最上位型 [CODE(MIME)[aggregate]] (修正)
を使って例えば [CODE(MIME)[aggregate/mixed]] としたり、
不定長バイナリ・データの表現に複数部分様式の境界に依存するのではなく
[CODE(MIME)[packet]] 内容転送符号化を使ったりすることを提案しています。
これは有用かもしれませんが、 [CODE(MIME)[multipart]]
機構はよく確立しており、送信するクライアント及び受信するサーバーの両方を実装するのが簡単であり、
バイナリ・データの複数の組合せを処理する他の方式と同じくらい有効です。
> 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.
[CODE(MIME)[multipart/form-data]] 符号化は、多くの欄と短い値の場合は高いオーバーヘッドと効率への打撃があります。
しかし、実際上、例えば HTML で使われるフォームでは、
平均オーバーヘッドは重要ではありません。
**5.3 Remote files with third-party transfer
> 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]] を指定したいと思うかもしれません。この場合、
ブラウザがクライアントに内容全体ではなく外部データの指示子を送ることができる方法があるでしょうか。
この能力は、例えばクライアントがサーバーに、
[CODE(MIME)[[[access-type]]]] が、そう、 [CODE(MIME)[uri]]
に設定されて、メッセージの本体に遠隔データの URL
が入った型 [CODE(MIME)[[[message/external-body]]]]
のデータを送ることで実装できます。
**5.4 Non-ASCII field names
> 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 の方式に従って符号化するべきです。
**5.5 Ordered fields and duplicated field names
> 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.
フォーム中の欄の順序と [CODE(MIME)[multipart/form-data]]
中で返される値の順序の関係は、この仕様書においては定義しませんし、
フォームが同じ名前の複数の欄を持っているときの取扱いについても定義しません。
HTML を基にしたフォームは受信した順序で結果を送り返し、
中間では結果を並べ替えるべきではありませんが、
フォームの欄の自然な順序を定義していないシステムもあるかもしれません。
**5.6 Interoperability with web applications
> Many web applications use the "application/x-url-encoded" method for
returning data from forms. This format is quite compact, e.g.:
多くのウェブ応用はフォームからのデータを返すのに
[CODE(MIME)[[[application/x-url-encoded]]]] 方式 [INS[(訳注 : 普通は [CODE(MIME)[[[application/x-www-urlencoded]]]] だけど、検索してみると確かに用例はある。)]]
を使います。この書式はとても簡潔で、例えば
>
- [SAMP[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.
しかし、内容型を札付けしたり charset を適用したり他の符号化方式を使ったりする方法はありません。
> 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.
多くのフォーム解釈プログラム (主としてウェブ・ブラウザ)
は今は [CODE(MIME)[multipart/form-data]] を実装・生成しますが、
既存の応用は任意選択で [CODE(MIME)[application/x-url-encoded]]
書式も同様に対応する必要があることでしょう。
**5.7 Correlating form data with the original form
> 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.)
この仕様書は、 [CODE(MIME)[multipart/form-data]]
を転送することとするフォームに関連付ける特定の方法を用意していません。
この分離は意図的なものでして、多くの異なるフォームが同じデータを転送するのに使われるかもしれません。
実際上、応用は特定のフォーム処理資源 (HTML では、
[CODE(HTML)[FORM]] タグの [CODE(HTML)[ACTION]] 属性)
を各々異なる書式に供給しても構いません。
代わりに、フォームについてのデータが「隠し欄」
(フォームの一部であるが、フォーム・データ処理器に送り返される固定値を持ったもの)
に符号化されるかもしれません。
*6. Security Considerations
> 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.
この文書で説明したデータ書式は、
これを使うプロトコル及び構成部品要素のプロトコルによるもの以外で新たな安全上の考慮点を増やしてはいません。
[CODE(MIME)[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.
利用者からのフォーム情報を要求する利用者応用は、
利用者が不意のうちあるいは知らぬ間に要求者や第3者に情報を送信してしまわないように注意しなければなりません。
例えば、フォームは意図せぬ第3者に「スパム」情報を送ることを要求するかもしれませんし、
誰か利用者が実際には意図していない人に個人情報を送ることを要求するかもしれません。
これは主としてフォーム自体の表現と解釈の問題であってフォーム転送の結果のデータ表現ではないのですが、
個人情報の転送は望まない覗きに晒してしまうことがないような方法で行われなければなりません。
> 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.
道理的に利用者のファイル空間のファイルの内容を送り返すことができる
[CODE(MIME)[form-data]] の導入で、利用者にフォームを記入して利用者の手元のファイルを他の番地に送る自動化スクリプトを送られてくる可能性があります。
従って、 [CODE(MIME)[form-data]] が利用者のファイルを取込むかもしれないときには自動化スクリプトの実行時に追加の警告が必要です。
*7. Author's Address
[PRE[
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
]PRE]
*Appendix A. Media type registration for multipart/form-data
>
: 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.
フォームを受信して処理する応用は、受信者が送信することを意図しない要求フォーム処理サイトにデータを送り返すことが無いよう注意しなければなりません。
これは [CODE(MIME)[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.
[CODE(MIME)[multuipart/form-data]] 型は、
囲まれた部分に出現するもの以上の利用者に対する新しい安全性についての注意点はありません。
*References
[RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC 2231] Freed, N., and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997.
[RFC 1806] Troost, R., and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header", RFC 1806, June 1995.
[INS[
訳注 : RFC 1806 は RFC 2183 によって廃止されました。
]INS]
[RFC 1867] Nebel, E., and L. Masinter, "Form-based File Upload in
HTML", RFC 1867, November 1995.
[INS[
訳注 : RFC 1867 は [[RFC2854]] によって廃止されました。
]INS]
[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 2184] Freed, N., and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2184, August 1997.
[INS[
訳注 : RFC 2184 は RFC 2231 によって廃止されました。
]INS]
[HTML40] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
Specification", World Wide Web Consortium Technical Report
"REC-html40", December, 1997.
[INS[
訳注 : HTML 4.0 は HTML 4.01 によって廃止されました。
最新の HTML 4 は を参照。
]INS]
*Full Copyright Statement
> Copyright (C) The Internet Society (1998). All Rights Reserved.
See [[RFCのライセンス]]
* memo