民芸的プログラミング 〜ソフトウェア開発日記〜

アクセスカウンタ

zoom RSS MySQLのODBCで何か文字化け(2) これの調査はほぼ無意味か?

<<   作成日時 : 2008/05/28 23:45   >>

ブログ気持玉 0 / トラックバック 0 / コメント 0

8月27日追記
この問題の対策が分かったので、 http://kzworks.at.webry.info/200808/article_58.html に別記事を作成した。
以下は、本記事掲載時(5月28日)のままの内容。


昨日、MySQLにODBC接続してMS-Accessでデータを閲覧しようとすると全角ダッシュ「−」が文字化けするという記事を書いた。しかし、冷静に考えようとすればするほどこんがらがってくる文字コードの問題。今になって思えば、MySQLに突っ込んだ元のデータの作成方法にも問題があったようだ。
CSVデータをテキストエディタのxyzzyで作成しUTF-8N形式で保存(!)したのを、mysql-importで取り込んだだけだった。
xyzzyで全角ハイフンをUTF-8化すると文字コードは「U+FF0D」となる。これは、元のデータの文字コードがいわゆるSJISではなく、Windows 31J(あるいはcp932。SJISとほぼ同じなのだが一部の記号などのコードが微妙に異なっている)と言われるものとして扱われているためらしい。一方、MySQLは文字コード変換のために独自の変換テーブルをもっており、これでUTF-8からSJISへの変換を行っている。この変換テーブルの差異がどうも文字化けの原因となっているようだ。
なので、MySQLへのデータの取り込みの際から、MySQLの文字コード変換テーブルを使用していれば、この文字化けは発生しなかったものと思われる。未テストだが。
またついでにiconvで全角ダッシュを変換してみたところ、「U+2212」となることも分かった。

結局のところ、昨日の調査内容とあわせると
・MySQLは独自の文字コード変換テーブルを内蔵している
・Windows上でSJIS→UTF8変換を行うのとMac上でSJIS→UTF8変換を行うのとでは結果が異なる
・iconvでSJIS→UTF8変換を行うとまた違った結果となる
・元データがSJISではなくcp932だとまた違った結果となる
という結論が得られたことになる。

要は元データに関しては、Windows上ではSJISとcp932の違いを認識する必要がある。文字変換のテーブルに関しても、アプリケーション内蔵(MySQLなど)、Windows標準、Mac標準、iconvで、それぞれ微妙に異なっていることを認識する必要がある、ということのようだ。

MySQLだけを特別に取り立てて論じる問題ではなかった。

テーマ

関連テーマ 一覧


月別リンク

ブログ気持玉

クリックして気持ちを伝えよう!
ログインしてクリックすれば、自分のブログへのリンクが付きます。
→ログインへ

トラックバック(0件)

タイトル (本文) ブログ名/日時

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(0件)

内 容 ニックネーム/日時

コメントする help

ニックネーム
本 文
MySQLのODBCで何か文字化け(2) これの調査はほぼ無意味か? 民芸的プログラミング 〜ソフトウェア開発日記〜/BIGLOBEウェブリブログ
文字サイズ:       閉じる