name

Content-Disposition: ヘッダー filename 引数 (MIME、HTTP)

[9] Content-Disposition: ヘッダーfilename 引数は、当該実体が保存される際のファイル名ヒントを示すものです。

[130]引数MIMEHTTPmultipart/form-data で使われています。

multipart/form-dataMIME とも HTTP とも一部異なる構文や処理方法が採られていますので、本項では区別しています。

仕様書

意味

[19] MIME実体 / HTTP payload を単独のファイルとして保存する際のファイル名を提案するものです >>18, >>55

構文

[17] 構文上は filename 引数の値は無制約となっています >>16, >>55

[25] MIME では RFC 2231HTTP では RFC 5987 により拡張された構文 (filename*) によって長い名前や非ASCII文字も扱えます。

>>122 参照。

[27] 多くのシステムでは利用できる文字や長さに制限があることに注意が必要です。 短い英数字のみのファイル名であれば、受信側で修正することになる可能性は低くなります。 >>18

[91] 多くの利用者エージェントは、引用文字列中の quoted-pair\ を正しく処理できません >>55

[92] \ がどうしても必要なのは "\ を含めたい時ですが、 ファイル名にこれらを使えないファイルシステムが多いので、 実際にはそのような場面はあまりないでしょう。

[165] multipart/form-data本体部分において、 どのブラウザも常に quoted-string を使います。 WinIE\quoted-pair にしません。 >>266

[167] 未確認ですが、 Content-Disposition: ヘッダーname 引数の場合同様、 特別な文字の扱いはどのブラウザもおかしいのだろうと思われます。

[93] 字句引用文字列として指定された値に % のあとに十六進数字が2つ続くような文字列が含まれる時はパーセント符号化と誤解されないよう注意が必要です。

>>110 参照。
拡張構文を使えば曖昧なく指定できます。

空文字列

[33] 構文上は空文字列も認められています。

[34] しかし空文字列ファイル名として指定する意味があるとはあまり思えません。

[161] 空文字列が何を意味するのかは、仕様上も明確になっていません。

[35] multipart/form-data においては、 ファイルアップロードにおいてファイルが指定されていない場合に空文字列ファイル名が用いられます。

[188] 空文字列を正しく扱えない実装があり (>>186)、要注意です。

引数値における非 ASCII 文字

[11] ファイル名にはしばしば非ASCII文字が使われます。 そのため filename 引数にも非ASCII文字が含まれることがあり得ますが、その方法は統一されておらず現在も混乱しています。

[94] 特に最近では Windows だけでなく Un*x 系でも漢字のファイル名を使ったりする人が増えてきましたから、 大きな問題となります。

[95] IETF 的には RFC 2231 (旧 RFC 2184) の拡張構文 (引数 (MIME) を参照。) を使うのが正統な方法ですが、MIME の歴史の中では比較的新しいことや、 複雑であることから、当初あまり実装されず、各 MUA が異なる方法で非ASCII文字を扱っていました。

[96] HTTP でも RFC 2231 に従うべきというのが“専門家”の見解でしたが、 MIME ではなく MIME もどきを採用している HTTP にも RFC 2231 が適用されるのかは RFC 6266 が出版される2011年(!)まで明確な根拠がありませんでした。

[97] ですから、安全にファイル名をやり取りしたいと思ったら、 ASCII の英数字だけに限定する方が得策です。 しかし、一昔前ならともかく、 多言語・多文字が当たり前の現在ではこのような仕様は批判されても当然でしょう。

proto
プロトコル
qs
引用文字列
pe
パーセント符号化
ew
符号化語
2231
拡張構文
proto
電子メール/MIME
2231
qs
US-ASCII 限定
pe
×
ew
○ (仕様上は禁止)
proto
HTTP
2231
略式
qs
charset 依存? (仕様上は US-ASCII のみ)
pe
× (過去にあった)
ew
× (過去にあった)
proto
multipart/form-data
2231
×
qs
容認 (charset 依存)
pe
ew
×
proto
SIP
qs
UTF-8
pe
×
ew
×
2231
×

符号化語を使う方法

[12] 非ASCII文字を扱う方法として非常に広く採用されているのが、 値である引用文字列の中で符号化語 (MIME RFC 2047 encoded-word) を使うというものです。

[98] 例えば filename="=?iso-2022-jp?b?...hogehoge...?=" のようにします。

[101] MIME は明確に引用文字列内での符号化語の使用を禁止しています >>100 し、 RFC 6266 もそれを本方法が不適切である理由に挙げています >>99

[102] ただ RFC 2184 登場以前はメールヘッダーにおける符号化の唯一の方法が符号化語でしたから、 それを同じくヘッダーの一部である filename 引数の値にも適用するよう拡張するとの判断自体はそうおかしなものでもなかったのでしょう。

