文字コードについて勉強したおかげで MySQL の文字化けに対処できた

以前、このブログで、「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;」のほうが相性が良いようだ。

ブログ気持玉

クリックして気持ちを伝えよう!

ログインしてクリックすれば、自分のブログへのリンクが付きます。

→ログインへ

なるほど(納得、参考になった、ヘー)
驚いた
面白い
ナイス
ガッツ(がんばれ!)
かわいい

気持玉数 : 3

なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー)
ナイス

この記事へのコメント

この記事へのトラックバック