日本語文字化け対応フォーラム

うわーっ、大変ですね。私には到底出来そうもない仕事です。ところでこれらの問題に関係があるのかどうか、あるとしても問題の解決に至るのかが判然としないのですが、この1週間頭を悩ましていたことがあります。それは、Windows版のPHP5の日本語処理の仕方に深刻なBugがあるのではないか、という疑いです。（まぁ、仮にBugがあったとしても特にMoodleには関係しないような気もするのですが．．．）とりあえず疑問だけをぶつけておきます（すみません・・・）

疑問点：PHPの組み込み関数であるrawurlencodeの処理が異常ではないか？実際Shift_JISコードの「実践工業数学参考文献.doc」というファイル名にrawurlencodeをかけると「%8E%C0%91H%8DH%8B%C6%90%94%8Aw%8EQ%8Dl%95%B6%8C%A3.doc」という文字列に変換されます。この文字列はちょっと変です。%記号の直後に3文字となっている箇所が4か所程度あります。しかもHやQ、小文字のwやlという文字は、16進数の表現としてはとても異常です。他の日本語文字コード表から想像すれば、この文字列は正しくは「%E5%AE%9F%E8%B7%B5%E5%B7%A5%E6%A5%AD%E6%95%B0%E5%AD%A6%E5%8F%82%E8%80%83%E6%96%87%E7%8C%AE.doc」となっていなければならないはずです。実際、前者のコード文字列にrawurldecode関数でデコードしてみると、全く意味不明な文字列になるのに対して、後者の文字列にrawurldecodeをかけると、UTF-8コードの「実践工業数学参考文献.doc」という元の文字列にきちっと戻すことができます。

そこで思い余って、ええい、PHPの勉強だと思って、rawurl_encodeという別の関数を作ることにしました。一応、正常に動いているような気がします。このrawurl_encodeを使ってMoodleのなかのrawurlencodeを置き換えると、一応Windows上のMoodleでファイルの処理が正常に行えているような気がします。これまであった現象、「実践工業数学参考文献.doc」というファイルがアップロードできないなどというような現象もないようなのです。Moodleの内部処理として、すべてUTF-8コードで処理させられるような気がします。ただ依然として単なる表示がうまくいきません。たとえば、「実践工業数学参考文献.doc」というファイルをアップロードすると、画面上では「_.doc」という表示なります。ただこれだけのことで、このファイルを開いたり、ダウンロードしたりすることは全く問題ないです。ただ以前よりは、私自身の中で進歩した点があります。それは、Primeira LiçãoとかBücherという欧文の文字を使った＜ファイル名＞をきちっと表示してくれるようになったことです。だから、Moodleの内部処理をすべてUTF-8コードで行わせるようにすれば、日本語表示もrawurldecodeでデコードするようにどこかでソースコードを変更すれば、うまくいくのではないか、という期待感があるのですが．．．。

（なお、この私製のrawurl_encodeでMoodleを試してみよう（＝危険を冒してみよう）という奇特な方がいらっしゃいましたら、別途松村にメールをいただけませんか(matsmura@nufs.ac.jp)？というのは、このrawurl_encodeは、文字コード表の独自のデータベースを組み込んだ（辞書的に検索します）大きなデータなのです。圧縮しても1.8MBもある巨大なファイルとなって、ここにアップロードできません（申し訳ないです・・・）。

補足の補足です：　私製のrawurl_encodeとPHP組み込み関数のrawurldecodeとを使えば、Shif_JISコードの文字列からUTF-8の文字列に変換することができるわけですが、今回のプログラムを応用すれば、逆にUTF-8コードからShift-JISコードへの逆変換プログラムも比較的簡単にできると思います。なお、Browserに表示するだけならUTF-8で問題はないでしょうから、その必要はないかと思ってこの逆変換プログラムは作っていません。

お約束の（？）ＩＥではうまくダウロードできない問題にぶちあたりましたが，なんとか解決しました．

奥村先生たちの対策は，send_files()で使う引数のうち，$filenameをＳＪＩＳあるいはＵＲＬエンコードするという方法です．これは当方でも利用しました．

問題はそれ以前にファイルの有無を確認するところでコケてしまいました．
$pathnameに実際のファイルのフルパス名が入っている（UTF-8）のですが，ダウンロードしたいファイル名をクリックしてfile.phpを呼ぶ際に，Firefoxはマルチバイトの文字列をＵＲＬエンコードしてくれます（ＵＲＬではなくてもエンコードしてくれるようですね）．それに対してＩＥ６の場合は生のデータ（ＵＴＦ－８）のままで送信してしまうようです．file.phpが受け取った引数を分割したりしてパス名を切り出して$_GET[]という配列に入れるのですが，ここでデータが欠損するようです．$pathnameは$_GET[]を受け取っている．ところがどこでこの$_GET[]をセットしているのか，コードを読んでも追いきれない．こちらの方向は諦めました．

そこでダウンロードできるファイルの一覧を表示するmod/assignment/type/upload/assigment.class.phpの中のprint_user_files()の中でハイパーリンクを生成する際に，(Firefoxは自動的にコード変換してくれるのと同じように）ファイル名をrawurlencode()してしまう方法を選択しました．

マルチバイトのデータを自動的にエンコードしてくれないのはＩＥの仕様なのでしょうか．それとも設定次第なのでしょうか．

さて，来週は定期試験ですので，ここで一旦，作業を停止します．
実験結果とどこをどう変更すれば良いのか，改めて整理し直して報告します．

---

ＩＥでリンク先のＵＲＬがエンコードすると変になる問題は，以前に松村先生にご報告していただいたS-JISをrawurlencode()すると変になる，という現象に少し似ている感じがします．$_GET[]で受け取った文字列をrawurlencode()すると，例示していただいたようなへんてこりんな文字列（%の後に３文字．正確には%の後に２桁の１６進コード＋１文字のANK文字）になります．rawurlencode()に問題があるのではなく，ＩＥを介してマルチバイトをPHP間で受け渡しを行なうと，マルチバイトを明示的にURLエンコードしないと受け取り側でむちゃくちゃに化ける可能性がある，ということなのかも知れません．

もしかしてPHPのmb_string関係の設定で，強制的にＵＲＬエンコードして送出するという設定があって，それを私の方では設定していないだけ，という可能性もあります．

[mbstring]
; language for internal character representation.
mbstring.Xlanguage= Japanese

; internal/script encoding.
mbstring.internal_encoding = "UTF-8"

; http input encoding.
;mbstring.http_input = auto

; http output encoding. mb_output_handler must be
; registered as output buffer to function
mbstring.http_output = "UTF-8"

; enable automatic encoding translation according to
; mbstring.internal_encoding setting. Input chars are
; converted to internal encoding by setting this to On.
mbstring.encoding_translation = On

; automatic encoding detection order.
;mbstring.detect_order = auto

; substitute_character used when character cannot be converted
; one from another
;mbstring.substitute_character = none;

; overload(replace) single byte functions by mbstring functions.
; mail(), ereg(), etc are overloaded by mb_send_mail(), mb_ereg(),
; etc. Possible values are 0,1,2,4 or combination of them.
mbstring.func_overload = 7