[103] RFC 2047Content-Disposition:引数値での符号化語を明示的に禁止しています >>100 が、 その前の版である RFC 1522 は言及していません (そもそも Content-Disposition: ヘッダーがまだありませんでした)。 元々 RFC 822 ヘッダーのどこで符号化語を使うことができ、 どこで使うことができないかを定める趣旨の規定だったのですから、 MIME で新たに追加されたヘッダーにおいて符号化語をどう利用するかは本来それに束縛される必要はなかったはずです。
[104] HTTP では、 RFC 2616 世代までは一部のヘッダー引用文字列内で符号化語を使うことを認めていました (RFC 723x 世代でこの規定は削除されました)。 RFC 2388符号化語を認めていました。符号化語を使う方法はむしろそちらと整合性があったとも言えます。

[105] 90年代末には、 MSOE をはじめ広く使われている MUA がこの方法で filename 引数の値を解釈していました。

[106] 現在でも Gmail はこの方法で引数の値を読み書きしているようです。

[107] ファイル名が短い時は、 (ASCII文字が含まれていたとしても) 全体が UTF-8 B符号化符号化語として引用文字列内に含まれます。 長い時は間に FWS が入った複数の符号化語に分割されます。

[108] 電子メール/MIME では、互換性のためにこの方法を実装する必要があります。

[109] HTTP では、以前は Firefox が実装していましたが現在は削除されており >>87、 この方法に対応する必要はなさそうです。

[162] multipart/form-dataSIP ではこの方法が用いられたことは歴史的にもないと思われます。

[124] ファイル名を指定する古い方法である Content-Type: ヘッダーname 引数でも、同じくこの方法が使われることがよくあります。
[125] Gmail>>124 のように動作します。

符号化しない方法

[13] ファイル名が特別な符号化なしでそのまま字句引用文字列として指定されることもあります。

[114] 電子メールは長らく8ビット安全ではありませんでしたが、 日本語EUCシフトJIS文字符号化として使った値が用いられることがしばしばありました。

[20] HTTP でもしばしばこの方法が用いられます。 RFC 6266UTF-8 らしい値が指定されると UTF-8 として解釈する実装があると述べています >>115。その他に payload body と同じ符号化が用いられることもあると思われます。

[117] 仕様上は RFC 2068RFC 2616 時代は引用文字列の値を ISO-8859-1 と解釈することになっていましたが (RFC 723x はこれを撤回したものの、どう解釈するべきか明確にしていません。)、 実際上は payload body と同じと解釈するのが適当と思われます。
[121] RFC 6266UTF-8 と解釈する実装があることを根拠に非ASCII文字があるとき (ISO-8859-1 で表現できるとしても) 引用文字列を使わないことを薦めています >>120 が、 RFC 723x では引用文字列における非ASCII文字を禁止していますから、 現行仕様に従うなら非ASCII文字を含むなら必ず拡張構文を使う必要があります。

[119] RFC 6266sniffing は誤解釈する問題があるので本方法は不適切としています >>115 が、現在の状況からすると HTTP においては必ず UTF-8 として解釈する、 あるいは payload body として解釈すると規定しても良かったはずです。 最も単純で実装しやすいはずなのに敢えてより複雑な拡張構文のみを正しいとするのは、 はじめから RFC 2231 が歴史的に正当であるとの結論ありきの議論のようにも思えます。

[32] multipart/form-data では、 filename 引数は常に引用文字列で、非ASCII文字も含めて提出時の charset で(のみ)符号化されます。 RFC 7578 もそのように説明しています >>155, >>173

[166] RFC は言及するだけで、それを肯定も否定もしていません。相互運用性のためにはその動作を必須とするべきなのでしょうが、そうなっていないのは、 他の RFC と矛盾すると IETF 的にまずいからでしょうか...

[168] 表現できない文字十進数文字参照になるのも本体と同じです。 (HTTP提出する場合のみ調べています。) >>266

[266] Firefox 3.0.4、Opera 9.61、Safari 3.2、WinIE 7 の実装状況を調べてみました。

[116] SIP では引用文字列UTF-8 を使うことが認められています。 SIP では RFC 2231 の方法は認められておらず、 UTF-8 でそのまま指定するのが唯一の正当な方法となっています。

[183] Safari 15ではダウンロードしたファイル名が文字化けすることがある - Togetter () https://togetter.com/li/1794752

[184] 今更こんなWeb非互換な変更をぶっこんでくるApple鬼畜やなあ。

[185] 元を辿ればふざけた仕様を数十年放置したIETFが悪いんだが、それを言い出すと全部IETFが悪いからなw

