* filename 引数 (MIME/HTTP/SIP Content-Disposition: 欄) [9] その名のとおり、ファイルの名前を示すパラメーターです。 詳しくは [[RFC 2183]] を参照して下さい。 [49] あ ([[名無しさん]] [WEAK[2005-04-13 10:23:16 +00:00]]) [[#comment]] ** 非 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 ね。) 追試きぼんぬ。 [[#comment]] ** 安全性 [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]]]] などから[[ファイル名]]を決定するとしても、 使用する[[文字]]・[[オクテット]]が本当に安全なものかどうかをよく確かめなければなりません。 [[#comment]] *** メモ [[#comment]] ** 実装 [30] ''Content-Disposition'' : [[Windows]] の実装の状況 (1999)。 [36] ''414647 - [IE5] Content-Disposition: の DBCS ファイル名(5C)が認識できない'' ([[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'' : 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 では狭義ファイル名。 [[#comment]] ** 他との関係 [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]] で両方の引数を付けることを推奨しています。 [[#comment]] ** メモ [[#comment]] * メモ