Re: Re: ファイル名のマルチバイト文字対応

個人的にはサーバ上にはハッシュ等のユニークな名前で保存し、ダウンロード時に設定された元のファイル名でダウンロードする様にした方がよいかな？と考えています。

元のファイル名でダウンロードさせることについては、現に上で提示したものもそのような仕様にしてあります。
ただ、ハッシュを適用した名前でサーバー上に保存すると、既存システムに適用したときにファイルが呼び出せなくなると思い、現状では「Punycodeのエンコード結果を利用」という形にしています。

実は日本語のURLについてもずいぶん前に「urlencodeではなく、Punycodeではどうか？」という議論がありました。
Punycodeは%が入らなくて短く出来る点は良いのですが、エンコード、デコードにライブラリが必要でPHP標準関数では対応出来ない事と、そのために若干動作が重くなる事からURLencodeにしました。（URLはページを表示する度に何回も処理される部分なので...）

確かに重さの点は重要ですね。現段階での仕様としては、データベースにはマルチバイト入りのファイル名をそのまま格納しており、サーバー上のファイルを呼び出すときにその都度変換を施しています(よってデコード処理を一切使っていません)。データベースの構造を変えなくていいので楽ですが、負荷の面は考える必要がありますね。
ただ、日本語URLと違い、ファイル名の場合はurlencodeだとファイルシステムの限界(255バイトなど)を簡単に超えそうで怖いのです(日本語1文字に対して、UTF-8では典型的には3バイトで、1バイトが %81 のように変換されるので、エンコード結果は都合9バイトになりますね。30文字弱で限界を超えます)。もちろんサーバー上のファイル名としてハッシュ関数の結果を使うならこの限りではありませんが。

今回の5.4.1.1でも日本語ファイル名の対応は議題にあがりましたが、時間切れで次期バージョンに保留となってしまいました。
なので、もし可能であればconcrete5版のアドオンなりパッチなりを作成して頂き、次期バージョンのリリースまでに検証出来れば嬉しいです。

そうですね、エンコード方法の選択やその長短も含めて議論の余地があるでしょうから、次期バージョンのリリースまでにゆっくりと、という感じになるでしょうか。