パーセント符号化

[110] HTTP では、値がパーセント符号化されることもあります。その場合の文字符号化payload body で使われている符号化だったり、利用者エージェントlocale や設定に依存したり、自動判別されたりするようです。 >>111

[112] HTTP (RFC 6266) は、対応していない利用者エージェントパーセント符号化された文字列がファイル名として使われてしまうこと、 どの文字符号化が使われているか明確で無いことからこの方法は不適切としています >>111

[40] WinIEHTTPパーセント符号化された字句引用文字列の指定に対応しています。 WinIERFC 2231 の構文に対応する前はこの方法に fallback すればよいと言われていました。

[113] MIME でこの方法が採られるのは見かけません。

[118] HTTP でももはやこの方法に対応する必要は無いのかもしれませんが、はっきりしません。

[179] ChromeFirefox も、この方法に対応しているようです。

[180] グループウェアWebアプリケーションには、未だにこの方式のみを採用しているものがあるようです。

[163] multipart/form-data本体部分では、 MIMEヘッダーUS-ASCII しか使えないシステムとの互換性のため、 パーセント符号化しても構わない >>155、とされています。

[164] 仕様に従う MIME システムとの互換性のためには必ずパーセント符号化しなければならないことになってしまいます。 現実の MIME システムはそうでもないので必ずしもパーセント符号化しなくて構わないといえます。 (そして現実には multipart/form-dataファイル名は何も符号化しません。)

RFC 2231 の拡張構文

[122] MIME では RFC 2231HTTP では RFC 5987 の拡張構文 (filename* 引数) により非ASCII文字を使うことができます。

引数 (MIME)>>11 を参照。
[26] RFC 2183 には同時に発行された RFC 2184 (後に改訂されて RFC 2231) を参照して非ASCII文字を扱えると述べている箇所と、非ASCII文字は扱えず将来の拡張が待たれるとしている箇所があり、 矛盾しています。 RFC 2183RFC 2184 は同時に出版されたにも関わらず、 前者が後者により更新される形が採られています。記述に矛盾があるとはいえ、 RFC 2184/RFC 2231 の拡張が適用され、非ASCII文字も扱えると解釈するのが一般的です。

[123] 90年代から00年代中頃まではこの方法はあまり実装されていませんでしたが、 その後徐々に対応が広がってきています。

[126] 現在では多くの MUA がこの方法で電子メール/MIME実体に指定された名前を理解できるようです。 しかし送信時にこの方法を使うとは限りません。

[127] Webブラウザーはこの方法で HTTP に指定された名前を理解できるようになっています。

[128] HTTP では仕様上 UTF-8ISO-8859-1 を使えることになっていますが、 実装によっては UTF-8 しか対応していないので、 UTF-8 を使うべきです >>120

[63] HTTP では、旧来の構文 (filename) しか理解しない受信者に対応するため、 旧来の構文と拡張構文 (filename*) の両方を指定することができます >>55, >>120。その場合、一部の実装との互換性の問題のため、 filename を先に置くべきです >>120

[160] multipart/form-data実体本体では、拡張構文を使ってはなりません >>155

[169] multipart/form-data本体部分ではこの方法が用いられたことは歴史的にも現実にはなかったと思われますが、 仕様上は混乱がありました。

[172] HTML4 は、 UA 側システムのファイル名が US-ASCII でないときには、 ファイル名は近似するか、 RFC 2045 の方法で符号化しなければならない HTML 4 17.13.4.2 と述べていました。しかし RFC 2045 の方法とは一体何を指しているのか不明で、それらしい規定は見当たりません。

[170] RFC 2388 は、 RFC 2045 ではなく、 RFC 2231 の方法を使っても良いとしていました RFC 2388 4.4。 この規定は RFC 2231 とは整合していますが、 encoded-word を使うべしとする name 引数の規定とは一貫しておらず、本当に使い分けろというのか謎でした。

[171] それから17年後の RFC 7578 でようやく改訂され、拡張構文は明確に禁止されています >>155

[129] SIP ではこの方法は使われません。

文脈

[29] filename 引数は、 disposition型に関わらず任意の MIME実体に指定できます。 Content-Disposition: inline であっても指定して構いません >>18

[31] しかし多くの場合は Content-Disposition: attachment と共に使用され、電子メールにおいては添付ファイルファイル名を、 HTTP においてはダウンロードファイル名を表します。

[49] multipart/form-data においては、 <input type=file> などでファイル提出した際に当該ファイルファイル名を指定するために filename 引数が用いられます。

この場合の disposition型form-data です。

[159] multipart/form-data本体部分ファイルを表す場合、 filename 引数ファイル名を指定するべきです >>155

