C#2.0時代のゲームプログラミング(42)

Connector/ODBC(MySQL用のODBCドライバ)とConnector/NETに関する調査報告。


Connector/ODBCのソースを読んでいくとわかるが、MySQL client(frontend)とやりとりするためにlibMySQLというMySQLのライブラリを使っている。そしてこいつが、文字コードの変換テーブル自体も持っている。何故このような仕様になっているのか歴史的な経緯については知らないが、動作環境に左右されたくなかったのかと推察する。


そして現在のバージョン(Connector/ODBC 3.51)では、libMySQLとMySQL clientとの間はucs2に対応していないようだ。mySQL client起動時に--logオプションを入れるとやりとりしているログを出力できるのだが、そのログを見る限り、どうもsjisでしかやりとりされていないようだ。またmySQLのclientにDOS窓からリダイレクトでset names ucs2;として、そのあとucs2 charasetでSQL文をリダイレクトさせたが、それもエラーになる。MySQL client自体がucs2に対応していないので当然の結果、というところか。ちなみにutf8では文字化けを起こす。


結局のところ、ODBCドライバとMySQL clientの間がsjisなのが気持ち悪いという話なのだが、解決はなかなか難しい。Windows限定で良ければこれに対応させるためのpatchを作成するのは難しい話ではないが、ソースを相当深くまで読んでいかないといけないし、Connector/ODBCの公式でいずれは対応されるのだから、それを行なうことがあまり意味のある行為とも思えない。要するにgive upである。


ちなみに、Connector/NET経由であればutf8でやりとりできる。広く一般にお勧めできる解は、これである。ただし、何度も言うようにYanesdk.NETでこれをサポートするわけにはいかない。


で、私は自分の仕事で使っているプロジェクトではODBCドライバ経由でMySQLにアクセスして、「set names sjis;」としておけばいいか、ということになった。MySQLのDB上はucs2で格納されているので、いずれODBCのドライバがucs2に対応すれば、そのときに「set names ucs2;」に変更すればいいやん、どうせしばらくはsjis文字コードの範囲でしかDBには格納しないんだし、という結論になった。