以前、このブログで、「MySQLのODBCで何か文字化け(2) これの調査はほぼ無意味か？」（ http://kzworks.at.webry.info/200805/article_28.html ）という記事を書いたことがあった。UTF8環境で動作しているMySQLサーバーに、Windows上で文字コード変換したデータを突っ込んだところ、全角ハイフンなどが化けてしまった話だ。 UTF8 と Shift_JIS の変換において、Windows OS の持つ文字コード変換テーブルと、MySQLの持つ文字コード変換テーブルが必ずしも一致しているわけではないのだから、多少の文字化けは致し方なしとするのが、その記事での結論だった。 しかし、昨日来、どうしても SQLite では十分なパフォーマンスが得られず、MySQLを使わざるを得ない案件が生じてしまった。しかも、そういう案件に限って「変換テーブルが違うので、多少の文字化けは我慢してください」では済まされなかったりする。 で、最後の手段ということで、MySQL のソースを眺めることにした。文字コード変換用のテーブルがどこかでコーディングされているはずなので、これを Windows の変換テーブルと揃うように改造してコンパイルしてやれば、文字化けは解消するはずだ。 しかし、ソースを調べたことで、事態は全く異なった方向へと進んでいく。 MySQL では、UTF8 <-> SJIS 変換用のテーブルとは別に、 UTF8 <-> CP932 変換用のテーブルが最初から用意されていることが分かったたのだ。そして、SJIS 変換用のテーブルでは全角ハイフンは「変換不能」となっているのに対し、CP932 変換用のテーブルでは変換先のコードがしっかりと指定されていることも分かった。 なら、MySQL サーバーに接続した直後に、SET NAMES CP932; とやれば、文字化けは解消するのではないか。 まず、コマンドラインで試したところ、成功。 続いて、MyODBC接続で、接続時に「SET NAMES CP932;」を発行するように設定して、MS Access から接続してみたところ、これも成功。 ディストリビューションによっては、CP932が無効にされているかも知れないが、とりあえず手元の Debian ではうまくいった。 MySQLの文字化け対策で、Webを検索すると「SET NAMES SJIS;」を発行せよとなっている記事がよくヒットするのだが、Windows からの接続では「SET NAMES CP932;」のほうが相性が良いようだ。

<< 前記事（2008/08/26）

トップへ

後記事（2008/08/27）>>

<< 前記事（2008/08/26）

トップへ

後記事（2008/08/27）>>