>>156 も参照。

[134] VPIM では、ファイル名情報が利用可能なら、 filename 引数を指定するべきです >>133

[135] なお VPIM では Content-Disposition: inline の指定が必須となっています。

処理モデル

[56] MUA では、添付ファイルが存在する旨の文字やアイコンに添えて表示したり、 ツールチップで表示したりできます。

[57] Content-Disposition: attachment で用いられている場合は、 MUA添付ファイルの保存を利用者が選択した時にファイル名の元として利用したり、 HTTP応答に含まれていた時に保存先を選択するにあたりファイル名の元として利用したり >>55 できます。

[58] Content-Disposition: inline で用いられている場合は、 MUA で表示中の実体の保存を選択した時にファイル名の元として利用したり、 Webブラウザーで表示中のページの保存を利用者が選択した時にファイル名の元として利用したり >>55 できます。

[53] ダウンロードファイル名 (の既定値) の決定に filename 引数の値が使われることがあります >>51, >>52

ダウンロードも参照。

[21] filename 引数を受信した MUA が当該実体ファイルとして保存する際は、 指定されたファイル名をできるだけ実際のファイル名の基礎として用いるべき (should) です >>18

[28] ただし filename 引数があるからといって受信した実装がファイルに保存しなければならないわけではありません。 利用者が特に要求しない限り、当該実体を通常のメールの処理の一部として表示したとしてもまったく問題ありません。 >>18

[61] HTTP では、 filename 引数が旧来の構文と拡張構文の両方で指定された場合、 拡張構文を採用し、旧来の構文を無視するべきです >>55

引数 (HTTP)も参照。
[62] MIME では特に規定がありません。

[50] なお、 RFC 2231/RFC 5987 の拡張構文では引数言語タグを指定できますが、 ファイル名では言語はあまり使われず、無視されるであろうと RFC 6266 は述べています >>41

ファイル名の決定とセキュリティー

[65] MIME でも HTTP でも filename の指定はヒント >>55 とされています。 利用者エージェント利用者も、 filename の指定に関わらず任意のファイル名を使うことができます。

[66] 実装によっては filename で指定されたファイル名を原則そのまま (都度利用者に確認することなく) 保存に使うものがありますが、 セキュリティーには十分な配慮が必要です。

[67] また利用者に都度ファイル名を確認する場合で、 filename の値は単にその既定値として示すだけであったとしても、利用者が意図せずシステムを破壊してしまったり、 ファイルを危険な位置に保存してしまったりすることがないよう、 配慮が必要でしょう。

[22] MUA は何も考えずに指定されたファイル名を使ってはいけません。 保存先のファイルシステムの規約に従っているか、 既存のファイルを上書きしてしまわないか、 セキュリティー上の問題を起こさないかを検査して、 必要なら変更するべきです >>18

[23] MUAfilename 引数で指定された値にディレクトリーの部分があっても、 それに従うべきではありませんディレクトリーを除いた狭義のファイル名の部分のみを使うべきです >>18

[24] RFC 2183 は将来の拡張で Content-Disposition: ヘッダーの他の引数ディレクトリーを指定できるようにする可能性を示唆しています >>18 が、その後そのような動きはなく、今後もそのような仕組みが新たに追加されることはなさそうです。

[68] HTTP 受信者は、利用者に指定された位置以外にファイルを保存させることができてはなりません。 この要件を満たす方法の例として、 /\ のようなフォルダーの名前との区切りの文字よりも前の部分はすべて除去することができます。 >>55

[71] 具体的な方法が仕様上要求されていないのは、要件が OSファイルシステムなどに依存するというのが大きな理由でしょう。例えば実際のファイルシステムではなくデータベースサーバー上に添付ファイルを保存するクラウドストレージサービスと連携した WebブラウザーMUA なら、任意の文字列を安全にファイル名として指定できるかもしれません。

[10] RFC 2183 にも記述がありますが、例えば /etc/passwd >>37 というファイル名が指定されていたとしましょう。 UA がその名前でファイルを保存してしまって、しかもたまたま permission 的にもそれが成功してしまうと、 Un*x 系の処理系では困ったことになります。 (そのような permission にしてあるのも問題ですが...)

ですから、この値は参考程度とするべきものであって、 自動処理でこの名前をそのまま使う時は、 細心の注意を払う必要があります。

[38] システムにより特別な意味を持った名前のファイルを利用者が意識せずに作ってしまったり、 PATH が通ったディレクトリーに実行可能なファイルを置いてしまったりしては危険ですから、 実装は何らかの配慮をするべきでしょう >>37

