Ajax対応のためのUTF-8化のその後

プログラミング

いやー、結構大変でした。一日かかりました。


まず、一番目に想定していた方法はダメでした。
ディレクティブにphp_value等でmbstring関連の設定を上書きし、ローカルな設定を施すということです。これはちょっと想像してもわかるけど、やはり.htaccessだけでもダメだったわけで、それをディレクティブに変えようが同じわけですな。けれどもなぜこのサーバのPHP4.3.10は.htaccessでmbstring関係のグローバル設定を上書きしようとすると、PHPがFatal Errorで終了してしまうのだろう？？？　その答えは今もなぞのままです。


そこで2番目の方法、もう一つのサーバに素直に設定を施すということです。
もう一つのサーバはRapidsiteのVPSサーバで、あまりPHPやMySQLは使っていないので、作業もやりやすいということもあります。


まず、このサーバで.htaccessでmbstring関連がUTF-8に適応するように設定しました。こんな感じです。

internal_encodingがSJISのままでなんでUTF-8に揃えられなかったかと言うと、それはDB（MySQL）の文字コードとの統一のためです。（後述）


そしてphpinfo();をそのディレクトリ下でやってみると、見事エラーも無く、ローカルバリューがグローバルバリューを上書きしていました。やっぱりトラブルのあったサーバはおかしいのです。なんか変なコンパイルオプションやったかな？？


もう一つ、このサーバで稼動させるのにDBの問題がありました。
VPSで標準で用意されていたのはMySQLのVer3、しかもSJIS有効になるように、default_character_set = sjis してやってもsjis.confが無いとか言われて、何か有効にコンパイルされてないみたいです。


そこで気の短い俺はあきらめまして、新しくMySQL4.0をコンパイルすることにしました。なんで4.0かと言うと、俺が4.1以上の文字コード設定周りの仕様変更に関してあまりなれていなく、4.0でずっと安定運用してきているという実績を持っていたからです。確かに4.0ではデフォルトのエンコードをUTF-8にすることは出来ないし、4.1以降ではすごく細かいレベル（DB単位、テーブル単位、フィールド単位）までエンコードを指定できます。4.1以降を使うには僕のDB周りのツール等も含めて、もっと実験をして経験をつんでからでないとダメでしょう。


コンパイルはあっさり行きました。
無事設定起動させて、早速メモアプリでも使えるメモのカテゴリ用のテーブルをSJISで作成しました。後は、出力関係がUTF-8化されているPHP環境からアクセスして無事にSJISのDBデータが自動変換されるかと言うところです。


すぐに新サーバに俺フレームワークを設置して、メモアプリの続きの部分でDBからデータを取得してみました。


無事成功！！


ちゃんとSJISで取得したDBのデータがPHPのinternal_encodingと合わせてUTF-8に変換されて出力され、文字化けもありませんでした。DBでなくプログラム中で書かれている日本語（UTF-8）も同様に表示されているということで、全く問題ないことがわかりました。


ここまで一日かかってしまいました。
けど、PHPのmbstring関係の設定の各役割に関してとか、MySQL関係の日本語の扱い関係とかに関して、良い復習をすることが出来ました。と同時に、やはり当初考えていた方向性で間違いは無く、設定しようとしてサーバのPHPの問題であっと事がわかり非常に安心しました。


と同時にDB周りも早くUTF-8化できるように、MySQLの5以降をもっとよく調べないとな。同時にツール周りも整理しないと。