579.txt

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

[130] 本[[引数]]は [[MIME]]、[[HTTP]]、[CODE(MIME)@en[[[multipart/form-data]]]]
で使われています。

;; [CODE(MIME)@en[[[multipart/form-data]]]] は [[MIME]] とも [[HTTP]]
とも一部異なる構文や処理方法が採られていますので、本項では区別しています。

* 仕様書

[REFS[
- [16] [CITE@en[RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field]] ([TIME[2014-09-07 04:20:15 +09:00]] 版) <http://tools.ietf.org/html/rfc2183#section-2>
-- [18] '''[CITE@en[RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field]] ([TIME[2014-09-07 04:20:15 +09:00]] 版) <http://tools.ietf.org/html/rfc2183#section-2.3>'''
-- [37] [CITE@en[RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field]] ([TIME[2014-09-07 04:20:15 +09:00]] 版) <http://tools.ietf.org/html/rfc2183#section-5>
- [133] [CITE@en[RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2)]] ([TIME[2014-09-07 15:46:36 +09:00]] 版) <http://tools.ietf.org/html/rfc3801#section-4.3.2>
- [41] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) <http://tools.ietf.org/html/rfc6266#section-4.1>
- [55] '''[CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) <http://tools.ietf.org/html/rfc6266#section-4.3>'''
- [51] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2014-10-30 18:30:38 +09:00]] 版) <https://html.spec.whatwg.org/#downloading-resources:http-content-disposition-3>
- [52] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2014-10-30 18:30:38 +09:00]] 版) <https://html.spec.whatwg.org/#downloading-resources:http-content-disposition-4>
- [138] [CITE@en[RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer]] ([TIME[2014-09-13 18:22:39 +09:00]] 版) <https://tools.ietf.org/html/rfc5547#section-6>
- [155] [CITE@en[RFC 7578 - Returning Values from Forms: multipart/form-data]] ([TIME[2015-07-19 23:17:07 +09:00]] 版) <https://tools.ietf.org/html/rfc7578#section-4.2>
- [173] [CITE@en[RFC 7578 - Returning Values from Forms: multipart/form-data]] ([TIME[2015-07-19 23:17:07 +09:00]] 版) <https://tools.ietf.org/html/rfc7578#section-5.1.2>
]REFS]

* 意味

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

* 構文

[17] 構文上は [CODE(MIME)@en[[[filename]]]] [[引数]]の値は無制約となっています
[SRC[>>16, >>55]]。

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

;; >>122 参照。

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

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

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

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

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

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

;; >>110 参照。

;; 拡張構文を使えば曖昧なく指定できます。

** 空文字列

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

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

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

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

* 引数値における非 ASCII 文字