[15] Windows のファイル選択対話箱とショートカットの組合せでファイルを書き換えるよう利用者を誘導し得ることが知られています。 このように、システムにファイル・システム内のリンク機能の類があり、 ファイル名の決定に関する利用者界面に不備があると安全上の問題になり得ます。 利用者への配慮のつもりが却って問題のもとになることもありますから、 よく考慮しなければなりません。

[80] 多くの環境ではMIME型ファイルシステム上に保存できず、 ファイル名拡張子によってファイルの種類を表します。 そのような環境では拡張子が安全でMIME型と一致したものとなるようにしなければなりません >>55

[79] Windows ではファイル名の拡張子と呼ばれる接尾辞の部分が省略されて表示されるのが標準の設定で、 その設定を変更してもショートカットなど一部の種類のファイルは依然表示されません。 それを悪用して example.txt.lnkexample.txt.vbs のようにファイル名を偽装 する方法が Outlook Express を対象によく行われています。

[83] ファイルシステムによってはダウンロードした外来のファイルを表す属性が存在することがあります。 保存時にそのような属性を設定することで、送信者が指定した拡張子MIME型、あるいは利用者が選択した拡張子によって当該ファイル実行可能と判断される場合で、 後に利用者がそのファイルを実行するよう指示した時に、 本当に実行してよいか OS から確認させることができます。

[81] 表示上、あるいはファイル名として問題となる文字、 例えば制御文字や末尾の空白は、削除するべきです >>55

[39] プログラミング言語ライブラリー等によっては、 パイプ >>37リダイレクトなどに使用する特殊な文字をファイル名と共に使用することができ、 利用者が意図しないコマンドが実行されてしまったり、 ファイルが書き換えられてしまったりする危険性があります。

[90] その他ファイルシステムシェルで問題となる文字文字列として、 ...~|デバイス名などがあります。受信者はこれらを無視したり、 置き換えたりするべきです>>55

ファイル名に意味が無い場合

[156] multipart/form-data では filename 引数は指定するべきとはいえ、必須ではない >>155 とされています。

[157] ファイル名は、取得できないこともあるかもしれません >>155。 利用する OSAPI などのファイルの取得方法次第で、 ファイルの内容にはアクセスできても、ファイル名にはアクセスできないかもしれません。 一般的なパソコン等とは異なるシステムでは、ファイル名がなかったり一般的なファイルシステムとは異なる形でファイルを扱っているかもしれません。

[158] ファイル名は、意味がないものかもしれません >>155外部装置からの入力を受ける一時ファイル名 (機械的に付けられたもの) かもしれません。

ファイル名の互換性問題

[4] filename 引数ではなくファイル名そのものが持つ大きな問題が、 ファイル名の制限や慣習の違いです。次に幾つかの例を挙げますが、 この他にも様々な問題があり、送信側は filename 引数を指定するにしても余り多くを期待しないこと、 受信側は filename 引数の値をありとあらゆる可能性を検討しつつそのシステムで適切な形に適宜変換することが重要です。

[5] 古いファイル・システムは 8文字に名前が制限されることがあり、 filename 引数でも互換性のためにそれに従うことを進める仕様もあります 例えば RFC 3851 3.2.1

[6] ファイル・システムによっては大文字・小文字が区別できなかったり、 区別を保存はできても大文字・小文字だけが異なるファイルが同時に存在できなかったりします。 大文字・小文字の範囲が異なることもあります (例: ギリシャ文字, 互換性文字, ...)

[7] 多くのシステムでは拡張子と呼ばれる接尾辞によってファイルの種類を表すことが行われています。 特定の接尾辞を付けることを呼びかける仕様もある 例えば RFC 3851 3.2.1 一方で、 Content-Type と重複する情報であり、 利用者エージェントがシステムの慣習や制限に従い自動的に付加するのが望ましいという意見もあります。

[8] ファイル・システムやオペレーティング・システムのファイルにアクセスするための仕組みで採用している文字コードは様々です。 あるシステムで使える文字が別のシステムで使えなかったり、 使うと問題の基になったりすることは少なくありません。 実体で使われている文字コードからシステムの文字コードへの変換も適切に行わなければなりません。 ASCII の範囲は割と安全ですが、 EBCDIC 系などもありますから安心できません。シフトJIS の2バイト目が ASCII と衝突して云々のような問題もあります。 文字コードそのものの問題だけではなく、 特殊な意味に使われるために予約されている文字もシステムによって様々です。 英数字なら安全と思いきや、 逃避などの目的で使われることもあるから油断できません。

[14] 多くのシステムには /devCON のような特殊な名前のファイルがあります。安全性に関わりますから特に注意が必要です。 ファイル・システム的に特殊でなくても、 システムにおいて重要なファイルにも注意が必要です (>>10)。

