579.txt

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

* 仕様書

[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>'''
]REFS]

* 意味

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

* 構文

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

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

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

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

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

** 空文字列

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

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

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

** 非 ASCII 文字の値

[11] [CODE(MIME)[fuilename]] 引数のもう一つの問題は、
非 [[ASCII]] 文字を使った名前への対応です。
(特に最近では [[Windows]] だけでなく [[Un*x]]
系でも漢字のファイル名を使ったりする人が増えてきました。)

規格としては既に [[RFC 2231]] の方法 (>>3)
が決まっていますが、この標準化が遅れたことと、
やや複雑であることから、好き勝手な方法で実装した
[[MUA]] が幾つもあって、その MUA との互換性のため
(あるいは実装者の無知のため) そうした方法での実装が後をたちません。

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

[12] ''[CODE(ABNF)[[[encoded-word]]]] を使う方法''。
[CODE(ABNF)[[[parameter]]]] の [CODE(ABNF)[[[value]]]]
([CODE(ABNF)[[[[[quoted-string]]]]) の中に ]]
[CODE(ABNF)[encoded-word]] を使う方法です。
[SAMP(file)[filename="=?iso-2022-jp?b?...hogehoge...?="]]
のようにします。

この方法は'''間違い'''です ([[RFC 2047]] にも
[CODE(ABNF)[quoted-string]] 中で [CODE(ABNF)[encoded-word]]
が使えないことは明記されています)。

[[M$OE]] をはじめとする数多くの UA がこの方法で実装していますので、
UA はこの方式も解読出来ると良いかもしれませんが、
この方法で送っては'''いけません'''。

[13] ''生8ビット符号を使う方法''。
生の日本語 [[EUC]] や[[シフトJIS]]をそのまま使って 
[SAMP(MIME)[filename="ファイル名"]]
とする方法です。現在でもたまに使われますが、
この方法は[[相互通信性]]に欠けるので、使っては'''いけません'''。
(電子メイルの世界はいまだに8ビット安全ではありません。)

[20] しかし実際には、特に [[HTTP]] で使用される場合において、 
>>13 のようなことがありますね。大抵は、[[本体]]の 
[CODE(MIME)[[[charset]]]] と同じなんでしょうが... 
(その場合でも [CODE(HTTP)[[[Content-Type]]:]] 欄に 
[[[CODE(MIME)[charset]]パラメーター]]が無かったりするので、
油断は出来ません。結局は自動判別せざるを得ません。)

もっとも、 HTTP では RFC 2231 の方法も [CODE(ABNF)[encoded-word]]
もほとんど使われていないので、仕方が無いのは確かです。
また、 SIP は [[UTF-8]] を採用しているので、
ここで UTF-8 を使うことはまったく合法
(そして唯一の方法) です。

(なお、 [[HTTP/1.1]] においては頭部の8ビット文字列は
[CODE(charset)[[[ISO-8859-1]]]] として解釈されます。
[[HTTP/1.0]] では実装依存の8ビット列です。)

[40] [[URI符号化]]が有効な UA もあるらしい。 (なにかというと WinIE ね。) 追試きぼんぬ。

[32] [CODE(MIME)@en[[[multipart/form-data]]]] では、 [CODE(MIME)@en[[[filename]]]]
[[引数]]は常に[[引用文字列]]で、[[非ASCII文字]]も含めて[[提出]]時の
[[charset]] で(のみ)[[符号化]]されます。

;; [CODE(MIME)@en[[[multipart/form-data]]]] を参照。

* 文脈

[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]]]] です。

* 処理モデル

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

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

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

* セキュリティー

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

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

[10] [CODE(MIME)[filename]] 
パラメーターを巡っては幾つかの問題があります。
そのうちの1つは値の安全性についてです。

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

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

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

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

[[#comment]]


** 相互運用性


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

[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]]]] などから[[ファイル名]]を決定するとしても、
使用する[[文字]]・[[オクテット]]が本当に安全なものかどうかをよく確かめなければなりません。

* 歴史

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

現在では [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]]
で両方の引数を付けることを推奨しています。

** [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/>

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

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

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