[11] [[ファイル名]]にはしばしば[[非ASCII文字]]が使われます。
そのため [CODE(MIME)@en[[[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]] の英数字だけに限定する方が得策です。
しかし、一昔前ならともかく、
多言語・多文字が当たり前の現在ではこのような仕様は批判されても当然でしょう。

[FIG(table)[
:proto:[[プロトコル]]
:qs:[[引用文字列]]
:pe:[[パーセント符号化]]
:ew:[[符号化語]]
:2231:拡張構文

:proto:[[電子メール]]/[[MIME]]
:2231:○
:qs:[[US-ASCII]] 限定
:pe:×
:ew:○ (仕様上は禁止)

:proto:[[HTTP]]
:2231:略式
:qs:[CODE(MIME)@en[[[charset]]]] 依存? (仕様上は [[US-ASCII]] のみ)
:pe:× (過去にあった)
:ew:× (過去にあった)

:proto:[CODE(MIME)@en[[[multipart/form-data]]]]
:2231:×
:qs:容認 ([CODE(MIME)@en[[[charset]]]] 依存)
:pe:○
:ew:×

:proto:[[SIP]]
:qs:[[UTF-8]]
:pe:×
:ew:×
:2231:×

]FIG]

** 符号化語を使う方法

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

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

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

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

;; [103] [[RFC 2047]] は [CODE(MIME)@en[[[Content-Disposition:]]]]
の[[引数]]値での[[符号化語]]を明示的に禁止しています [SRC[>>100]] が、
その前の版である [[RFC 1522]] は言及していません (そもそも 
[CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]がまだありませんでした)。
元々 [[RFC 822]] [[ヘッダー]]のどこで[[符号化語]]を使うことができ、
どこで使うことができないかを定める趣旨の規定だったのですから、 [[MIME]]
で新たに追加された[[ヘッダー]]において[[符号化語]]をどう利用するかは本来それに束縛される必要はなかったはずです。

;; [104] [[HTTP]] では、 [[RFC 2616]] 世代までは一部の[[ヘッダー]]の[[引用文字列]]内で[[符号化語]]を使うことを認めていました
([[RFC 723x]] 世代でこの規定は削除されました)。 [[RFC 2388]]
も[[符号化語]]を認めていました。[[符号化語]]を使う方法はむしろそちらと整合性があったとも言えます。

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

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

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

[108] [[電子メール]]/[[MIME]] では、互換性のためにこの方法を実装する必要があります。
[TIME[2014-11-02T14:11:27.00Z]]

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

[162] [CODE(MIME)@en[[[multipart/form-data]]]] や [[SIP]] 
ではこの方法が用いられたことは歴史的にもないと思われます。

[REFS[
- [100] [CITE@en[RFC 2047 - MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text]] ([TIME[2014-09-22 05:10:14 +09:00]] 版) <http://tools.ietf.org/html/rfc2047#section-5>
- [99] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) <http://tools.ietf.org/html/rfc6266#appendix-C.1>
]REFS]

;; [124] [[ファイル名]]を指定する古い方法である [CODE(MIME)@en[[[Content-Type:]]]]
[[ヘッダー]]の [CODE(MIME)@en[[[name]]]] [[引数]]でも、同じくこの方法が使われることがよくあります。

;; [125] [[Gmail]] も >>124 のように動作します。 [TIME[2014-11-02T15:00:04.100Z]]

** 符号化しない方法

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

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

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

;; [117] 仕様上は [[RFC 2068]] や [[RFC 2616]] 時代は[[引用文字列]]の値を
[CODE(charset)@en[[[ISO-8859-1]]]] と解釈することになっていましたが 
([[RFC 723x]] はこれを撤回したものの、どう解釈するべきか明確にしていません。)、
実際上は [[payload body]] と同じと解釈するのが適当と思われます。

;; [121] [[RFC 6266]] は [[UTF-8]] と解釈する実装があることを根拠に[[非ASCII文字]]があるとき
([[ISO-8859-1]] で表現できるとしても) [[引用文字列]]を使わないことを薦めています [SRC[>>120]]
が、 [[RFC 723x]] では[[引用文字列]]における[[非ASCII文字]]を禁止していますから、
現行仕様に従うなら[[非ASCII文字]]を含むなら必ず拡張構文を使う必要があります。

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

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

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

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

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

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

[REFS[
- [115] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) <http://tools.ietf.org/html/rfc6266#appendix-C.3>
- [120] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) <http://tools.ietf.org/html/rfc6266#appendix-D>
]REFS]

** パーセント符号化

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

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

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

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

[118] [[HTTP]] でももはやこの方法に対応する必要は無いのかもしれませんが、はっきりしません。
[TIME[2014-11-02T14:49:15.700Z]]

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

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

[REFS[
- [111] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) <http://tools.ietf.org/html/rfc6266#appendix-C.2>
]REFS]

** RFC 2231 の拡張構文

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

;; [[引数 (MIME)]]、 >>11 を参照。

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

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

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

[127] [[Webブラウザー]]はこの方法で [[HTTP]] に指定された名前を理解できるようになっています。
[TIME[2014-11-02T15:01:13.700Z]]

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

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

[160] [CODE(MIME)@en[[[multipart/form-data]]]] の[[実体本体]]では、拡張構文を使っては[['''なりません''']]
[SRC[>>155]]。

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

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

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

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

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

* 文脈

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

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

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

;; この場合の [[disposition型]]は [CODE(MIME)@en[[[form-data]]]] です。

[159] [CODE(MIME)@en[[[multipart/form-data]]]] の[[本体部分]]が[[ファイル]]を表す場合、
[CODE(MIME)@en[[[filename]]]] [[引数]]で[[ファイル名]]を指定する[['''べきです''']]
[SRC[>>155]]。

;; >>156 も参照。

[134] [[VPIM]] では、[[ファイル名]]情報が利用可能なら、 [CODE(MIME)@en[[[filename]]]]
[[引数]]を指定する[['''べきです''']] [SRC[>>133]]。

;; [135] なお [[VPIM]] では [CODE(MIME)@en[[[Content-Disposition: inline]]]]
の指定が[['''必須''']]となっています。

* 処理モデル

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

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

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

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

;; [[ダウンロード]]も参照。

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

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

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

;; [[引数 (HTTP)]]も参照。

;; [62] [[MIME]] では特に規定がありません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* ファイル名の互換性問題

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

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

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

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

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

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

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

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

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

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

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

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

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

* SDP [CODE['file-selector']] 属性 [CODE['name']] 選択子

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

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

* 歴史

** [CODE(MIME)@en[Content-Type:]] ヘッダー [CODE(MIME)@en[name]] 引数

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

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

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

