[11] MIME型 multipart/form-data
は、 HTML のフォームの提出で使われるデータ形式です。
[42] application/x-www-form-urlencoded と並んで HTTP
POST 要求で最もよく用いられる MIME型の1つです。
パーセント符号化を使う
application/x-www-form-url-encoded
では扱いづらいファイル (<input type=file>) の提出のために開発されましたが、
ファイルを扱わない場合にも使われています。
[157] multipart/form-data は、フォームデータ集合の提出のための構文です。
[40] 基本的には、 multipart/mixed と同じ書式です。
RFC 2046, HTML 4 17.13.4.2, RFC 2388 3.
[159] つまり本体は、境界文字列などで区切られた本体部分の列です。
[160] 境界文字列は、 Content-Type: ヘッダーの
boundary 引数によって表されます。
boundary 引数は、必須です >>43。
Content-Type: に指定する引数です。
本体部分のヘッダーではありません。[79] どのブラウザも、前書きも後書きも空にします。
Opera が複数のファイルを提出する場合に使う multipart/mixed
についてもそうです。
(HTTP の場合のみ調べました。)
>>66
[24] 境界文字列 (boundary) はデータ中に現れてはなりません。
HTML 4 17.13.4.2, RFC 2388 4.1
[89] どのブラウザも、 boundary 引数は quoted-string
ではなく、 token として表現しています。
>>66
Firefox の例:
boundary=---------------------------105742468821884
Opera の例:
boundary=----------ByrdxQC7rqEXna35oMxxa7
Safari の例:
boundary=----WebKitFormBoundaryAAEEAAYDAACjAAHf
WinIE の例:
boundary=---------------------------7d839d460bd2
[124] 古の Netscape Navigator は boundary 引数を含めない不具合があったようです。
[129] CGI.pm によれば、 MacIE の 3.01 と 3.02、 DreamPassport には境界文字列の前に
-- を含めない不具合があったようです。
[125] MIME の規定によれば、境界文字列のある行の最後には任意個の空白が挿入されることがあり、 利用者エージェントはこれを無視して解釈しなければなりません。
[127] HTTP の鯖がこれに対応しているかは怪しいです。
[128] Perlモジュール HTTP::Body はこれに対応していないようです。ほどほどよく使われているモジュールのようなので、 Web互換性のためには必要ないということでしょう。
[8] MIME の規定により、境界行や実体頭欄の末端の改行は CRLF
でなければなりません。 CR や LF
だけではいけません。
[25] 他のすべての MIME 転送同様、改行は CRLF とします
HTML 4 17.13.4.2。
と HTML 4 も言っています。 (転送
とはどこからどこまでか、
曖昧であるのが問題ではありますが。)
[9] >>8 は大前提なんですが、
一方で HTTP ではいい加減な実装が多いので、もしかしたら・・・ CR
だけとか LF だけとかで送ってくる糞
UA もあったりするんでしょうか?
多分 Mozilla とか Opera とか IE とかの有名どころは大丈夫だと思うんですが。。。
[60]
MacIE 5.2 には boundary のところの改行の
CR が一部欠落してしまう不具合があるそうです。
MacのIEでのmultipart/form-dataデータ http://kvasir.skirnir.net/software/software00009.ksd
[68] 主要ブラウザは multipart/form-data としての改行をすべて
CRLF と正しく送信するようです。
>>66
[65] 本体部分の個数に特に制限は設けられていないようです。
[23]
フォームの各欄は、応用とフォームによって定義された順で、
それぞれ multipart/form-data の本体部分とします。
RFC 2388 4.1 本体部分の順序は、 RFC 2388
では規定されていません。 RFC 2388 5.5
[41]
HTML の場合、multipart/form-data の本体部分は、それぞれ、
成功制御子に対応します。順序は制御子の文書順とします。
HTML 4 17.13.4.2
[180] フォームで順序が規定されている場合は、そのまま送るべきです >>177。中間器は入れ替えてはなりません >>177。
[91] どのブラウザも、本体部分に使う可能性のある頭欄は
Content-Type: と Content-Disposition:
だけのようです。他の頭欄は見たことがありません。
>>66
[146] 本体部分には、 Content-Disposition:
ヘッダーで disposition型 form-data
を指定しなければなりません。 name
引数もなければなりません。 >>145
[162] Content-Disposition: ヘッダーには、更に
filename 引数も指定できます。
[174] Content-Type:、Content-Disposition:、
Content-Transfer-Encoding: 以外の Content-
ヘッダーを含めてはなりません。無視しなければなりません。 >>43
[28] 各欄は名前を持ちます。
[182] 同名の欄が複数含まれることもあります。 同名の欄をまとめてはなりません >>177。
[179] 各本体部分は、 Content-Disposition
を form-data とし、その name
引数に対応する制御子の欄名 (制御子名) を指定します
HTML 4 17.13.4.2, RFC 2388 3.。
[147] 本体部分がファイルの内容を表す場合は、
本体部分の Content-Disposition: ヘッダーの
filename 引数でファイル名を指定するべきです
>>145。
[44] フォーム・ソフトウェアは、提出するファイルにファイル名やその他のファイルの属性情報をつけても構いません。 RFC 2388 4.4
[33] HTML UA は提出する各ファイルにファイル名を供給するよう試みるべきです。
ファイル名は Content-Disposition 欄の
filename 引数で指定します。HTML 4 17.13.4.2
[45] 提出するファイルは相互にファイル名で参照関係を持っているかもしれませんから、 ファイル名が保存されていると便利です。 HTML 4 17.13.4.2, RFC 2388 4.4
ファイル名指定に関する様々な問題については、
filename 引数の説明をご覧ください。
[71] WinIE はフルパス名を値に使います。他のブラウザは狭義のファイル名だけを値に使います。 >>66
[74] どのブラウザでも、 filename は必ず
name の後に来るようです。
form-data と name 引数と
filename 引数の3つだけで、他の情報は付与しないみたいです。
>>66
[131] Perlモジュール HTTP::Body は filename
引数の有無によりある実体本体がファイルかどうか判断します。たとえ空文字列であっても、
ファイルならファイル名が必要です。
[26] ほかのすべての multipart/* 型と同様、
各本体部分は省略可能 >>165 な Content-Type
頭欄を持ちます。省略時の既定値は text/plain です >>165。
[166] 媒体型が分かっている場合は適当に札付けし、分からない場合は
application/octet-stream とするべきです。
HTML 4 17.13.4.2, RFC 2388 3., RFC 2388 4.1, RFC 2388 4.2, >>165
[76] どのブラウザも、ファイルの場合はそのファイルの媒体型を
Content-Type: 欄として指定し、
それ以外の場合は Content-Type: 欄を省略します。
>>66
[77] ファイルの場合、どのブラウザも、
(おそらく拡張子やシステムの、またはブラウザ内蔵の対応表を使って)
ファイルの媒体型を推定できればその値を、できなければ
application/octet-stream を使うようです。
確認できた限りでは charset も含めて引数を指定することはありませんでした。
>>66
[84] どのブラウザも、すべての実体本体、 name 引数、
filename 引数に同じ charset を使うようです。
>>66
[85] 使用することに決めた charset で表現できない文字がある場合、 Unicode における符号位置を十進数文字参照形式にしたものが代わりに挿入されます。 >>66
[86] Opera は以前は multipart/form-data 自体の
Content-Type: 欄に charset 引数を指定していましたが (>>2)、
互換性に難があったのか、現在はつけないようです。
他のブラウザも multipart/form-data 自体には
boundary 引数だけしか指定しません。
>>66
[168] フォームデータがテキストの時は、その本体部分の
Content-Type: text/plain
の charset 引数で文字符号化を提示できます >>32。
[169] しかし実際には広く使われている実装は charset
引数を指定しません >>32。
[1] WinIE も Mozilla も Opera も、 multipart/form-data
に含まれる本体部分には charsetパラメーターを付けてくれません。
(ファイル送信を除いて Content-Type 欄そのものをつけません。)
[167] HTML4 は、 HTML UA は本体部分の Content-Type 欄を
(charset 引数を含めて) 供給するべき
HTML 4 17.13.4.2 と述べていました。しかし誰もそれに従っていませんでした。
[2] Opera (Presto) は、 multipart/form-data そのものに (存在しない)
charset 引数をつけてきます。
この charset 値は実際にはそれに含まれる本体部分の実体本体及び
Content-Disposition 欄の name
引数に適用されるようです。あ、 filename にもかな?
今度確かめてみよう。
[4] >>2-3 の情報は、 file
として送られる実体本体には適用できません。 (その実体の頭欄には適用されます。)
charset=unknown-8bit とでも考えるしかなさそうです。問題は、
一般の form data と file を区別する確実な方法がないことです。
IE, Moz, Opera に限れば、 filename 引数の有無で決定できますが。。。
[5] >>4 あ、確実な方法が1つだけあります。受取る側が名前を知っていること。 これ超確実。
[88] HTML5 や元の Web Forms 2.0 は application/x-www-form-urlencoded
や text/plain で提出する場合については
_charset_ hack を定義していますが、
multipart/form-data の処理は RFC 2388
に丸投げしているので、 _charset_ hack
は正式にはどこでも定義されていませんでした。
[3] その後の改訂で HTML Standard で multipart/form-data
の時も _charset_ hack の扱いが規定されるようになりました。
[170] RFC 7578 も、それが既定の charset を規定する >>32 と述べています。
[87] Safari 以外のブラウザは _charset_ hack に対応しています。
>>66
[30] ファイルの場合、 MIME型が Content-Type:
ヘッダーに指定されますが、 charset 引数を含め、
引数までは指定されないのが普通です。
[31]
各本体部分の本体は、ファイル選択制御子
(input//file) ではファイルの内容、
それ以外では現在値になります。
(という説明が HTML 4 仕様書ではきちんとなされていません。)
[27] 各本体部分は CTE
を使ってもかまいません。
HTML 4 17.13.4.2, RFC 2388 3., RFC 2388 4.3
その他 MIME の機構により暗号化・圧縮などをしても構いません。
それは multipart/form-data を生成する応用の機能です。
RFC 2388 5.1
[53] ただし、 HTTP で multipart/form-data
を使う場合は、仕様が曖昧なためその中の本体部分で
Content-Transfer-Encoding を使用するべきではありません。
Content-Encoding を本体部分に適用できるのかどうかも曖昧であり、
使わない方が良いです。
(対応している実装も少ないでしょう。)
Transfer-Encoding を本体部分に適用することはできません。
なお、これは multipart/form-data 内の各本体部分についてであり、
multipart/form-data 実体自体については >>54 をご覧下さい。
[75] どのブラウザも、内容符号化や内容転送符号化は使用しないようです。
Content-Transfer-Encoding: 欄や
Content-Encoding: 欄も使用していないようです。
(HTTP の場合のみ調べています。)
>>66
[14] >>12 は Content-Transfer-Encoding: 8bit と
Content-Transfer-Encoding: binary を1つの
multipart/form-data で混在させた例を示しています。
[172] RFC 2388 の改訂である RFC 7578 は、
HTTP のように CTE が不要なら、非推奨であり、
Content-Transfer-Encoding: ヘッダーを生成するべきではない
>>43 とされています。そのような実装は知られていない >>43
とも述べられています。
[49] 遠隔ファイルを直接送らずに、 message/external-body
を使ってその指示子だけを送ることができます。
RFC 2388 5.3
[52]
message/external-body の使い方は色々ありますが、
access-type uri
を使って遠隔ファイルの
URI参照を送るのが現代的でよろしいのではないでしょうか。
[83] これに対応しているブラウザやフォーム処理エージェントがあるという話は聞いたことがありません。
[73] 1つの欄が複数のファイルを含むときは、
同じ name 引数の異なる本体部分としなければなりません
>>72。
multipart/mixed 方式[51] かつては、1つのフォーム項目として複数のファイルを同時に提出する場合には、
multipart/mixed を使って1つの本体部分とすることになっていました。
HTML 4 17.13.4.2, RFC 2388 3., RFC 2388 4.2
[150] しかしこの方式は現在では非推奨とされています >>72。
[151] ファイル名等はその multipart/mixed
内のそれぞれの本体部分の情報として付与します。
[34] 提出ファイルが複数の時の multipart/mixed 内の本体部分では
Content-Disposition: file とするかのような記述が仕様書にあります
HTML 4.01 17.13.4.2 が、
attachment の誤りだそうです HTML 4.01 正誤表 10.。
みっともないことに HTML 4.01 正誤表は RFC 2388 に責任転嫁しております(w。確かに元々 HTML 4.0 では attachment になっておりましたが、 HTML 4.01 で minor typo
として修正されています HTML 4.01 A.1.3。
file を指定して、 Content-Disposition: file; filename=foo のように指定することがあるようです。 (CGI script とかで。)
(正しくはやはり Content-Disposition: attachment。)[152] HTML や multipart/form-data の仕様の側では複数のファイルを1つの欄で提出することになってはいましたが、
実際にはこれは (クライアント側でもサーバー側でも) 対応されていませんでした。
そのまま Webブラウザーを拡張するとサーバーが意図しない
multipart/mixed データを受信することになってしまうため、
Web Forms 2.0 は min/max
属性によってサーバーが受信を意図するファイルの個数を明示できるようにしました。
[78] Opera 9 は Web Forms 2.0 の max 属性による指定を使ったファイルの複数同時提出に対応しています。
複数のファイルが含まれる場合、仕様通り multipart/mixed
が使われます。その本体部分については、単体の場合と同じように挿入されます。
Content-Disposition: の値は RFC 2388 とも HTML4
とも違って form-data になります。
name 引数も単一ファイルの場合と同じように指定されます
(multipart/mixed の方にも指定されますが、個々の本体部分の方にも指定されます)。
(複数ファイル指定可能であっても、選択数が1つ以下なら従前の方法によります。)
>>66
[153] しかし、結局複数のファイルを受信するためにサーバー側で新たに
multipart/mixed に対応しなければならないことには変わりありません。
Web Forms 2.0 が HTML5 に統合されるに当たり、
min/max 属性による複数ファイルの提出機能は廃止され、
代わって新たに mutliple 属性による提出が導入されました。
新方式では multipart/mixed を使わず、同名の複数の本体部分を用いる方法に変更されました。
[154] RFC 7578 はこれを踏まえて multipart/mixed
を非推奨とし、 HTML が採用した方法を使わなければならないとしました。
その一方で、広い応用可能性を求める応用 (例えばライブラリー)
は multipart/mixed 方式も対応するべき >>72
としています。
[6] ファイル選択制御子 (input/file)
があっても、ファイル名として何も指定されなかった場合、
WinIE も Mozilla も Opera も、空の内容を送ります。
このとき、 WinIE と Mozilla は頭欄に
Content-Type: application/octet-stream と書いてきて、
Content-Disposition にも filename=""
がつきます。 Opera ではどちらもつかず、本当に空
(Content-Disposition: form-data; name=名前
と空の内容だけ) になります。
[38] 頭欄がどうであれ、空の実体を送ってしまうと (一般の UA の場合に) ファイル未選択状態と内容が空のファイルを提出した場合が区別できなくなってしまいます。 ファイルを選択していないファイル選択制御子はそもそも成功にしてはいけないのではないでしょうか。
[80] HTML5 でも選択されていないファイル選択制御子はフォーム・データ集合に含まれない定義になっていますがね。。。
[81] どのブラウザも、選択されていなくても空の実体本体を含めるようです。
Content-Disposition: はファイル以外の制御子の場合と同じです
(filename 引数がつきません)。
Content-Type: は、 Opera 以外は
application/octet-stream とします。
Opera は欄自体を省略します。
>>66
multipart/form-data 符号化算法[110] multipart/form-data 符号化算法は、
フォーム・データ集合を multipart/form-data 実体として符号化するための算法です。
[111] multipart/form-data符号化算法は次のように定義されています >>109。
form 要素が accept-charset
属性を有する場合、mutlipart/mixed によるファイル集合の符号化の方法は使いません。file でない欄の実体本体については、
Content-Type: を指定しません。multipart/form-data
によるフォームの提出を実装しなければなりません HTML 4 17.13.4
と規定されていました。 HTML5 ではフォーム符号化算法などに完全に組み込まれており、
mutipart/form-data に対応しない実装が適合するのか不明です。enctype 属性値[104] HTML の form 要素の enctype 属性と、
input 要素や button 要素の
formenctype 属性は、属性値として multipart/form-data
を指定することができる列挙型属性です >>103。この値を指定すると、当該要素
(やそのフォームに属する要素であって上書きされていないもの) の enctype
を multipart/form-data に設定することができます >>103。
要素の enctype はフォーム提出算法から参照されています。
enctype 属性の既定値は
application/x-www-form-urlencoded
なので、
multipart/form-data
は必ず明示的に指定しなければなりません。[108] enctype が multipart/form-data の時の適当なフォーム符号化算法は
multipart/form-data符号化算法です。 >>105
[106] フォーム提出算法において提出する実体本体を構築するに当たり、提出子たるボタンの要素の
enctype が参照されます。それが multipart/form-data である場合、
実体本体の MIME型 (Content-Type: 欄の値) としては、
multipart/form-data; boundary=boundary-string... が使われます。ただし boundary-string は
multipart/form-data境界文字列です。
>>103[143] multipart/form-data そのものに関する DOM API
はありませんが、 multipart/form-data で送信されることになるフォームデータ集合を表すオブジェクトとして
FormData があります。
[144] FormData は XHR Standard により規定されていますが、
XHR 以外の目的でも使うことができます。
[190] multipart/form-data は、ファイルアップロードに使われます。
しかし実のところ multipart/form-data は大容量のファイルの送受信に適した形式というわけでもありません。
[191] multipart/form-data に含めるフォームデータの順序は、
制御子の種別と無関係に決まります。ですから、ファイルがどこに来るかはわかりません
(フォーム制御子の文書中の位置に依存します)。
受信者 (サーバー) は受信したデータの末尾まで読み終わらないと、
処理に必要なすべてのフォームデータを受信したのかどうか確実に判断することができません。
[192] つまり、サーバーは大容量のファイルが含まれる (かもしれない)
multipart/form-data の要求本体を全部読み込み終わらないと、
それをどう処理するべきか判断できる保証がありません。
要求本体を単純に先頭から末尾まで読みつつ処理するなら大容量のデータをメモリー上に保持しておく必要がありますし、
それが難しそうなら一時ファイルに書き込んでから処理するしかなさそうです。
どんなデータを与えられるか事前にまったく予測できないプログラミング言語のライブラリーなどでは一時ファイルに保存する方法を選択することが多いようです。
[93] WAP により規定された multipart/form-data に相当するバイナリー表現として、
application/vnd.wap.multipart.form-data 媒体型がありました。
multipart/form-data[6] HTML のフォームでは application/x-www-form-urlencoded
もよく使われていますが、任意のバイナリ・データや非 ASCII
文字を効率よく確実に扱うことができないという問題があります。
バイナリ・データや非 ASCII 文字を含むフォームの提出では、
multipart/form-data を使うべきです HTML 4 17.13.4.2。
ファイル選択制御子 (input/file)
を使う時には、 multipart/form-data を
form の enctype で指定するべきです
HTML 4 17.3, 17.13.4.2。
[35] HTML のフォームで multipart/form-data で提出させたい時は、
form 要素の enctype
属性に multipart/form-data と指定しておきます。
各本体部分の文字符号化方式の決定には、 form
要素の accept-charset 属性の指定を参照します。
multipart/form-data[54] MIME の規定によれば、 multipart/*
のすべての実体の Content-Transfer-Encoding
は 7bit, 8bit, binary
のいずれかでなければなりません。もちろん multipart/form-data
の実体にも適用されます。
注意: multipart/form-data
の中の本体部分についての規定ではありません。
本体部分の CTE については >>53 を参照して下さい。
[55] HTTP では Content-Transfer-Encoding
を使用しません (常に binary 相当です) が、
Content-Encoding と Transfer-Encoding
があります。 Transfer-Encoding は媒体型に依存しませんので、
multipart/form-data であろうがそうでなかろうが常に使用できます。
Content-Encoding が使用できるのかどうかは微妙なところですが、
特別規定がないのですから、使用できるのでしょう。但し、
それに対応している実装 (クライアント・鯖) がどれだけあるのかは微妙なところです。
[56] Content-MD5 による簡易的な整合性情報は、
MIME では multipart/* に対して使用することが認められていませんが、
HTTP では認められています。 multipart/form-data
についても例外ではありません。
しかし、 multipart/form-data 全体の MD5
ハッシュを計算するよりは、面倒でも個々の本体部分で計算した方が良いでしょう。
もし HTTP で提出された multipart/form-data が途中で
MIME に変換されて (例えば電子メイルで)
送られるとすると困ったことになります。
[50] multipart/form-data
を構成するプロトコル要素やフォームの仕組み自体には、
様々な安全上の問題があることが知られています。
例えば、利用者の意図しない状態や利用者が十分な考慮を行えない状況で自動的・ 半自動的にフォームを提出させると、 利用者の私的な情報や利用者の環境の安全に関わる情報が送信されてしまう虞があります。 このほかにも、フォームの提出という仕組みそのものに起因する問題が多く見つかっています。
また、ファイルを提出する際には filename
引数を使うことができますが、フォーム処理エージェント
(multipart/form-data を処理する側)
が信頼して無防備に実際のファイル名等として使用すると、
既存の別のファイルやシステム・ファイルを上書きしたり、
その環境で扱えないファイル名のファイルが中途半端にできてしまったりする虞があります。
詳しくは filename 引数の説明をご覧ください。
このようなフォーム自体や multipart/form-data
が利用しているプロトコル要素に関する問題や、
特定の実装に依存した問題を除いては、 multipart/form-data
に関する安全上の問題は見つかっていません。
[57] 提出の途中での改竄を検出する簡易的な手段として
Content-MD5 が使用できます (>>56)。
但し記述された Content-MD5 値自体が改竄されることもあり得ますから、
あくまで簡易的なものです。また、
実装している利用者エージェントは現時点で存在しないと思われます。
[58] 一般の MIME の実体の安全のための仕組みとして署名のための
multipart/signed や暗号化のための
multipart/encrypted が、
それを使った実際のシステムとして PGP/MIME や S/MIME
があります。しかし、現実に multipart/form-data
と組合せて使っている (使える) 例は聞いたことがありません。
multipart/form-data のどの部分を署名・暗号化するのか
(あるいは全体をするのか) や、フォームの提出の手続きの中でどのように処理するのかなどの詳細な標準化がなされないと
(またはデファクト標準が登場しないと) 使用するのは難しいでしょう。
[59] 現実にフォームの提出の安全のために使用されているのは TLS や SSL です。 HTTP に対応した利用者エージェントや鯖では大抵 TLS over HTTP (HTTPS) が利用できるので、 フォーム処理エージェントとしては特別な処理が要らないのが普通です。 但し、 HTTP 以外の提出方法 (特に電子メイル) にはこの方法は使えません。
[15] WinIE 3.02 用の file upload add-on は 1997年の中ごろに出ました。
[92]
RFC 1867 と RFC 2388 と HTML 4 の multipart/form-data
の規定は文章を流用していて同じようなことが書いてありますが、
少しずつ違います。独立の仕様書になっている RFC 2388 が当然一番詳しくなっています。
multipart/form-data への言及の変遷:Content-Disposition: attachment
を Content-Disposition: file に変更attachment から
file に再修正。しかも RFC 2388 に責任転嫁(藁[22] multipart/form-data 内容は RFC 2045
で説明された多部分 MIME データ列の規則に従います。
multipart/form-data の定義は IANAREG
から入手できます。 HTML 4 17.13.4.2
と書いてありますけど、むしろ RFC 2046 を読むべきでしょう。
また、後方互換性, 他の内容型との関係, 効率の問題その他については
RFC 1867 HTML 4.0 17.13.4.2 ・ RFC 2388 HTML 4.01 17.13.4.2
を読むよう指示があります。
ちなみに、仕様書の発行順序は HTML 4.0 → RFC 2388 → HTML 4.01 です。
[95] HTML4 はフォームで非ASCII文字が提出される可能性がある場合に
application/x-www-form-urlencoded の代わりに
multipart/form-data を使うことを勧めていましたが、
世間からは完全に無視されています。
[98] device-upload では、音声等の新しいファイルのうpの方法に適用するための
device などの Content-Disposition: 引数を提案し、
その指定方法を規定していました。
[99] VoiceXML 解釈器は multipart/form-data
に対応することが義務付けられています VoiceXML 2.1。
[96] XForms でも、「互換性のため」としながらも multipart/form-data
を使うことができます。ただし、 XForms のモデル上のすべての情報を含められるわけではなく、
例えば属性節点に相当する情報は欠落します。
XForms は注記として、既存の HTML 利用者エージェントは非ASCII文字等の扱いが芳しくないことを指摘しています。
それとどう関係があるのか知りませんが (だからきちんと処理するよう指導しているわけでもありません)、
multipart/related や application/xml
を使うことを勧めています。
[97] WSDL でも、 「XForms との互換性のため」として
multipart/form-data を使うことができます。
[121] WF2 ははじめてフォーム提出算法を明確な形で仕様として規定しました。その中に
multipart/form-data による提出の方法も含まれていました。
[122] HTML Living Standard (HTML5 / Web Applications 1.0) はこれを引き継ぎ、
更により明確かつ具体的に multipart/form-data の処理も規定しています。
[123] とはいえ、いずれの仕様書も multipart/form-data 自体の生成の部分は
RFC に委ねており、 >>102 により曖昧な部分を明確化したとはいえ、結果として
delta spec のような状態になっています。
[46] 2015年7月には、 RFC 2388 を廃止して新たに RFC 7578 が出版されています。
[142] Webブラウザー業界からの要求がようやく少しずつ反映されて、 実態により近い形に改訂されています。 (とはいうものの、 基本的には昔ながらの IETF の RFC のスタイルからは脱却できず、 現代 Web標準レベルの正確な仕様書にはなっていません。)
[36] 現代のほとんどの WWWブラウザは multipart/form-data
によるフォームの提出を実装しています。
[37]
一方、 CGIスクリプトなどの鯖側は酷い状況です。
多くの実装は相手にもしていません。 Perl なら CGI.pm
などを使えば自動的に対応できますが、最近は増えてきたとはいえモジュールを
CGI スクリプトで使うことは少なく、 application/x-www-form-urlencoded
にしか対応していません。ファイルのうpがしたくなったら
(素直にモジュールを使えばいいのに) 見よう見まねで適当に対処しようとして、
結局特定ブラウザの特定の版でしか上手く動かないようなコードを書いてみたり。
(で、質問掲示板で暴れてみたり。) お前らちゃんと仕様書読んでくださいよ。
処理系で標準または標準に近いモジュール的なものが要求の解析をしてくれることが広く知られていて、
そのモジュール的なものの作者がちゃんと仕様を読んでコードを書くような人なら、
その処理系で書かれた処理はさほど深く考えなくても自動的に
multipart/form-data を正しく処理できるはずです。
よく知りませんけど、 Java servelet とか PHP はその辺きちんとしてるのではないですか?
[66] Firefox 3.0.4、Opera 9.61、Safari 3.2、WinIE 7 の実装状況を調べてみました。
[94] enctype="multipart/form-data"で携帯からファイルアップロード « 携帯・モバイル « プログラム « Re: (kronekodow 著, 版) http://blog.livedoor.jp/kronekodow/archives/64944587.html
SoftBankが素敵に思えた。
データフォルダから直アップできるんですね。
fileup_auauは(W52SHは)Browse...ってボタンは出るものの反応しない。
DoCoMoはボタンすら出ない。
SoftBankでも、C端末、3GC端末などによる違など全てじゃなかったり、auも一部端末なら出来たり?(HTMLやXHTMLの違いなども関係したり)とか、可能な端末の振り分けは大変そうです。
[13] 1つのファイル選択制御子 (input//file)
を使って複数ファイルをうpする (>>51) のは、 UA で対応してるのはなさげ、
サーバーもおそらく全滅だろうという感じですね。
www-html で Opera の特定の版では出来るという未確認情報がありましたが、 最新版では出来ないらしいし、勘違いかなんかじゃないかなあ。
[67] その後 Opera 9 は Web Forms 2.0 に対応しましたので、
複数ファイルの提出にも対応しています。 file 制御子用の
max 属性は一旦 HTML5 で削除されましたが、
multiple 属性が改めて追加される予定ですから、
いずれ他のブラウザも複数ファイルの提出に対応すると期待されます。
[90] Index of /~wakaba/-temp/test/html/form/multipart-form-data ( 版) http://suika.fam.cx/~wakaba/-temp/test/html/form/multipart-form-data/
[39] HTML のフォームの例 HTML 4 17.13.4.2、改
<FORM action="http://server.example/cgi/handle"
enctype="multipart/form-data"
method="post">
<P>
What is your name? <INPUT type="text" name="submit-name"><BR>
What files are you sending? <INPUT type="file" name="files"><BR>
<INPUT type="submit" value="Send"> <INPUT type="reset">
</FORM>このフォームで、文章入力欄に Larry と記入し、ファイル選択で file1.txt を指定して提出した場合 HTML 4 17.13.4.2, 改:
Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Larry --AaB03x Content-Disposition: form-data; name="files"; filename="file1.txt" Content-Type: text/plain ... contents of file1.txt ... --AaB03x--
更に file2.gif も選択していた場合 HTML 4 17.13.4.2, 改:
Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Larry --AaB03x Content-Disposition: form-data; name="files" Content-Type: multipart/mixed; boundary=BbC04y --BbC04y Content-Disposition:fileattachment; filename="file1.txt" Content-Type: text/plain ... contents of file1.txt ... --BbC04y Content-Disposition:fileattachment; filename="file2.gif" Content-Type: image/gif Content-Transfer-Encoding: binary ...contents of file2.gif... --BbC04y-- --AaB03x--
[47] ユーロ通貨記号を値に使った例 RFC 2388 4.5、改
Content-Type: multipart/form-data; boundary="AaB03x" --AaB03x content-disposition: form-data; name="field1" content-type: text/plain; charset=windows-1250 content-transfer-encoding: quoted-printable Joe owes =80100. --AaB03x--
[63] Q: HTML でファイルをアップロードするにはどうしたらいいですか? ファイル名しか取得できません...
A: ファイル名しか取得できないのは、
application/x-www-form-urlencoded
を使用しているからの可能性が高いと考えられます。
フォームの提出で multipart/form-data
を使うようにしましょう。
関連: >>61, input//file, 提出
[61] Q: HTML によるフォームの提出でブラウザに multipart/form-data で送ってもらうにはどうしたらいいですか?
A: form 要素の enctype
属性を multipart/form-data と指定してください。
ついでに、 accept-charset 属性に希望する文字コードも指定しておきましょう。
method 属性を post
にしておくのを忘れないように。
[62] Q: CGI スクリプトで multipart/form-data と application/x-www-form-urlencoded を見分けるにはどうしたらいいですか?
A: CGI には CONTENT_TYPE というメタ変数
(環境変数) があります。その値で判別できます。
CONTENT_TYPE の値の先頭の19文字が
multipart/form-data (大文字・小文字の区別なし)
で、その次の文字が存在しないか、空白 (間隔、
タブ、改行) か、セミコロン (;)
なら、 multipart/form-data が使われています。
CONTENT_TYPE の値の先頭35文字が
application/x-www-form-urlencoded
(大文字・小文字の区別なし)
で、その次の文字が存在しないか、空白 (間隔、
タブ、改行) か、セミコロン (;)
なら、 application/x-www-form-urlencoded が使われています。
それ以外なら、未知の何かが使われています。
関連: Content-Type, CONTENT_TYPE
Web アプリケーション 開発
[100] XForms 1.1 ( 版) http://www.w3.org/TR/2009/REC-xforms-20091020/#serialize-form-data
[132] IRC logs: freenode / #whatwg / 20120502 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20120502#l-1099
[133] IRC logs: freenode / #whatwg / 20120616 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20120616#l-355
[134] [whatwg] multipart/form-data filename encoding: unicode and special characters ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-July/036579.html
[135] Bug 16909 – multipart/form-data: field name encoding is not specified; browsers do incompatible things ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909
[136] https://github.com/masinter/multipart-form-data/
[137] IRC logs: freenode / #whatwg / 20131010 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20131010#l-1183
[138] ( ( 版)) http://www.ietf.org/proceedings/88/slides/slides-88-appsawg-8.pdf
[139] What's the holdup? · Issue #17 · masinter/multipart-form-data ( ( 版)) https://github.com/masinter/multipart-form-data/issues/17
[140] IRC logs: freenode / #whatwg / 20140630 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140630
[141] Ajax with FormData is Broken on IE10 / IE11 in Some Conditions « 鴨七・chitsaou ( (Yu-Cheng Chuang 著, 版)) http://blog.yorkxin.org/posts/2014/02/06/ajax-with-formdata-is-broken-on-ie10-ie11
[20] Batch Requests | ArangoDB Documentation ( ( 版)) https://docs.arangodb.com/HttpBatchRequest/README.html
[181] MIME Type Detection in Windows Internet Explorer (Windows) ( 版) https://msdn.microsoft.com/en-us/library/ms775147(v=vs.85).aspx
[183] Fix form submission's encoding algorithms ( (annevk著, )) https://github.com/whatwg/html/commit/ec42efb1d7c3a2e34db21b8076a8a3f4bd6dfb81
[184] 16909 – multipart/form-data: field name encoding is not specified; browsers do incompatible things ( ()) https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909
[185] RFC 2388 has been obsoleted by RFC 7578 · Issue #398 · whatwg/html ( ()) https://github.com/whatwg/html/issues/398
[186] 136676 – no quoting at all in MIME-Headers (Content-Disposition header not escaped) ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=136676
[187] Editorial: reference RFC 7578 instead of RFC 2388 (eehakkin著, ) https://github.com/whatwg/fetch/commit/5d5e80db32cf917233ffa4e95c032f86b7d9f42c
[188] Add a space before multipart/form-data's boundary parameter (annevk著, ) https://github.com/whatwg/fetch/commit/4f53460fc2d1773ef38633c3c7ac23cf1affb08c
[189] Clarify package data algorithm for FormData (eehakkin著, ) https://github.com/whatwg/fetch/commit/e03ee6fc7f6234005a058d9784e95861b9a0a301
Implement a Servlet filter which will validate Content-Type and throw away request with suspicious values not matching multipart/form-data.
For x-www-form-urlencoded and multipart/form-data requests, Micropub supports an extension of the standard URL encoding that includes explicit indicators of multi-valued properties. Specifically, this means in order to send multiple values for a given property, you must append square brackets [] to the property name.
[195] RCS MaaP Chatbot API Specifications Version 1.0 () https://www.gsma.com/futurenetworks/wp-content/uploads/2017/11/FNW.11_v1.0.pdf
[196] Move _charset_ handling to construct the form data set (tkent-google著, ) https://github.com/whatwg/html/commit/8c212e549607a41b6d40d953b47d9f3e749533f3
[197] Move _charset_ handling from "multipart/form-data encoding algorithm"… by tkent-google · Pull Request #3645 · whatwg/html () https://github.com/whatwg/html/pull/3645
[199] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#-F
[200] Use UTF-8 decode without BOM for multipart/form-data (annevk, , ) https://github.com/whatwg/fetch/commit/7db8ac52245d6f0abaaeec6ae1cd96553c30b737
[201] Should Body.formData() always strip the BOM? · Issue #650 · whatwg/fetch () https://github.com/whatwg/fetch/issues/650
[202] Use UTF-8 decode without BOM for multipart/form-data by annevk · Pull Request #915 · whatwg/fetch () https://github.com/whatwg/fetch/pull/915
[203] andreubotella/multipart-form-data: A web-spec definition of multipart/form-data and related algorithms. () https://github.com/andreubotella/multipart-form-data
[204] multipart/form-data (, ) https://andreubotella.github.io/multipart-form-data/