5月 23
最近XOOPSやOpenPNEの文字コードでハマリまくっている。ようやくそのトリックが分かったので、メモっておく
問題となる場合
まず文字コードが問題となるバージョンなのだが、4.1系でよく起こる。ソースからコンパイルしてインストールする場合には、オプションが指定できるので、大きな問題にはならないのだが、RPMなどの事前にコンパイルされたバイナリの場合は要注意だ。
RPMパッケージの場合
RPMによりインストールされたMySQLをデフォルトの設定ファイル（my.cnf）で起動してサーバの環境変数（文字コード周り）を確認すると以下のようになる。
mysql> show variables like '%char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | latin1 | | character_set_results | latin1 | | character_set_server | latin1 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ 7 rows in set (0.00 sec)
実はこのまま何も考えずにXOOPSやらOpenPNEなどをインストールしてもうまくいくのだが、よくよく考えるとおかしいことに気付く。文字コードlatin1とはいかがなものか？ISO8859-1で日本語が扱えるのか非常に疑問だったりする。
なぜうまくいくのか
それは、MySQLの起動オプションで「skip-character-set-client-handshake」を付けずに起動しているからだ。
このオプションがついていない場合、MySQLは接続された際の文字コードと内部に持っている文字コードの違いをうまい具合に吸収して、あたかも問題ないような挙動を見せる。ところが、日本語文字列で検索する場合にボロがでる。正しく検索できない文字が発生したりするのだ。
解決策
このような現象を避けるため、以下のオプションを付けて起動すれば正しく処理される
[mysqld] default-character-set=ujis skip-character-set-client-handshake [client] default-character-set=ujis
もちろんOpenPNEの場合は、ujisをutf8に変更することが必要だ。
Recent Comments