Webkit 系ブラウザに日本語ファイル名でダウンロードさせると文字化け - 対策したはずなのに!?

ブラウザに日本語ファイル名でダウンロードさせる

ASP.NET による Web アプリケーション開発での話。

ASP.NET Web アプリ側からブラウザ側への応答返信時、Content-Disposition 応答ヘッダに、"attachment; filename=～" という値を指定すると、ブラウザ側ではファイルのダウンロード処理が行われる。
ダウンロード処理時のファイル名は、この応答ヘッダの filename=～ に指定する。

たとえば次のようなコードがあったとすると、

Response.AppendHeader(

  "Content-Disposition",

  "attachment; filename=something.zip");

"something.zip" というファイル名で応答が保存されるのだ。

このときの "ファイル名" に日本語のようなマルチバイト文字列を指定しようとすると、実は結構やっかいだ。

とりあえず今日現在の状況をおさらいしてみると、マルチバイト文字列をダウンロードファイル名に指定する方法は、ブラウザに応じて以下のとおりのはずである。

• IE8 以前は Unicode 文字列を UTF-8 エンコードして生成したバイト列を URL エンコードした 7bit ASCII 文字列で指定。
  
  
• IE9 以降、および、いつ頃からかの Firefox では、IE8 以前と同じ手順で生成した文字列を使うが、ただし、"filename=～" に続けるのではなく、"filename*=utf-8''～" という、一瞬誤記ではないかと疑いたくなるような特殊な記述で指定（RFC 6266）。
  
  
• Safari や Google Chrome など Webkit 系では Unicode 文字列を UTF-8 エンコードしたバイト列をそのままで指定。

すみません、Opera は不勉強でわからないです...
(ただ、これは想像だけど、Opera は最新仕様に早くから対応するイメージがあるので、たぶん、RFC 6266 のとおりでOKじゃないかな?)

それでもWebkit 系ブラウザでファイル名文字化け

さてところで、上記のとおりのダウンロードファイル名指定を実装したにもかかわらず、動作検証中に、Webkit 系ブラウザでのみ、日本語ファイル名によるダウンロードでファイル名が文字化けする、という怪現象が発覚した。

それも本番環境をかなり正確に模擬した検証環境でのみ発生するのだ。

開発環境ではぜんぜん再現しない。

IE9 の開発者ツールでネットワークのキャプチャで観察しても、たしかに、検証環境から返される応答ヘッダはしっかり文字化けしていた。
Web アプリケーションのバイナリは、いずれの環境でも慎重に正確に一致させてある。
よって、アプリケーション側のコードになにか原因があるとは考えにくい。

となると、原因があるのは、アプリケーションを取り囲む環境構成にあるのではないか。

検証環境とそれ以外の環境の差異はなにか。

それはリバースプロキシの存在にあった。

IIS7 + ARR

検証環境では、Web サーバーが直接クライアントにさらされているのではなく、IIS7.5 + Application Request Routing 拡張機能 (以下 ARR) によるリバースプロキシを介して接続する構成になっていたのだ。

Application Request Routing - IIS TechCenter
http://technet.microsoft.com/ja-jp/iis/ee839425

すなわち、IIS7.5 + ARR が Web サーバーからの応答を中継するときに、何か起きているのではないだろうか。

ということで試しに、IP 経路を変更したりして、リバースプロキシを迂回して直接 Web サーバーと通信できるように構成し、改めて Safari for Windows でダウンロードしてみた。
すると、さすがに期待どおり、正しい日本語ファイル名でダウンロードされるようになった。

ということで、ほぼ間違いなく犯人は ARR である確信を得た。

しかし原因はそうだとしても、どうすればこの現象を回避できるのだろうか。

ARR の設定を IIS マネージャを通してあれこれ探索したりいじってみたりした。
しかし結局、応答ヘッダの中継とその文字コードに関係しそうな設定項目をつきとめることができなかった。

そこでいったん手を置いて休憩し、ゆっくり考えてみた。

文字化けしている、ということは、Web サーバーが返した UTF-8 エンコードされている応答ヘッダを、ARR が正しくデコードできていないに違いない。
いったい ARR は、応答ヘッダのエンコード方式が何であるとして扱っているのだろうか。

そこでふと思い立って、ASP.NET Web アプリ側が返す応答ヘッダのエンコードを SHIFT-JIS に変えてみた。

設定は簡単。
当該 ASP.NET Web アプリの web.config 構成ファイルをエディタで開き、system.web - globalization セクションの responseHeaderEncoding 属性に "shift_jis" と書いて保存すればOK。

これで再び ARR によるリバースプロキシ経由で Safari for Windows によるアクセスを行うと、正しく日本語ファイル名でダウンロードされるようになった。

とりあえずこれにて一件落着とした、が...。

たまたま今回のアプリでは、応答ヘッダのエンコードを SHIFT-JIS にしても問題ない仕様であった。
しかし、日本語以外のファイル名や、SHIFT-JIS エンコーディングの範疇外の文字を含むファイル名を指定したい場合は、これではお手上げだ。

ARR の挙動が本当に変えられないものなのか、まだまだ要調査である。