カテゴリ | |
---|---|
サマリ | 日本語ファイルをダウンロードすると文字化け |
バージョン | 1.4.2 |
投稿者 | cogen |
状態 | 着手 |
投稿日 | 2004-03-05 (FRI) 14:31:43 |
Multibyte Support:enabled Japanese support:enabled Multibyte (japanese) regex Support:enabled mbstring.detect_order:auto mbstring.encoding_translation:Off mbstring.func_overload:0 mbstring.http_input:auto mbstring.http_output:EUC-JP mbstring.internal_encoding:EUC-JP mbstring.language:Japanese mbstring.substitute_character:no value
何度か似たような質問がでているのでそれを参考にしてみたのですが,解決できないの質問させて下さい。
アップロードについては特に問題がないようで,attachにアップされているファイルを直に見てもEUC-JPでエンコードされたファイル名になっているようです。しかし,そのファイルをダウンロードする段階になると,ブラウザによってはファイル名に文字化けを起こします。文字化けは起こりますが,落としたファイル自体が壊れているなどという事はありません。
以下に私が試したそれぞれのブラウザでの状況を記します。
また,日本語名の画像のファイル,テキストでファイル等はブラウザで表示する分には問題なく表示可能です。しかし,それらを保存しようとすると同じように文字化けを起こします。
常に化けますか? 特定のファイル名のみでしょうか? attach.inc.php の中で、ダウンロード時に、mb_convert_encoding($this->file,'SJIS','auto') でコード変換しているので、このコード検出は理論的に失敗する可能性があります。'auto' を SOURCE_ENCODING にすれば良いのかな・・・。もうちょっと、調べてみます。但し、それで巧くいったとしても、Win/Mac 限定です(SJISに変換してますから)。他OSでは、巧くいくとは限りません。ファイル名は US-ASCII をお勧めします(ファイル名のエンコーディングは、文書のエンコーディング以上に問題が多くって(というか、ちゃんとした規格が無い)、いかなる場面においても、US-ASCII以外のファイル名を使った場合、異なるOSではファイル名が化ける可能性があります)。
日本語ファイルであれば常に化けます。attach.inc.phpのその部分は弄ってみたのですが、結局はうまくいきませんでした。ファイル名のエンコーディグにUS-ASCII以外を使うのは良くないのは分かっているのですが、PukiWikiを職場のイントラネット上での使用を考えており、US-ASCII以外のエンコーディグを使わないように徹底させるのが難しそうなんです。
うーん。とすると、SJISにしているのが問題なのかな? http に詳しい方、ファイル名のエンコーディングに関する規定があるのかどうか、ご存じありません? ファイル名は、Content-Disposition: ヘッダで指定ができるのですが・・・。ちょっと、検索してみたところでは、RFC2183 で、以下の様に規定されています。
disposition := "Content-Disposition" ":" disposition-type *(";" disposition-parm) disposition-type := "inline" / "attachment" / extension-token ; values are not case-sensitive disposition-parm := filename-parm / creation-date-parm / modification-date-parm / read-date-parm / size-parm / parameter (中略) Parameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in [RFC 2184].ということは、RFC2184に従って、MIMEエンコーディングすれば良いのですかねぇ? attach.inc.php の
$filename = htmlspecialchars(mb_convert_encoding($this->file,'SJIS','auto'));を
$filename = mb_encode_mimeheader($this->file);に変えるとどうですか?
$filename = mb_encode_mimeheader($this->file);
試してみました。
という結果になりました。
SJISではなくUTF-8にすればどうですかねぇ…
SJISをUTF-8に変更してみた結果。
惜しい...という結果に。
詳しくは調べていませんが、RFCをちょっと読んだところでは、RFC2184に従ってMIMEエンコーディングしろ、ということになっているようです。しかし、それに準拠していないブラウザが多いのが実状です(さすが、Mozillaは大丈夫のようですね)。最近のWindows(どのバージョンからかは知りませんが)は、内部的にはUTF-8でファイル名をエンコーディングしています。以前は、SJISでした。SJISで送るとIEが大丈夫なのは、古いシステムとの互換性の為に、IEがSJIS->UTF-8変換をしている為と思われます。UTF-8だとMozilla, Operaが大丈夫なのは、なにも変換せずにディスクに書き込むからだと思います。MIMEエンコーディングするとMozillaが大丈夫なのは、ちゃんとRFCに準拠しているからだと思います。このように、ブラウザの対応状況がまちまちだから、「ファイル名はUS-ASCIIで」と言われる訳です。現状の、PukiWikiは、多数派(Windows+IE)に合わせてあるということですね。と言う訳で、ブラウザの対応状況がまちまちな現状では、全てのブラウザで文字化けしないようにするのは無理なのではないでしょうか。「ファイル名をUS-ASCII」で統一するか、「化けない送信方法&ブラウザの組み合わせ」で統一するか、のいずれかではないでしょうか。根本的な対策としては、ブラウザのベンダーに、「RFCに準拠するように要望を言う」くらいでしょうか。但し、RFCを熟読した訳ではないので、間違っているかもしれません。どなたか、正確な情報をご存じの方がいらっしゃいましたら、教えてください。
いろいろ調べてもらってありがとうございます。
やはり全てのブラウザに対応するのは難しいようですね。
自分がIEを使用していないのでどうにかならないかと思ったわけですが,今回は職場のイントラネットで使用するのが目的なので実際IEで文字化けさえしなければ問題なさそうです。
職場でIE以外のブラウザを使用しているのは自分だけのような感じですし。
HTTP_USER_AGENTを見て、送出方法を変えるという方法があることはあるのですが・・・、ブラウザの不始末をPukiWikiが尻拭いしてやらないといけないのか? って所で、積極的には対応する気になれない訳です。どうしても、なんとかしたいっていうことであれば、filenameをエンコーディングしているところで、HTTP_USER_AGENTを調べて場合分けし、各エージェントに会った形でエンコーディングしてやってください。
このコメントを読む前に、IEを使っていない自分の為だけHTTP_USER_AGENTで送出方法を変えるように変更してました...
とりあえずはこれで逃げておきます。