Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
MySQLもキャラクタ端末もどちらも EUC-JP にしておこう。
ここで、'漢字'という文字列を調べてみよう。 まずは、単純に、'漢字' を SELECT してみよう。
mysql> SELECT '漢字'; +------+ | 漢字 | +------+ | 漢字 | +------+
MySQLには、文字列関数 HEX が用意されていて、引数に文字列を与えると、 その文字列を16進数表示した文字列を返してくる。
mysql> SELECT HEX('漢字');
+-------------+
| HEX('漢字') |
+-------------+
| B4C1BBFA |
+-------------+
これは、EUC-JPの文字列 '漢字' の16進数表記であることが、 別のキャラクタ端末を開き、端末を同じ文字コードのEUC-JPにセットしてから、 以下を実行することで確認できる。
$ echo -n '漢字' | xxd -g 1 0000000: b4 c1 bb fa ....
HEX(文字列）─→ 16進数表記
キャラクタ端末がSJISで、MySQLがUJISの場合
まず、キャラクタ端末の文字コードだけをSJISに変更してやってみよう。
mysql> SELECT '漢字'; +------+ | ?? | +------+ | 漢字 | +------+
すると、こんなことになってしまい、 下側の結果表示の方は正常に表示されているものの、タイトルの方は 変になってしまった。
さらに、そのときの16進数表示も試みてみよう。
mysql> SELECT HEX('漢字');
+-------------+
| HEX('????') |
+-------------+
| 8ABF8E9A |
+-------------+
この結果は SJISのようであるが、以下のようにして一応確かめてみた。
$ echo -n '漢字' | nkf -Es | xxd -g 1 0000000: 8a bf 8e 9a ....
確かにSJISである。
あちこちで ? が表示されてしまうのは、MySQLが文字コードの自動変換を 行なっていて、そのとき変換に失敗すると ? が表示されるためなのである。 詳しくは、この連載の中で次第に分かるようになるのではないかと思う。
キャラクタ端末もMySQLもSJISにした場合
SET NAMES で、MySQLもSJISに設定すると、以下のように、何の問題もなくなる。
mysql> SET NAMES SJIS;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT '漢字';
+------+
| 漢字 |
+------+
| 漢字 |
+------+
1 row in set (0.00 sec)
mysql> SELECT HEX('漢字');
+-------------+
| HEX('漢字') |
+-------------+
| 8ABF8E9A |
+-------------+
1 row in set (0.00 sec)
要するに、
キャラクタ端末とMySQLの文字コード(文字セット)は同じでなければならない。
でも、いつでもそのように設定できる訳ではない。 どんなクライアントでもmysqlのように色々設定可能とは限らないので、 そのときには適切に文字コードの変換をしてやらなければならない。
クライアントとサーバでの文字コードが違うと、MySQLは適切だったり、 不適切な変換を行なうことがあり、そのあたりをきちんと制御しなければならない。 文字化けは、そのとき失敗して変な表示になるケースが圧倒的に多いようだ。 通常はMySQLサーバとの接続の直後に、 SET NAMES で適切なキャラクタセットに設定すると大丈夫になる。
面倒かも知れないが、日本語を扱う以上避けては通れない。
戻る：キャラクタコード変換ツール(nkf, iconv, kcc)
フィードバック：
There is no comment.