[46] 現代的なファイル・システムはディレクトリによって階層化された名前空間でファイルを管理していますが、 その経路でディレクトリ名やファイル名の区切りとして使われる文字は様々です。 Un|x では /、伝統的な Mac OS では :Windows では \ が使われます。 他のシステムでは他の文字が使われているかもしれません。

シフトJIS のように、バイト列で \ が使われる文字コードが使われるシステムもあります。

[47] 階層的なファイル・システムでは . (同じ階層) や .. (一つ上の階層) や ... (二つ上の階層) のように相対的な参照のための仕組みを用意していることがあります。 安全面から特定の階層へのファイルの保存のみを認めたつもりでも、 ファイル名にこのような特殊な文字列が含まれているとそのチェックをすり抜けられるかもしれません。 利用者エージェントはそのシステムの仕組みに応じて厳しいチェックが必要です。

[48] なお、システムによっては、ファイル・システムで本来認められない文字オクテットを使った名前のファイルが作れてしまい、 そのシステム標準の方法では削除できないということがあり得ます。 安全対策を行った上で filenameSubject などからファイル名を決定するとしても、 使用する文字オクテットが本当に安全なものかどうかをよく確かめなければなりません。

実体間のファイル名の関係

[131] 仕様上、各実体ファイル名の関係は明記されていません。 multipart/* に含まれる実体本体で相互にファイル名を使って参照できるとはされていませんし、 ファイル名が重複していていけないとの規定もありません。 ディレクトリ名のように見える文字列が含まれていたとしても、 それらのファイルが同じディレクトリに保存されるとも、 別のディレクトリに保存されるとも何ら保証されません。

[132] RFC 2388multipart/form-data によるファイル提出に関して、ファイル名で相互参照されている可能性があるため、 ファイル名が保持されると有用だと述べています (multipart/form-data (>>45)参照)。 ただ具体的な要件や処理方法を定めているわけではありません。

実装

[186] ファイルアップロードを受け付けるHTTPサーバー (アプリケーションサーバー) の中には、 filename="" 引数によって (空文字列ではない) ファイル名が指定されていない場合に、 ファイルが存在すると認識できずにエラーを返すものがあります。

[187] ファイルアップロードに対応したクライアントライブラリーは、 Web互換性のため、アプリケーションからファイル名が与えられなかったときでも file.dat のような適当なファイル名を補った方が良いのかもしれません。

SDP 'file-selector' 属性 'name' 選択子

[139] SDP'file-selector' 属性name 選択子は、 Content-Disposition: ヘッダーfilename 引数に対応するものです >>138

[140] 'name' では値として直接指定またはパーセント符号化のいずれかを " で括った構文 (UTF-8) を採用しています >>138

歴史

Content-Type: ヘッダー name 引数

[44] Content-Type: 欄の name 引数: MIME の初版、 RFC 1341 では application/octet-streamファイル名を表す name 引数がありました >>151。 しかし、この引数が Content-Type: 欄そのものの引数と誤解され、 媒体型に関わらず name 引数はファイル名と扱われるようになってきました。 そこで IETFContent-Disposition: 欄を用意して ODE(MIME)[filename]] 引数を設け、 application/octet-streamname 引数は廃止しました。

[154] RFC 2046 は「非推奨 (deprecated) となっている」 >>152 と述べています。同じく削除された conversions 引数は「削除」と説明しているのに対し、 name は「非推奨」と区別して記述されていますが、その意図は不明です。

[153] 現在では Content-Type: 欄の name 引数だけを見てファイル名を決める利用者エージェントはもはや存在しないと推測されますが、 依然として多くの利用者エージェントがメッセージ作成時に Content-Disposition: 欄の filename 引数と (媒体型に関わらず) Content-Type: 欄の name 引数の両方にファイル名を入れています。

[45] ファイル名を表す name 引数を持つ媒体型:

媒体型状態出典
application/octet-stream廃止 (IETF 提案標準)RFC 1341
application/pkcs7-mimeIETF 標準化過程RFC 3851 3.2.1

注: RFC 3851 (S/MIME) は application/pkcs7-mime で両方の引数を付けることを推奨しています。

Content-Disposition: ヘッダー filename 引数

[30] Content-Disposition http://tohoho.wakusei.ne.jp/lng/199903/99030058.htm : Windows の実装の状況 (1999)。

[36] 414647 - [IE5] Content-Disposition: の DBCS ファイル名(5C)が認識できない http://support.microsoft.com/default.aspx?scid=http://www.microsoft.com/japan/support/kb/articles/JP414/6/47.asp (WinIE 4, WinIE 5)

HTTP で使われるときに、例えばシフトJISfilename=表.xls とあったら、 保存時の既定名が 表.xls ではなくて URI の末尾の部分と同じになるという話。

0x5C を quote として落とすだけなら分かる (仕様上正しい動作) だけど、全く無視してしまうのはおかしい。(けど、 の片割れが残って、 不正なファイル名→無視と判断しているのならまともかもしれない。)

なんにせよ、この文書での M$ の立場は本来 US-ASCII しか使えないけど、 DBCS もおまけで対応してるよん☆らしい。 M$ にしては珍しくまともなことを言ってるね。

[42] Bug 162765 - RFC2231 filename support for nsExternalAppHandler http://bugzilla.mozilla.org/show_bug.cgi?id=162765 : Mozilla が RFC 2231 方式に対応したという話。

[43] Mozilla 1.2.1 Navigator で、「ファイル」->「ページを送信」してメイルに添付して送ろうとしますと、たとえばみてた URI が http://foo.example/path/to/resource であるなら、 filename 引数は foo.example/path/to/resource になりました。

これってどう考えれば良いのだろう。 別に間違ったことをしているわけではないけど、あまり正しいようにも思えない。 (名無しさん 2004-05-10 04:45:59 +00:00)

[1] HTML form からのファイルうpの時の filename 引数の値、 WinIE6 では完全経路名、 Mozilla 1.4 と Opera 7.20 では狭義のファイル名になりました。 (MIME 的には後者が適当。)

[2] 引数の値の符号化は、 multipart/form-data の他の部分と同じになりました。

[3] >>1 WinNN 3.0 では完全経路名、 MacNN 3.0 では狭義ファイル名。

[59] FirefoxはRFC 2231実装してますね。WinIE6やOpera8はしていませんが。 (成瀬 2005-05-22 08:58:59 +00:00)

[64] Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding ( 版) http://greenbytes.de/tech/tc2231/

[69] Test Cases for HTTP Content-Disposition header field and the Encodings defined in RFC 2047/6266 and RFC 2231/5987 ( ( 版)) http://greenbytes.de/tech/tc2231/

[72] Content-Disposition FireFoxとIEの挙動の違い - 開発者の談話室 ( ( 版)) http://www.agile-tech.com/blogs/dev/2007/12/contentdisposition.html

[73] 日本語ファイル名 ( ( 版)) http://oku.edu.mie-u.ac.jp/~okumura/php/filename.php

[74] Japanese: 日本語ファイル名をIEでダウンロードするときの文字化け対策 ( ( 版)) http://moodle.org/mod/forum/discuss.php?d=72567

[75] 日本語ファイル名の悩み (サイボウズ Office 開発ブログ) ( ( 版)) http://cydn.cybozu.co.jp/office/2008/07/post_1.html

[76] 久しぶりの技術ネタ。HTTPレスポンスヘッダの[Content-Disposition]について、Safariでの日本語文字化け対策など。 - maachangの日記 ( ( 版)) http://d.hatena.ne.jp/maachang/20110730/1312008966

[77] Example file ( ( 版)) http://suika.fam.cx/~wakaba/test/web/http/content-disposition/non-us-ascii-filename.cgi

[78]

Content-Disposition: attachment; filename=%E4%B8%80%E4%B8%81; filename*=utf-8''%E4%B8%80%E4%B8%81
... のように UTF-8符号化してパーセント符号化したのを直接指定するのと、 RFC 6265 に従って UTF-8符号化したのを、両方指定すると、 IE を含む全 Webブラウザーでいい感じに復号してくれます。

[82] IE9以降でもHTMLフォームでファイル名とファイルの中身を外部から指定できる | 徳丸浩の日記 ( ( 版)) http://blog.tokumaru.org/2014/01/ie9html.html

[84] ファイルをダウンロードする ASP.NET ページで日本語ファイル名が文字化けする ( ( 版)) http://support.microsoft.com/kb/436616/ja

[85] ダウンロードファイル名の文字化け ( (WebSurfer 著, 版)) http://surferonwww.info/BlogEngine/post/2011/03/20/Downloading-file-with-Japanese-file-name.aspx

[136] draft-harding-ediint-filename-preservation-03 - Filename Preservation for EDIINT ( 版) http://tools.ietf.org/html/draft-harding-ediint-filename-preservation-03

RFC 6266

[60] RFC 6266 以前の多くの利用者エージェントは、 RFC 2231/RFC 5987引数拡張構文を実装していません >>55

[70] RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) ( ( 版)) http://tools.ietf.org/html/rfc6266

[86] Bug 84977 – Add Support for RFC 5987 (Non-ASCII HTTP Header Keys/Values) for filenames ( ( 版)) https://bugs.webkit.org/show_bug.cgi?id=84977

[87] 601933 – remove RFC 2047 encoding support for HTTP header field parameters ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=601933

[88] 610054 – Clean up RFC 2231 MIME param handling, and add support for RFC 5987 subset ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=610054

[89] Downloads and International Filenames - IEInternals - Site Home - MSDN Blogs ( ( 版)) http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx

関連

[54] ダウンロードの際のファイル名既定値の決定には、 filename 引数の他に HTMLdownload 属性の値も使われます。

[137] RFC 5273 - Certificate Management over CMS (CMC): Transport Protocols ( ( 版)) http://tools.ietf.org/html/rfc5273#section-3

[141] RFC 6047 - iCalendar Message-Based Interoperability Protocol (iMIP) ( ( 版)) https://tools.ietf.org/html/rfc6047#section-2.6

[142] HTTP::Response - search.cpan.org ( 版) http://search.cpan.org/dist/HTTP-Message/lib/HTTP/Response.pm#%24r-%3Efilename

A "Content-Disposition:" header in the response. Proper decoding of RFC 2047 encoded filenames requires the MIME::QuotedPrint (for "Q" encoding), MIME::Base64 (for "B" encoding), and Encode modules.

[143] HTTP::Response - search.cpan.org ( 版) http://search.cpan.org/dist/HTTP-Message/lib/HTTP/Response.pm#%24r-%3Efilename

The filename is obtained from one the following sources (in priority order):

A "Content-Disposition:" header in the response. Proper decoding of RFC 2047 encoded filenames requires the MIME::QuotedPrint (for "Q" encoding), MIME::Base64 (for "B" encoding), and Encode modules.

A "Content-Location:" header in the response.

The URI used to request this response. This might not be the original URI that was passed to $ua->request() method, because we might have received some redirect responses first.

[144] Site Compatibility for Firefox 22 - Mozilla | MDN ( 版) https://developer.mozilla.org/en-US/Firefox/Releases/22/Site_compatibility#RFC_2047_encoding_support_for_HTTP_header_field_parameters_has_been_removed

When decoding the filename parameter in Content-Disposition headers, Firefox had attempted to unescape using the RFC 2047 encoding. This was a bug according to the relevant specs, and implemented only on Firefox and Chrome. The RFC 2231/5987 encoding can be used instead.

Update: This change has been postponed to collect and analyze data on the usage of the RFC 2047 encoding.

[145] 601933 – remove RFC 2047 encoding support for HTTP header field parameters ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=601933

[146] 875615 – Revert to decoding RFC 2047-encoding until we have telemetry on usage ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=875615

[147] Issue 41308 - chromium - Non-standard Content-Disposition headers from Outlook Web Access are not handled - An open-source project to help move the web forward. - Google Project Hosting ( 版) https://code.google.com/p/chromium/issues/detail?id=41308

[148] 651185 – double quotes aren't a legal delimiter for 2231/5987 encoding ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=651185

[149] 511521 – (CVE-2009-3376) downloading file with RTL override (RLO) presents conflicting filenames ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=511521

[150] Issue 72935 - chromium - Chrome saves Excel files as "Main.aspx" in text mode instead of an actual Excel file - An open-source project to help move the web forward. - Google Project Hosting ( 版) https://code.google.com/p/chromium/issues/detail?id=72935

[174] Fix #25: bring back FormData's append()'s filename argument · whatwg/xhr@b0ec31e ( 版) https://github.com/whatwg/xhr/commit/b0ec31ea3f70b1c465ae54d6d5dcd2acde833ea9

[175] Fix #48: align with HTML's form submission algorithm · whatwg/xhr@7b1941f ( 版) https://github.com/whatwg/xhr/commit/7b1941fbd5347433734a491c36ef8ea6485e7dfb

[176] S3のContent-Dispositionのブラウザ対応について調査してみた - Innovator Japan Engineers’ Blog () http://tech.innovator.jp.net/entry/s3-content-disposition

RFC 5987 が各最新ブラウザで問題なくファイル名指定ダウンロードができることが分かりました。エンコード方法によっては400エラーになってしまったり、ファイル名が正しく指定できなかったりとサポートしていないことが分かります。

[177] Clarify package data algorithm for FormData (eehakkin著, ) https://github.com/whatwg/fetch/commit/e03ee6fc7f6234005a058d9784e95861b9a0a301

[178] Use USVString rather than [EnsureUTF16] for fileName. (mkruisselbrink著, ) https://github.com/w3c/FileAPI/commit/abf6637473a9c81247fce46ef0a2954be95908f1

[181] 69939 - Filename surrounded by hyphens in a download - chromium - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=69939

[182] Minioファイル名POST 時のチェックに使っているようで、 ファイル名空文字列だとファイル未指定のエラーにします。