空文字列

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

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

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

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

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

符号化語を使う方法

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

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

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

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

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

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

[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 と同じ符号化が用いられることもあると思われます。

[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 (2021-10-28T12:26:04.000Z) https://togetter.com/li/1794752

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

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

• [191] 학회/행사/기타 안내 상세보기(일상생활에서 개인정보 지키는 꿀팁!(개인정보 보호 주간 9.30.-10.4.)) | 국립국어원, 2025-05-23T11:20:55.000Z https://www.korean.go.kr/front/board/boardStandardView.do;front=02D474CEED6BC6E2426609D7FD6CA64E?board_id=7&b_seq=938&mn_id=186
  • [192] https://www.korean.go.kr/common/download.do?file_path=event&c_file_name=4bb0df72-593c-4cde-87ec-5c3e82b645f4.zip&o_file_name=%EC%9D%BC%EC%83%81%EC%83%9D%ED%99%9C%EC%97%90%EC%84%9C%20%EA%B0%9C%EC%9D%B8%EC%A0%95%EB%B3%B4%20%EC%A7%80%ED%82%A4%EB%8A%94%20%EA%BF%80%ED%8C%81(%EA%B0%9C%EC%9D%B8%EC%A0%95%EB%B3%B4%20%EB%B3%B4%ED%98%B8%EC%A3%BC%EA%B0%84%20%EC%B9%B4%EB%93%9C%20%EB%89%B4%EC%8A%A4).zip

[193] >>192

Set-Cookie: SCOUTER=z2p6t444haner5; Expires=Wed, 10-Jun-2093 14:39:10 GMT; Path=/
Access-Control-Allow-Methods: GET, POST
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers: x-requested-with
Access-Control-Allow-Origin: http://lib.korean.go.kr/usweb/union3/ksearch.asp
Access-Control-Allow-Origin: http://lib.korean.go.kr/usweb/union3/klist_result.asp
Access-Control-Allow-Origin: http://lib.korean.go.kr/usweb/union3/klist_view.asp
Set-Cookie: front=E248D9A8824E811B761DABE9BBEE5E0F; Path=/; Secure; HttpOnly
Content-Disposition: attachment; filename="일상생활에서 개인정보 지키는 꿀팁(개인정보 보호주간 카드 뉴스).zip";
Content-Length: 599262
Vary: User-Agent
Connection: close
Content-Type: application/zip;charset=utf-8

• [194] 시정소식 < 새소식 < 용인소식 < HOME : 용인시청 대표포털, 2025-05-23T11:37:27.000Z https://www.yongin.go.kr/user/bbs/BD_selectBbs.do?q_bbsCode=1001&q_bbscttSn=20240219075251883
  • [195] https://www.yongin.go.kr/component/file/ND_fileDownload.do?q_fileSn=395735&q_fileId=ac01f7a4-ddee-47dd-b505-b2e134c1f2ae

[196] >>195

Access-Control-Allow-Origin: *
Date: Fri, 23 May 2025 11:39:07 GMT
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="ã<U+0080><U+008C>ê°<U+009C>ì<U+009D><<U+0098> ì<U+008B><U+009D>ì<U+009A>© 목ì <U+0081>ì<U+009D><U+0098> ì<U+0082>¬ì<<U+009C>¡ã<U+0086><U+008D>ë<U+008F><U+0084>ì<U+0082>´ ë°<U+008F>  ì<U+009C> í<U+0<U+0086>µ ë<U+0093>± ì¢<U+0085>ì<U+008B><U+009D>ì<U+0097><U+0090> ê´<U+0080>í<U+<U+0095><U+009C> í<U+008A>¹ë³<U+0084>ë²<U+0095>ã<U+0080><U+008D> ë<U+0093>±.zip"
Content-Type: text/plain;charset=utf-8

UTF-8。なお本体は ZIP (ファイル名は EUC-KR)。

• [198] Διακηρύξεις μίσθωσης και εκμίσθωσης ακινήτων. - Διεύθυνση Διοικητικών Υπηρεσιών - Ελληνική Δημοκρατία - Περιφέρεια Αττικής, 2025-05-23T15:10:12.000Z https://opendata.attica.gov.gr/content/genikh-dieythynsh-eswterikhs-leitoyrgias/d-nsh-dioikhtikwn-yphresiwn/155-diakhrykseis?preview=263-diakhrykseis-2020-zip
  • [197] https://opendata.attica.gov.gr/content/genikh-dieythynsh-eswterikhs-leitoyrgias/d-nsh-dioikhtikwn-yphresiwn/155-diakhrykseis?fdl=YTJ4TDV2Tnh1ZzAzZG9KSkRWZXVEcVZtY2ZHZDZoS1owc2FyY0tQNUovSGFqMkhpK2xZNkxOVHBxdHFaeWNSdGVFY3JMMjEzUzNKbmRXeGhlSGQ0VEZCWVNFRTFRVDA5

[199] >>197

Content-Type: application/zip
Content-Disposition: attachment; filename="ΔΙΑΚΗΡΥΞΕΙΣ 2020.zip"
Content-Transfer-Encoding: binary

UTF-8

• [200] C121040 Dodatečné informace.zip, MŠMT ČR, QCM, s.r.o web@qcm.cz http://www.qcm.cz, 2025-05-24T03:31:03.000Z https://msmt.gov.cz/file/26589/
  • [201] https://msmt.gov.cz/file/26589_1_1/download/

[202] >>201

server: Microsoft-IIS/10.0
set-cookie: msmt_session=ivcvs68987fb5ct4mt08r9s663; expires=Sat, 24-May-2025 06
:00:27 GMT; path=/; HttpOnly
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains; preload
content-security-policy: default-src 'self' https://*.google-analytics.com; scri
pt-src 'unsafe-inline' 'unsafe-eval' 'self' https://www.termsfeed.com https://*.
google-analytics.com https://www.googletagmanager.com; style-src 'unsafe-inline'
 'self'; img-src 'self' https://*.google-analytics.com data:; frame-src 'self' h
ttps://www.youtube.com
referrer-policy: strict-origin
permissions-policy: camera=(), geolocation=(), microphone=(), payment=(), usb=()
x-powered-by: PHP/5.4.45
content-description: File Transfer
content-transfer-encoding: binary
content-disposition: attachment; filename="C121040 DodateÄ<U+008D>né informace.zip"
x-powered-by: ARR/3.0
date: Sat, 24 May 2025 03:30:27 GMT

パーセント符号化

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

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

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

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

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

[179] Chrome も Firefox も、この方法に対応しているようです。 2017-05-20T07:19:01.900Z

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

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

RFC 2231 の拡張構文

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

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

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

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

[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 引数の規定とは一貫しておらず、本当に使い分けろというのか謎でした。

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

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

[203] てやんでぇサポートPDF - てやんでぇ_江戸風文字一覧.pdf, 2024-09-19T13:00:28.000Z, 2025-05-30T03:55:01.415Z https://support.morisawafonts.com/hc/ja/article_attachments/37901537591193

Content-Disposition: inline; filename="______________.pdf"; filename*=utf-8''%E3%81%A6%E3%82%84%E3%82%93%E3%81%A6%E3%82%99%E3%81%87_%E6%B1%9F%E6%88%B8%E9%A2%A8%E6%96%87%E5%AD%97%E4%B8%80%E8%A6%A7.pdf

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 引数は廃止しました。

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

[45] ファイル名を表す 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$ の立場は本来 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 (2008-09-21 02:53:50 +09:00 版) 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 ( (2011-08-03 23:43:34 +09:00 版)) http://greenbytes.de/tech/tc2231/

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

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

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

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

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

[77] Example file ( (2012-03-11 07:14:08 +09:00 版)) 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

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

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

[85] ダウンロードファイル名の文字化け ( (WebSurfer 著, 2014-10-28 06:29:35 +09:00 版)) 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 (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 の引数拡張構文を実装していません >>55。

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

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

[87] 601933 – remove RFC 2047 encoding support for HTTP header field parameters ( (2014-10-28 13:55:46 +09:00 版)) 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 ( (2014-10-28 13:59:09 +09:00 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=610054

[89] Downloads and International Filenames - IEInternals - Site Home - MSDN Blogs ( (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