[9] Content-Disposition: ヘッダーの
filename 引数は、当該実体が保存される際のファイル名のヒントを示すものです。
[130] 本引数は MIME、HTTP、multipart/form-data
で使われています。
[19] MIME実体 / HTTP payload を単独のファイルとして保存する際のファイル名を提案するものです >>18, >>55。
[17] 構文上は filename 引数の値は無制約となっています
>>16, >>55。
[25] MIME では RFC 2231、 HTTP では RFC 5987
により拡張された構文 (filename*)
によって長い名前や非ASCII文字も扱えます。
[27] 多くのシステムでは利用できる文字や長さに制限があることに注意が必要です。 短い英数字のみのファイル名であれば、受信側で修正することになる可能性は低くなります。 >>18
[91] 多くの利用者エージェントは、引用文字列中の quoted-pair
の \ を正しく処理できません >>55。
[165] multipart/form-data の本体部分において、
どのブラウザも常に quoted-string を使います。
WinIE は \ を quoted-pair にしません。
>>266
[93] 字句や引用文字列として指定された値に % のあとに十六進数字が2つ続くような文字列が含まれる時はパーセント符号化と誤解されないよう注意が必要です。
[34] しかし空文字列をファイル名として指定する意味があるとはあまり思えません。
[161] 空文字列が何を意味するのかは、仕様上も明確になっていません。
[35] multipart/form-data においては、
ファイルのアップロードにおいてファイルが指定されていない場合に空文字列のファイル名が用いられます。
[11] ファイル名にはしばしば非ASCII文字が使われます。
そのため filename 引数にも非ASCII文字が含まれることがあり得ますが、その方法は統一されておらず現在も混乱しています。
[95] IETF 的には RFC 2231 (旧 RFC 2184) の拡張構文 (引数 (MIME) を参照。) を使うのが正統な方法ですが、MIME の歴史の中では比較的新しいことや、 複雑であることから、当初あまり実装されず、各 MUA が異なる方法で非ASCII文字を扱っていました。
[96] HTTP でも RFC 2231 に従うべきというのが“専門家”の見解でしたが、 MIME ではなく MIME もどきを採用している HTTP にも RFC 2231 が適用されるのかは RFC 6266 が出版される2011年(!)まで明確な根拠がありませんでした。
[97] ですから、安全にファイル名をやり取りしたいと思ったら、 ASCII の英数字だけに限定する方が得策です。 しかし、一昔前ならともかく、 多言語・多文字が当たり前の現在ではこのような仕様は批判されても当然でしょう。
multipart/form-datacharset 依存)[12] 非ASCII文字を扱う方法として非常に広く採用されているのが、
値である引用文字列の中で符号化語 (MIME RFC 2047
encoded-word) を使うというものです。
[98] 例えば filename="=?iso-2022-jp?b?...hogehoge...?=" のようにします。
[101] MIME は明確に引用文字列内での符号化語の使用を禁止しています >>100 し、 RFC 6266 もそれを本方法が不適切である理由に挙げています >>99。
[102] ただ RFC 2184 登場以前はメールのヘッダーにおける符号化の唯一の方法が符号化語でしたから、
それを同じくヘッダーの一部である filename
引数の値にも適用するよう拡張するとの判断自体はそうおかしなものでもなかったのでしょう。
Content-Disposition:
の引数値での符号化語を明示的に禁止しています >>100 が、
その前の版である RFC 1522 は言及していません (そもそも
Content-Disposition: ヘッダーがまだありませんでした)。
元々 RFC 822 ヘッダーのどこで符号化語を使うことができ、
どこで使うことができないかを定める趣旨の規定だったのですから、 MIME
で新たに追加されたヘッダーにおいて符号化語をどう利用するかは本来それに束縛される必要はなかったはずです。[105] 90年代末には、 MSOE をはじめ広く使われている MUA
がこの方法で filename 引数の値を解釈していました。
[106] 現在でも Gmail はこの方法で引数の値を読み書きしているようです。
[108] 電子メール/MIME では、互換性のためにこの方法を実装する必要があります。
[109] HTTP では、以前は Firefox が実装していましたが現在は削除されており >>87、 この方法に対応する必要はなさそうです。
[162] multipart/form-data や SIP
ではこの方法が用いられたことは歴史的にもないと思われます。
[13] ファイル名が特別な符号化なしでそのまま字句や引用文字列として指定されることもあります。
[114] 電子メールは長らく8ビット安全ではありませんでしたが、 日本語EUCやシフトJISを文字符号化として使った値が用いられることがしばしばありました。
[20] HTTP でもしばしばこの方法が用いられます。 RFC 6266 は UTF-8 らしい値が指定されると UTF-8 として解釈する実装があると述べています >>115。その他に payload body と同じ符号化が用いられることもあると思われます。
ISO-8859-1 と解釈することになっていましたが
(RFC 723x はこれを撤回したものの、どう解釈するべきか明確にしていません。)、
実際上は payload body と同じと解釈するのが適当と思われます。[119] RFC 6266 は sniffing は誤解釈する問題があるので本方法は不適切としています >>115 が、現在の状況からすると HTTP においては必ず UTF-8 として解釈する、 あるいは payload body として解釈すると規定しても良かったはずです。 最も単純で実装しやすいはずなのに敢えてより複雑な拡張構文のみを正しいとするのは、 はじめから RFC 2231 が歴史的に正当であるとの結論ありきの議論のようにも思えます。
[32] multipart/form-data では、 filename
引数は常に引用文字列で、非ASCII文字も含めて提出時の
charset で(のみ)符号化されます。
RFC 7578 もそのように説明しています >>155, >>173。
[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
[110] HTTP では、値がパーセント符号化されることもあります。その場合の文字符号化は payload body で使われている符号化だったり、利用者エージェントの locale や設定に依存したり、自動判別されたりするようです。 >>111
[112] HTTP (RFC 6266) は、対応していない利用者エージェントでパーセント符号化された文字列がファイル名として使われてしまうこと、 どの文字符号化が使われているか明確で無いことからこの方法は不適切としています >>111。
[40] WinIE は HTTP でパーセント符号化された字句や引用文字列の指定に対応しています。 WinIE が RFC 2231 の構文に対応する前はこの方法に fallback すればよいと言われていました。
[113] MIME でこの方法が採られるのは見かけません。
[118] HTTP でももはやこの方法に対応する必要は無いのかもしれませんが、はっきりしません。
[179] Chrome も Firefox も、この方法に対応しているようです。
[180] グループウェアの Webアプリケーションには、未だにこの方式のみを採用しているものがあるようです。
[163] multipart/form-data の本体部分では、
MIMEヘッダーで US-ASCII しか使えないシステムとの互換性のため、
パーセント符号化しても構わない >>155、とされています。
[122] MIME では RFC 2231、 HTTP では RFC 5987 の拡張構文
(filename* 引数) により非ASCII文字を使うことができます。
[123] 90年代から00年代中頃まではこの方法はあまり実装されていませんでしたが、 その後徐々に対応が広がってきています。
[126] 現在では多くの MUA がこの方法で電子メール/MIME実体に指定された名前を理解できるようです。 しかし送信時にこの方法を使うとは限りません。
[127] Webブラウザーはこの方法で HTTP に指定された名前を理解できるようになっています。
[128] HTTP では仕様上 UTF-8 と ISO-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
引数の規定とは一貫しておらず、本当に使い分けろというのか謎でした。
[29] filename 引数は、 disposition型に関わらず任意の
MIME実体に指定できます。 Content-Disposition: inline
であっても指定して構いません >>18。
[31] しかし多くの場合は Content-Disposition: attachment
と共に使用され、電子メールにおいては添付ファイルのファイル名を、
HTTP においてはダウンロードのファイル名を表します。
[49] multipart/form-data においては、
<input type=file> などでファイルを提出した際に当該ファイルのファイル名を指定するために
filename 引数が用いられます。
form-data です。[159] multipart/form-data の本体部分がファイルを表す場合、
filename 引数でファイル名を指定するべきです
>>155。
[56] MUA では、添付ファイルが存在する旨の文字やアイコンに添えて表示したり、 ツールチップで表示したりできます。
[57] Content-Disposition: attachment で用いられている場合は、
MUA で添付ファイルの保存を利用者が選択した時にファイル名の元として利用したり、
HTTP で応答に含まれていた時に保存先を選択するにあたりファイル名の元として利用したり >>55
できます。
[58] Content-Disposition: inline で用いられている場合は、
MUA で表示中の実体の保存を選択した時にファイル名の元として利用したり、
Webブラウザーで表示中のページの保存を利用者が選択した時にファイル名の元として利用したり
>>55 できます。
[53] ダウンロードのファイル名 (の既定値) の決定に
filename 引数の値が使われることがあります >>51, >>52。
[21] filename 引数を受信した MUA
が当該実体をファイルとして保存する際は、
指定されたファイル名をできるだけ実際のファイル名の基礎として用いるべきです
>>18。
[28] ただし filename 引数があるからといって受信した実装がファイルに保存しなければならないわけではありません。
利用者が特に要求しない限り、当該実体を通常のメールの処理の一部として表示したとしてもまったく問題ありません。 >>18
[61] HTTP では、 filename
引数が旧来の構文と拡張構文の両方で指定された場合、
拡張構文を採用し、旧来の構文を無視するべきです >>55。
[50] なお、 RFC 2231/RFC 5987 の拡張構文では引数に言語タグを指定できますが、 ファイル名では言語はあまり使われず、無視されるであろうと RFC 6266 は述べています >>41。
[65] MIME でも HTTP でも filename の指定はヒント
>>55 とされています。
利用者エージェントも利用者も、 filename
の指定に関わらず任意のファイル名を使うことができます。
[66] 実装によっては filename で指定されたファイル名を原則そのまま
(都度利用者に確認することなく) 保存に使うものがありますが、
セキュリティーには十分な配慮が必要です。
[67] また利用者に都度ファイル名を確認する場合で、 filename
の値は単にその既定値として示すだけであったとしても、利用者が意図せずシステムを破壊してしまったり、
ファイルを危険な位置に保存してしまったりすることがないよう、
配慮が必要でしょう。
[22] MUA は何も考えずに指定されたファイル名を使ってはいけません。 保存先のファイルシステムの規約に従っているか、 既存のファイルを上書きしてしまわないか、 セキュリティー上の問題を起こさないかを検査して、 必要なら変更するべきです >>18。
[23] MUA は filename 引数で指定された値にディレクトリーの部分があっても、
それに従うべきではありません。ディレクトリーを除いた狭義のファイル名の部分のみを使うべきです
>>18。
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.lnk や
example.txt.vbs のようにファイル名を偽装
する方法が Outlook Express を対象によく行われています。
[81] 表示上、あるいはファイル名として問題となる文字、 例えば制御文字や末尾の空白は、削除するべきです >>55。
[39] プログラミング言語やライブラリー等によっては、 パイプ >>37 やリダイレクトなどに使用する特殊な文字をファイル名と共に使用することができ、 利用者が意図しないコマンドが実行されてしまったり、 ファイルが書き換えられてしまったりする危険性があります。
[90] その他ファイルシステムやシェルで問題となる文字や文字列として、
.、..、~、|、
デバイス名などがあります。受信者はこれらを無視したり、
置き換えたりするべきです。 >>55
[156] multipart/form-data では filename
引数は指定するべきとはいえ、必須ではない >>155
とされています。
[157] ファイル名は、取得できないこともあるかもしれません >>155。 利用する OS の API などのファイルの取得方法次第で、 ファイルの内容にはアクセスできても、ファイル名にはアクセスできないかもしれません。 一般的なパソコン等とは異なるシステムでは、ファイル名がなかったり一般的なファイルシステムとは異なる形でファイルを扱っているかもしれません。
[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] 多くのシステムには /dev や CON
のような特殊な名前のファイルがあります。安全性に関わりますから特に注意が必要です。
ファイル・システム的に特殊でなくても、
システムにおいて重要なファイルにも注意が必要です (>>10)。
[46]
現代的なファイル・システムはディレクトリによって階層化された名前空間でファイルを管理していますが、
その経路でディレクトリ名やファイル名の区切りとして使われる文字は様々です。
Un|x では /、伝統的な Mac OS では :、
Windows では \ が使われます。
他のシステムでは他の文字が使われているかもしれません。
シフトJIS のように、バイト列で \ が使われる文字コードが使われるシステムもあります。
[47]
階層的なファイル・システムでは .
(同じ階層) や .. (一つ上の階層) や
... (二つ上の階層) のように相対的な参照のための仕組みを用意していることがあります。
安全面から特定の階層へのファイルの保存のみを認めたつもりでも、
ファイル名にこのような特殊な文字列が含まれているとそのチェックをすり抜けられるかもしれません。
利用者エージェントはそのシステムの仕組みに応じて厳しいチェックが必要です。
[48] なお、システムによっては、ファイル・システムで本来認められない文字やオクテットを使った名前のファイルが作れてしまい、
そのシステム標準の方法では削除できないということがあり得ます。
安全対策を行った上で filename や
Subject などからファイル名を決定するとしても、
使用する文字・オクテットが本当に安全なものかどうかをよく確かめなければなりません。
[131] 仕様上、各実体のファイル名の関係は明記されていません。
multipart/* に含まれる実体本体で相互にファイル名を使って参照できるとはされていませんし、
ファイル名が重複していていけないとの規定もありません。
ディレクトリ名のように見える文字列が含まれていたとしても、
それらのファイルが同じディレクトリに保存されるとも、
別のディレクトリに保存されるとも何ら保証されません。
[132] RFC 2388 は multipart/form-data
によるファイルの提出に関して、ファイル名で相互参照されている可能性があるため、
ファイル名が保持されると有用だと述べています (multipart/form-data (>>45)参照)。
ただ具体的な要件や処理方法を定めているわけではありません。
[186]
ファイルアップロードを受け付けるHTTPサーバー (アプリケーションサーバー)
の中には、
filename=""
引数によって
(空文字列ではない)
ファイル名が指定されていない場合に、
ファイルが存在すると認識できずにエラーを返すものがあります。
[187]
ファイルアップロードに対応したクライアントのライブラリーは、
Web互換性のため、アプリケーションからファイル名が与えられなかったときでも
file.dat
のような適当なファイル名を補った方が良いのかもしれません。
'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 引数はファイル名と扱われるようになってきました。
そこで IETF は Content-Disposition: 欄を用意して
ODE(MIME)[filename]] 引数を設け、 application/octet-stream
の name 引数は廃止しました。
conversions
引数は「削除」と説明しているのに対し、 name
は「非推奨」と区別して記述されていますが、その意図は不明です。[153] 現在では Content-Type: 欄の name
引数だけを見てファイル名を決める利用者エージェントはもはや存在しないと推測されますが、
依然として多くの利用者エージェントがメッセージ作成時に
Content-Disposition: 欄の filename 引数と
(媒体型に関わらず) Content-Type: 欄の name
引数の両方にファイル名を入れています。
| 媒体型 | 状態 | 出典 |
application/octet-stream | 廃止 (IETF 提案標準) | RFC 1341 |
application/pkcs7-mime | IETF 標準化過程 | 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 で使われるときに、例えばシフトJIS で filename=表.xls とあったら、 保存時の既定名が 表.xls ではなくて URI の末尾の部分と同じになるという話。
0x5C を quote として落とすだけなら分かる
(仕様上正しい動作) だけど、全く無視してしまうのはおかしい。(けど、
表の片割れが残って、
不正なファイル名→無視と判断しているのならまともかもしれない。)
なんにせよ、この文書での M$ の立場は本来
らしい。
M$ にしては珍しくまともなことを言ってるね。US-ASCII しか使えないけど、 DBCS もおまけで対応してるよん☆
[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
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
[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 引数の他に HTML
の download 属性の値も使われます。
[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
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.
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.
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
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 時のチェックに使っているようで、
ファイル名が空文字列だとファイル未指定のエラーにします。
multipart/form-dataは MIME とも HTTP とも一部異なる構文や処理方法が採られていますので、本項では区別しています。