rfc1867J 魔術幻燈版 原典 RFC1867 ftp://ds.internic.net/rfc/rfc1867.txt 98.2.14 翻訳開始 98.4.15 翻訳終了 http://www.bekkoame.ne.jp/~poetlabo/WWW/rfc1867J.html Copyleft: 1998, 魔術幻燈 poetlabo@cap.bekkoame.ne.jp 引用・転載・複写・盗作その他の活用を歓迎します ---------------------------------------------------------------------- Network Working Group Request For Comments: 1867 Category: Experimental E. Nebel L. Masinter Xerox Corporation November 1995 HTMLにおける書式からのファイル上納 Form-based File Upload in HTML この書き付けの位置付け Status of this Memo この書き付けは、インターネット社会のための実験的な作法を定義するものです。 この書き付けは、その種類を問わず、インターネット標準を決めるものではありま せん。改良のための議論や提案が求められます。この書き付けの配布は無制限です。 This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. 1. 概要 Abstract 2. ファイル送信を伴うHTML書式 HTML forms with file submission 3. 実装のヒント Suggested implementation 1. ファイル操作部の表示 Display of FILE widget 2. 送信時の動作 Action on submit 3. multipart/form-dataの使用 use of multipart/form-data 4. 他の属性の解釈 Interpretation of other attributes 4. 逆行適合性問題 Backward compatibility issues 5. その他 Other considerations 1. 圧縮・暗号化 Compression, encryption 2. 差分ファイル転送 Deferred file transmission 3. バイナリデータ返送のための他の方法 Other choices for return transmission of binary data 4. の過負荷防止 Not overloading : 5. データ欄所定の内容種別 Default content-type of field data 6. 書式ACTIONの"mailto:"への対応 Allow form ACTION to be "mailto:" 7. 第三者の転送する遠隔ファイル Remote files with third-party transfer 8. ENCTYPE=x-www-form-urlencoded 付きのファイル転送 File transfer with ENCTYPE=x-www-form-urlencoded 9. 行の区切りとして使用されるCRLF CRLF used as line separator 10. multipart/relatedとの関係 Relationship to multipart/related 11. 非アスキー文字フィールド名 Non-ASCII field names 6. 例 Examples 7. multipart/form-dataの扱い方 Registration of multipart/form-data 8. 防犯への配慮 Security Considerations 9. 結び Conclusion 1.概要 Abstract 現在、 HTML 書式によって、書式を読んでいる利用者からの情報をその制作者におい て求めることが可能になっています。 この書式は、幅広い種類の利用者からの入力 が必要なアプリケーションに役立つことがわかってきました。 しかしながら HTML 書式は、利用者に対してデータのファイルを送るように求める方法を備えていないの で、この能力は限られたものになっています。 利用者からのファイルを取得する必 要があるサービスプロバイダは、特注の利用者アプリケーションを実行しなければな りませんでした。 (これらの特注ブラウザの見本が、 www-talk メーリング・リス トに現われたことがあります) ファイルの上納は多くのアプリケーションに利益を 与える機能なので、ここでは情報提供者が一定の形式でファイル上納要請を表せるよ うにするための HTML の拡張と、 MIME 互換性のあるファイル上納応答表現を提案し ます。 これには、新しいサーバが現行の HTML 利用者エージェントと互いに影響し 合うようにする逆行適合性戦略の記述も含まれます。 Currently, HTML forms allow the producer of the form to request information from the user reading the form. These forms have proven useful in a wide variety of applications in which input from the user is necessary. However, this capability is limited because HTML forms don't provide a way to ask the user to submit files of data. Service providers who need to get files from the user have had to implement custom user applications. (Examples of these custom browsers have appeared on the www-talk mailing list.) Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This also includes a description of a backward compatibility strategy that allows new servers to interact with the current HTML user agents. この提案は、これを組み入れる HTML のバージョンとは無関係です。 The proposal is independent of which version of HTML it becomes a part. 2.ファイル送信を伴うHTML書式 HTML forms with file submission 現行のHTML仕様書は、INPUT要素のTYPE属性が取り得る値として、CHECKBOX, HIDDEN, IMAGE,PASSWORD, RADIO, RESET, SUBMIT, TEXTの8つを定義しています。 The current HTML specification defines eight possible values for the attribute TYPE of an INPUT element: CHECKBOX, HIDDEN, IMAGE, PASSWORD, RADIO, RESET, SUBMIT, TEXT. さらに、POSTメソッドを使うFORM要素の既定のENCTYPE属性を、既定値 "application/x-www-form-urlencoded"を持つものとして定義しています。 In addition, it defines the default ENCTYPE attribute of the FORM element using the POST METHOD to have the default value "application/x-www-form-urlencoded". この提案では、HTMLを2箇所変更します。 This proposal makes two changes to HTML: 1. INPUTのTYPE属性に、FILEオプションを加える。 Add a FILE option for the TYPE attribute of INPUT. 2. INPUTタグのACCEPT属性を認める。これは入力できるメディアタイプかタイプパ ターンの一覧である。 Allow an ACCEPT attribute for INPUT tag, which is a list of media types or type patterns allowed for the input. さらに、ここでは新しいMIMEメディアであるmultipart/form-dataを定義し、 ENCTYPE="multipart/form-data"あるいは、またはその両方のタ グを持つ書式を解釈するときのHTML利用者手先の動作を指定します。 In addition, it defines a new MIME media type, multipart/form-data, and specifies the behavior of HTML user agents when interpreting a form with ENCTYPE="multipart/form-data" and/or tags. 以上の変更は別々に検討してかまいませんが、合理的なファイル上納には全て必要で す。 These changes might be considered independently, but are all necessary for reasonable file upload. 利用者から1個以上のファイルを入手したいHTML書式の作者は、例を示すと、以下の ように書けるようになります。 The author of an HTML form who wants to request one or more files from a user would write (for example):
HTML DTD への変更点としては、"InputType"実体に品目を1つ加えることになりま す。 さらに、 INPUT タグに ACCEPT 属性を持たせることを提案します。 これは、 コンマで区切られたメディアタイプの一覧となります。 The change to the HTML DTD is to add one item to the entity "InputType". In addition, it is proposed that the INPUT tag have an ACCEPT attribute, which is a list of comma-separated media types. ... (other elements) ... ... (other elements) ... 3. 実装のヒント Suggested implementation HTML を解釈する利用者エージェントは、それぞれの動作条件に最もふさわしいメカ ニズムを選ぶのに広範な余地を残すため、このセクションでは利用者エージェントの 一種である WWW 書見器が実行できるファイル上納の仕方について提案します。 While user agents that interpret HTML have wide leeway to choose the most appropriate mechanism for their context, this section suggests how one class of user agent, WWW browsers, might implement file upload. 3.1ファイル操作部の表示 Display of FILE widget 種別が FILE になっている INPUT タグに出くわしたとき、書見器は(以前に選択さ れた)ファイル名の表示と『 Browse 』ボタンか選択方法を示すことができます。 『 Browse 』ボタンを選択すると、書見器は、そのプラットホームにふさわしいファ イル選択モードに入るようになります。 たとえばウィンドウ形式の書見器では、フ ァイル選択窓が飛び出すようにしてかまいません。 利用者はそのようなファイル選 択ダイアログで、現行のファイル選択を入れ替えたり、新しいファイル選択を加えた りできるようになるでしょう。 書見器設計者は、ファイル名の一覧が手書きされる ようにしてかまいません。 When a INPUT tag of type FILE is encountered, the browser might show a display of (previously selected) file names, and a "Browse" button or selection method. Selecting the "Browse" button would cause the browser to enter into a file selection mode appropriate for the platform. Window-based browsers might pop up a file selection window, for example. In such a file selection dialog, the user would have the option of replacing a current selection, adding a new file selection, etc. Browser implementors might choose let the list of file names be manually edited. ACCEPT 属性がある場合は、書見器は、プラットホームに対応している適切なファイ ル拡張子を組み合わせるようにしたファイルパターンを強いて構いません。 If an ACCEPT attribute is present, the browser might constrain the file patterns prompted for to match those with the corresponding appropriate file extensions for the platform. 3.2送信時の動作 Action on submit 利用者が書式に記入して SUBMIT 要素を選択すると、書見器は、書式データと選択さ れたファイルの内容を送ることになります。 符号化方式種別 application/x-www-form-urlencoded は、非ASCII文字を含んでいる大量のバイナリ データあるいは文章を送るのには非効率的です。 かくして、受け手側から送り手側 へ、記入された書式に関する値を効率的に送る方法として、新しいメディアタイプで あるmultipart/form-data が提案される次第です。 When the user completes the form, and selects the SUBMIT element, the browser should send the form data and the content of the selected files. The encoding type application/x-www-form-urlencoded is inefficient for sending large quantities of binary data or text containing non-ASCII characters. Thus, a new media type, multipart/form-data, is proposed as a way of efficiently sending the values associated with a filled-out form from client to server. 3.3 multipart/form-dataの使用 use of multipart/form-data multipart/form-data の定義は、第7項に入っています。 境界線は、データのいずれ にも見出されないようなものが選ばれます。(この選択は、ときどき probabilisticlyとなる) 書式の各々のフィールドは、多元ストリームの元素とな り、それが書式に出てくる順序のとおりに送られます。 各元素には、元の HTML 書 式にある INPUT の名前が結合しています。 各元素は、(情報をファイル拡張子かOS の種類の情報から推察するなどして)そのメディアタイプがわかっている場合には適 切なcontent-typeとして、或いはapplication/octet-stream として分類されるべき です。 The definition of multipart/form-data is included in section 7. A boundary is selected that does not occur in any of the data. (This selection is sometimes done probabilisticly.) Each field of the form is sent, in the order in which it occurs in the form, as a part of the multipart stream. Each part identifies the INPUT name within the original HTML 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 multiple files are selected, they should be transferred together using the multipart/mixed format. HTTP 作法が任意のバイナリデータを配送することができるのに、メール配送 (ACTIONが"mailto:" URLである場合など)では7ビット符号化方式が所定のものとさ れています。 元素に与えられた値は、符号化される必要があるかもしれません。そ してその値が所定の符号化方式に従っていないならば、 "content-transfer-encoding"ヘッダが与えられる必要があるかもしれません。 詳細 については、RFC 1521の第5項を見てください。 While the HTTP protocol can transport arbitrary BINARY data, the default for mail transport (e.g., if the ACTION is a "mailto:" URL) 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 1521 for more details.] 'content-disposition: form-data'ヘッダか、複合ファイルの場合は副元素のヘッダ 'content-disposition: file'に'filename'変数が入っているもののどちらにおいて も、さらに元のローカルなファイル名が提供されるようにしてかまいません。 受け 手側応用ソフトウェアは、ファイル名を提供するために全力を尽くすべきです。受け 手側のオペレーティング・システム上のファイル名がUS-ASCIIで表わせない場合に は、ファイル名は近似するか、 RFC 1522 の方法を用いて符号化するようにしてかま いません。 これは、たとえばTeXファイルとその.sty補助スタイル記述などのよう に、上納されたファイルにお互いへの参照を入れられるなど、さまざまなケースにお いて便利です。 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 client application should make best effort to supply the file name; if the file name of the client's operating system is not in US-ASCII, the file name might be approximated or encoded using the method of RFC 1522. This is a convenience for those cases where, for example, the uploaded files might contain references to each other, e.g., a TeX file and its .sty auxiliary style description. 送り手側で、 ACTION が、CGI により動作する書式を実行する HTTP URL を指示する ようにしてかまいません。 そのようなケースでは、CGI プログラムは、 content-typeが multipart/form-data であることに注目して、種々のフィールドを 解析する(妥当性のチェック、次の処理過程のためにローカルファイルへファイルデ ータを書き出すなど)ことになります。 On the server end, the ACTION might point to a HTTP URL that implements the forms action via CGI. In such a case, the CGI program would note that the content-type is multipart/form-data, parse the various fields (checking for validity, writing the file data to local files for subsequent processing, etc.). 3.4 他の属性の解釈 Interpretation of other attributes VALUE 属性を、既定のファイル名のためにタグと共に使用できる ことが望まれます。 この使用は、おそらくプラットホームに左右されるでしょう。 これはしかしながら、同じファイル名が何度もくりかえして利用者に与えられるよう にすることを避けるなど、複数の処理の流れにおいて有用になるかもしれません。 The VALUE attribute might be used with tags for a default file name. This use is probably platform dependent. It might be useful, however, in sequences of more than one transaction, e.g., to avoid having the user prompted for the same file name over and over again. SIZE 属性はSIZE=width,height を用いて指定されます。ここでwidthは所定のファイ ル名の幅であり、これに対してheightは選択されたファイルのリストを示すために予 想されるサイズです。 例えば、これは、複数のファイルを入手しようとしている、 また、ブラウザで 多行ファイル入力欄を(できれば、その横に"browse"ボタンを添 えて)示したいと思っている書式の設計者に役立ちます。 高さが指定されていない とき(書式設計者がファイルを1つだけ求めるとき)は1行の書き込み欄を示し、高 さが1以上のとき(書式設計者が複合ファイルを求めるとき)スクロールバーのある 多行書き込み枠を示すように使えます。 The SIZE attribute might be specified using SIZE=width,height, where width is some default for file name width, while height is the expected size showing the list of selected files. For example, this would be useful for forms designers who expect to get several files and who would like to show a multiline file input field in the browser (with a "browse" button beside it, hopefully). It would be useful to show a one line text field when no height is specified (when the forms designer expects one file, only) and to show a multiline text area with scrollbars when the height is greater than 1 (when the forms designer expects multiple files). 4. 逆行適合性問題 Backward compatibility issues 現行の WWW 書式機構の補完を全面的に採用する必要はありませんが、これはまた、 移植戦略を計画するのにも役立ちます。まだ古い書見器を利用している人も、ヘルパ ーアプリケーションを用いて、ファイル上納ダイアログに参加することが可能なので す。 ほとんどの現行のweb書見器は、が与えられると、 それを と同様に扱って、利用者にテキスト・ボックスを与えます。 利用 者は、このテキスト・ボックスにファイル名を打ち込むことができます。 なお、現 行の書見器は そして利用者が氏名欄に"Joe Blow"と打ち込み、「どのファイルを送りますか?」へ の答えとしてテキストファイル"file1.txt"を選ぶと、 and the user types "Joe Blow" in the name field, and selects a text file "file1.txt" for the answer to 'What files are you sending?' クライアントは以下のデータを送り返すことになるでしょう。 The client might send back the following data: Content-type: multipart/form-data, boundary=AaB03x --AaB03x content-disposition: form-data; name="field1" Joe Blow --AaB03x content-disposition: form-data; name="pics"; filename="file1.txt" Content-Type: text/plain ... contents of file1.txt ... --AaB03x-- 同様に利用者が「どのファイルを送りますか?」への答えとして画像ファイル "file2.gif"を選ぶと、クライアントは以下のデータを送り返すことになるでしょ う。 If the user also indicated an image file "file2.gif" for the answer to 'What files are you sending?', the client might client might send back the following data: Content-type: multipart/form-data, boundary=AaB03x --AaB03x content-disposition: form-data; name="field1" Joe Blow --AaB03x content-disposition: form-data; name="pics" Content-type: multipart/mixed, boundary=BbC04y --BbC04y Content-disposition: attachment; filename="file1.txt" Content-Type: text/plain ... contents of file1.txt ... --BbC04y Content-disposition: attachment; filename="file2.gif" Content-type: image/gif Content-Transfer-Encoding: binary ...contents of file2.gif... --BbC04y-- --AaB03x-- 7. multipart/form-dataの扱い方 Registration of multipart/form-data メディア-タイプ multipart/form-data は、 RFC 1521 で概説された全ての multipart mime データストリームとしての規則に基づいています。 これは記入され た書式からデータを返すのに使うために用意されているものです。 書式には( HTML では他のアプリケーションが書式を用いてもいいのですが)、書式に記入する利用者 に提供されるフィールド一式があります。 各々のフィールドには名前があります。 与えられた書式の範囲内では、名前は重複しません。 The media-type multipart/form-data follows the rules of all multipart MIME data streams as outlined in RFC 1521. It is intended for use in returning the data that comes about from filling out a form. In a form (in HTML, although other applications may also use 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"であ る内容-性質ヘッダと、書式の範囲内でフィールド名を指定する名前属性を持つこと になっています。たとえば'content-disposition: form-data; name="xxxxx"'では、 xxxxxがそのフィールドに対応しているフィールド名です。 非ASCII 文字セットによ る元のフィールド名は、RFC 1522 で概説された方法を用いて符号化してかまいませ ん。 multipart/form-data contains a series of parts. Each part is expected to contain a content-disposition header where the value is "form- data" and a name attribute specifies the field name within the form, e.g., 'content-disposition: form-data; name="xxxxx"', where xxxxx is the field name corresponding to that field. Field names originally in non-ASCII character sets may be encoded using the method outlined in RFC 1522. multipart mimeタイプ全てに共通することですが、各々の部品は選択可能な内容-タ イプを持ち、その既定値は 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 application/octet-stream or the appropriate media type, if known. If multiple files are to be returned as the result of a single form entry, they can be returned as multipart/mixed 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. ファイル入力では、ファイル名も判別されるでしょう。ファイル名は "content-disposition"ヘッダの'filename'変数を用いて述べることができます。こ れは不可欠ではありませんが、どのような場合にも元のファイル名がわかるようにす るため、強く奨励されます。これは多くのアプリケーションにおいて便利であり、必 要ともなります。 File inputs may also identify the file name. The file name may be described using the 'filename' parameter of the "content-disposition" header. This is not required, but is strongly recommended in any case where the original filename is known. This is useful or necessary in many applications. 8. 防犯への配慮 Security Considerations 重要なこととして、ファイル送出について利用者の明白な意思表示がないものを、利 用者エージェントが送ってはなりません。 従って HTML を解釈しているエージェン トは、 をもって示されるどんな所定のファイル名 も確かめることになっています。 いかなるものであれ、隠しフィールドにファイル を指定できるようなことがあってはなりません。 It is important that a user agent not send any file that the user has not explicitly asked to be sent. Thus, HTML interpreting agents are expected to confirm any default file names that might be suggested with . Never have any hidden fields be able to specify any file. この提案には、データの暗号化のための機構は入っていません。これはデータの安全 な転送のためのあらゆる他の機構、保安 HTTP や( RFC 1848 で描写された)MOSSに よって与えられる防犯システムにおいて扱われるべきです。 This proposal does not contain a mechanism for encryption of the data; this should be handled by whatever other mechanisms are in place for secure transmission of data, whether via secure HTTP, or by security provided by MOSS (described in RFC 1848). ファイルが一旦アップロードされたら、適切にファイルを処理し保管することは受け 入れ先の仕事になります。 Once the file is uploaded, it is up to the receiver to process and store the file appropriately. 9. 結び Conclusion 示唆された実装はクライアントに、サーバへ送ることができるファイルの数と種類に おいてきわめて大幅な柔軟性を与えます。また、サーバに、ファイル受け入れ決定に 関する制御を与えます。そしてまた、これはサーバに、入力タイプ『ファイル』を扱 わない書見器と互いに影響し合う機会を与えます。 The suggested implementation gives the client a lot of flexibility in the number and types of files it can send to the server, it gives the server control of the decision to accept the files, and it gives servers a chance to interact with browsers which do not support INPUT TYPE "file". HTML DTD への変更は非常に単純ですが、非常に強力です。 これをもってすれば、 World-Wide Webにおいて実現されるサービスを、ファイル送信設備の不足に足を取ら れている現状より、はるかに多様なものにすることができるでしょう。 The change to the HTML DTD is very simple, but very powerful. It enables a much greater variety of services to be implemented via the World-Wide Web than is currently possible due to the lack of a file submission facility. This would be an extremely valuable addition to the capabilities of the World-Wide Web. Authors' Addresses Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 Phone: (415) 812-4365 Fax: (415) 812-4333 EMail: masinter@parc.xerox.com Ernesto Nebel XSoft, Xerox Corporation 10875 Rancho Bernardo Road, Suite 200 San Diego, CA 92127-2116 Phone: (619) 676-7817 Fax: (619) 676-7865 EMail: nebel@xsoft.sd.xerox.com ---------------------------------------------------------------------- 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. Published specification: RFC 1867 Security Considerations The multipart/form-data type introduces no new security considerations beyond what might occur with any of the enclosed parts. References [RFC 1521] MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. N. Borenstein & N. Freed. September 1993. [RFC 1522] MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text. K. Moore. September 1993. [RFC 1806] Communicating Presentation Information in Internet Messages: The Content-Disposition Header. R. Troost & S. Dorner, June 1995. 訳注 せっかくですが、ここで示されたRFC1521とRFC1522のMIMEは既に古くなってい ます。現行のMIMEはRFC2045,RFC2046,RFC2047,RFC2048,RFC2049の5つのRFCから 成り立つもので、当研究室ではこの翻訳に手をつけたところです。