[45] '''ファイル名を表す [CODE(MIME)[name]] 引数を持つ媒体型''':
,媒体型	,状態	,出典
,[CODE(MIME)[[[application/octet-stream]]]]	,廃止 (IETF 提案標準)	,[[RFC 1341]]
,[CODE(MIME)[[[application/pkcs7-mime]]]]	,IETF 標準化過程	,[[RFC 3851]] 3.2.1

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

[REFS[
- [151] [CITE@en[RFC 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies]] ([TIME[2015-05-03 14:29:03 +09:00]] 版) <http://tools.ietf.org/html/rfc1341#page-46>
- [152] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-4.5.1>
]REFS]

** [CODE(MIME)@en[Content-Disposition:]] ヘッダー [CODE(MIME)@en[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]] で 
[SAMP(HTTP)[filename=表.xls]] とあったら、
保存時の既定名が [SAMP(file)[表.xls]] ではなくて URI 
の末尾の部分と同じになるという話。 

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

なんにせよ、この文書での M$ の立場は[Q[本来 [CODE(charset)[[[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
が [SAMP(URI)[http://foo.example/path/to/resource]]
であるなら、 [CODE(MIME)[filename]] 引数は [SAMP(file)[foo.example/path/to/resource]]
になりました。

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

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

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

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

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

[64]
[CITE[Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding]] ([TIME[2008-09-21 02:53:50 +09:00]] 版) <http://greenbytes.de/tech/tc2231/>

[69] [CITE[Test Cases for HTTP Content-Disposition header field and the Encodings defined in RFC 2047/6266 and RFC 2231/5987]]
( ([TIME[2011-08-03 23:43:34 +09:00]] 版))
<http://greenbytes.de/tech/tc2231/>

[72] [CITE[Content-Disposition FireFoxとIEの挙動の違い - 開発者の談話室]]
( ([TIME[2010-07-29 15:43:38 +09:00]] 版))
<http://www.agile-tech.com/blogs/dev/2007/12/contentdisposition.html>

[73] [CITE@ja[日本語ファイル名]]
( ([TIME[2012-03-11 15:30:08 +09:00]] 版))
<http://oku.edu.mie-u.ac.jp/~okumura/php/filename.php>

[74] [CITE@en[Japanese: 日本語ファイル名をIEでダウンロードするときの文字化け対策]]
( ([TIME[2012-03-11 15:31:40 +09:00]] 版))
<http://moodle.org/mod/forum/discuss.php?d=72567>

[75] [CITE[日本語ファイル名の悩み (サイボウズ Office 開発ブログ)]]
( ([TIME[2008-09-10 10:02:13 +09:00]] 版))
<http://cydn.cybozu.co.jp/office/2008/07/post_1.html>

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

[77] [CITE[Example file]]
( ([TIME[2012-03-11 07:14:08 +09:00]] 版))
<http://suika.fam.cx/~wakaba/test/web/http/content-disposition/non-us-ascii-filename.cgi>

[78] 
[PRE(HTTP example code)[
Content-Disposition: attachment; filename=%E4%B8%80%E4%B8%81; filename*=utf-8[SPAN[']]'%E4%B8%80%E4%B8%81
]PRE]
... のように [[UTF-8]] で[[符号化]]して[[パーセント符号化]]したのを直接指定するのと、
[[RFC 6265]] に従って [[UTF-8]] で[[符号化]]したのを、両方指定すると、 [[IE]]
を含む全 [[Webブラウザー]]でいい感じに[[復号]]してくれます。 [TIME[2012-03-11T08:25:10.600Z]]

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

[84] [CITE@ja[ファイルをダウンロードする ASP.NET ページで日本語ファイル名が文字化けする]]
( ([TIME[2014-10-28 06:27:37 +09:00]] 版))
<http://support.microsoft.com/kb/436616/ja>

[85] [CITE[ダウンロードファイル名の文字化け]]
( ([[WebSurfer]] 著, [TIME[2014-10-28 06:29:35 +09:00]] 版))
<http://surferonwww.info/BlogEngine/post/2011/03/20/Downloading-file-with-Japanese-file-name.aspx>

[136] [CITE@en[draft-harding-ediint-filename-preservation-03 - Filename Preservation for EDIINT]] ([TIME[2014-10-17 00:24:39 +09:00]] 版) <http://tools.ietf.org/html/draft-harding-ediint-filename-preservation-03>

** RFC 6266

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

[70] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]]
( ([TIME[2012-03-02 10:21:42 +09:00]] 版))
<http://tools.ietf.org/html/rfc6266>

[86] [CITE@en[Bug 84977 – Add Support for RFC 5987 (Non-ASCII HTTP Header Keys/Values) for filenames]]
( ([TIME[2014-10-28 13:51:41 +09:00]] 版))
<https://bugs.webkit.org/show_bug.cgi?id=84977>

[87] [CITE@en[601933 – remove RFC 2047 encoding support for HTTP header field parameters]]
( ([TIME[2014-10-28 13:55:46 +09:00]] 版))
<https://bugzilla.mozilla.org/show_bug.cgi?id=601933>

[88] [CITE@en[610054 – Clean up RFC 2231 MIME param handling, and add support for RFC 5987 subset]]
( ([TIME[2014-10-28 13:59:09 +09:00]] 版))
<https://bugzilla.mozilla.org/show_bug.cgi?id=610054>

[89] [CITE@en[Downloads and International Filenames - IEInternals - Site Home - MSDN Blogs]]
( ([TIME[2014-10-28 14:00:23 +09:00]] 版))
<http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx>

* 関連

[54] [[ダウンロード]]の際の[[ファイル名]]の[[既定値]]の決定には、
[CODE(MIME)@en[[[filename]]]] [[引数]]の他に [[HTML]]
の [CODE(HTMLa)@en[[[download]]]] [[属性]]の値も使われます。

[137] [CITE@en[RFC 5273 - Certificate Management over CMS (CMC): Transport Protocols]]
( ([TIME[2014-08-17 10:28:09 +09:00]] 版))
<http://tools.ietf.org/html/rfc5273#section-3>

[141] [CITE@en[RFC 6047 - iCalendar Message-Based Interoperability Protocol (iMIP)]]
( ([TIME[2014-10-27 00:35:26 +09:00]] 版))
<https://tools.ietf.org/html/rfc6047#section-2.6>

[FIG(quote)[
[FIGCAPTION[
[142] [CITE[HTTP::Response - search.cpan.org]]
([TIME[2015-03-15 12:30:47 +09:00]] 版)
<http://search.cpan.org/dist/HTTP-Message/lib/HTTP/Response.pm#%24r-%3Efilename>
]FIGCAPTION]

> 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.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[143] [CITE[HTTP::Response - search.cpan.org]]
([TIME[2015-03-15 12:30:47 +09:00]] 版)
<http://search.cpan.org/dist/HTTP-Message/lib/HTTP/Response.pm#%24r-%3Efilename>
]FIGCAPTION]

> 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.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[144] [CITE@en-US[Site Compatibility for Firefox 22 - Mozilla | MDN]]
([TIME[2014-05-03 01:58:20 +09:00]] 版)
<https://developer.mozilla.org/en-US/Firefox/Releases/22/Site_compatibility#RFC_2047_encoding_support_for_HTTP_header_field_parameters_has_been_removed>
]FIGCAPTION]

> 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.

]FIG]


[145] [CITE@en[601933 – remove RFC 2047 encoding support for HTTP header field parameters]]
([TIME[2015-05-03 19:48:09 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=601933>

[146] [CITE@en[875615 – Revert to decoding RFC 2047-encoding until we have telemetry on usage]]
([TIME[2015-05-03 19:49:18 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=875615>

[147] [CITE[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]]
([TIME[2015-05-03 19:51:14 +09:00]] 版)
<https://code.google.com/p/chromium/issues/detail?id=41308>

[148] [CITE@en[651185 – double quotes aren't a legal delimiter for 2231/5987 encoding]]
([TIME[2015-05-03 19:52:26 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=651185>

[149] [CITE@en[511521 – (CVE-2009-3376) downloading file with RTL override (RLO) presents conflicting filenames]]
([TIME[2015-05-07 20:29:20 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=511521>

[150] [CITE[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]]
([TIME[2015-05-10 22:53:46 +09:00]] 版)
<https://code.google.com/p/chromium/issues/detail?id=72935>

[174] [CITE@en[Fix #25: bring back FormData's append()'s filename argument · whatwg/xhr@b0ec31e]]
([TIME[2015-12-16 12:29:43 +09:00]] 版)
<https://github.com/whatwg/xhr/commit/b0ec31ea3f70b1c465ae54d6d5dcd2acde833ea9>

[175] [CITE@en[Fix #48: align with HTML's form submission algorithm · whatwg/xhr@7b1941f]]
([TIME[2016-01-22 23:25:43 +09:00]] 版)
<https://github.com/whatwg/xhr/commit/7b1941fbd5347433734a491c36ef8ea6485e7dfb>

[FIG(quote)[
[FIGCAPTION[
[176] [CITE@ja[S3のContent-Dispositionのブラウザ対応について調査してみた - Innovator Japan Engineers’ Blog]]
([TIME[2016-10-13 18:34:25 +09:00]])
<http://tech.innovator.jp.net/entry/s3-content-disposition>
]FIGCAPTION]

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

]FIG]