〜が~に文字化けするのは直ったか | MySQL日本語の旅

バックスラッシュ(\,5C)の文字化けは、cp932とeucjpmsを使うと発生しないことがわかったが、〜が~に文字化けするのも直っただろうか？

全角の〜が半角の~に文字化けするでは、トラブルの発見までしか記載していないので、その続編の方だけを順を追って調べることにする。

文字端末をEUC-JPにしておいて、同じことを実行してみよう。

mysql> SET NAMES eucjpms;
Query OK, 0 rows affected (0.00 sec)
 
mysql> SELECT '〜';
+----+
| 〜 |
+----+
| 〜 |
+----+
1 row in set (0.00 sec)

問題ないね。

mysql> SELECT HEX('〜');
+-----------+
| HEX('〜') |
+-----------+
| A1C1      |
+-----------+
1 row in set (0.00 sec)

〜は JIS X 0208 の01区33点であり、EUC-JP では A1C1 になる。

mysql> SELECT _eucjpms 0x7E, _eucjpms 0x8FA2B7, _eucjpms 0xA1C1;
+---+-----+----+
| ~ | 〜  | 〜 |
+---+-----+----+
| ~ | 〜 | 〜 |
+---+-----+----+
1 row in set (0.00 sec)

0x8FA2B7 では、マスの幅が１つ間違っているようだが、この件(文字幅)に関しては後でじっくり語ることにしよう。

0x8FA2B7 と 0xA1C1 では、いずれも同じ〜になってしまったように見えるが、本当にそうなのか調べてみよう。

前回は USING を使って sjis に変換したが、今回はcp932に変換してみる。なお、0x8FA2B7は補助漢字の方の〜である。

mysql> SELECT HEX(CONVERT(_eucjpms 0x8FA2B7 USING cp932));
+---------------------------------------------+
| HEX(CONVERT(_eucjpms 0x8FA2B7 USING cp932)) |
+---------------------------------------------+
| 8160                                        |
+---------------------------------------------+
1 row in set (0.00 sec)
 
mysql> SELECT HEX(CONVERT(_eucjpms 0x8FA2B7 USING sjis));
+--------------------------------------------+
| HEX(CONVERT(_eucjpms 0x8FA2B7 USING sjis)) |
+--------------------------------------------+
| 3F                                         |
+--------------------------------------------+
1 row in set (0.00 sec)

さらに、utf8に変換してみよう。

mysql> SELECT HEX(CONVERT(_eucjpms 0x8FA2B7 USING utf8));
+--------------------------------------------+
| HEX(CONVERT(_eucjpms 0x8FA2B7 USING utf8)) |
+--------------------------------------------+
| EFBD9E                                     |
+--------------------------------------------+

前回は試さなかったが、普通の〜 (0xA1C1)についてもutf8に変換してみよう。

mysql> SELECT HEX(CONVERT(_eucjpms 0xA1C1 USING utf8));
+------------------------------------------+
| HEX(CONVERT(_eucjpms 0xA1C1 USING utf8)) |
+------------------------------------------+
| EFBD9E                                   |
+------------------------------------------+
1 row in set (0.00 sec)

あれ、変なことになってしまった。

0xA1C1(JIS X 0208)と 0x8FA2B7(JIS X 0212)が同じになってしまった。規格書を良く見ると分るんだが、0x8FA2B7(JIS X 0212)は、 0x7E(~)が JIS X 0201 では「半角の上線」になっていて、それでは半角の~が無いではないかと言うことで、補助漢字を作ったときに、02区に半角の文字をつっこんでしまったのが混乱を引き起こした原因だと推測できる。

という能書があるのだが、どうせ補助漢字(JIS X 0212)なんぞ殆ど使われていないのだから無視しても構わないと思わないでもないので、重箱の隅をつつき過ぎてはいけない。

sjisの場合には補助漢字の〜がlatin1にも変換できたのだが、どうなるだろうか。

mysql> SELECT HEX(CONVERT(_eucjpms 0x8FA2B7 USING latin1));
+----------------------------------------------+
| HEX(CONVERT(_eucjpms 0x8FA2B7 USING latin1)) |
+----------------------------------------------+
| 3F                                           |
+----------------------------------------------+
1 row in set (0.00 sec)

今度はそんな無茶なことはできないようで、3F(?)になった。

mysql> SELECT HEX(CONVERT('〜' USING cp932));
+--------------------------------+
| HEX(CONVERT('〜' USING cp932)) |
+--------------------------------+
| 8160                           |
+--------------------------------+
1 row in set (0.00 sec)

これも問題なく、普通の２バイトの〜に評価された。

'〜' と '~' の比較をやってみよう。

mysql> select '〜' = '~';
+------------+
| '〜' = '~' |
+------------+
|          0 |
+------------+
1 row in set (0.00 sec)
 
mysql> select CONVERT('〜' USING cp932) = CONVERT('~' USING cp932);
+------------------------------------------------------+
| CONVERT('〜' USING cp932) = CONVERT('~' USING cp932) |
+------------------------------------------------------+
|                                                    0 |
+------------------------------------------------------+
1 row in set (0.00 sec)

問題なく、異なるという結果になった。

\(5C)の場合についても同じテストをしておこう。

mysql> select CONVERT('＼' USING cp932) = CONVERT('\\' USING cp932);
+-------------------------------------------------------+
| CONVERT('＼' USING cp932) = CONVERT('\\' USING cp932) |
+-------------------------------------------------------+
|                                                     0 |
+-------------------------------------------------------+
1 row in set (0.00 sec)

こちらも大丈夫だ。

結論は

さて、比較テストは終了なんだが、ちょっと問題が残っていることが判明した。その問題点は、補助漢字の場合なんだが、どうせ補助漢字は使われていない、使うための手段がそもそもほとんどないので、ここでは無視することといしょう。

念のため、補助漢字の最初の漢字(たくみ、巧の右半分だけの文字)について確認しておこう。

mysql> SELECT HEX(CONVERT(_eucjpms 0x8FB0A1 USING utf8));
+--------------------------------------------+
| HEX(CONVERT(_eucjpms 0x8FB0A1 USING utf8)) |
+--------------------------------------------+
| E4B882                                     |
+--------------------------------------------+
1 row in set (0.00 sec)
 
mysql> SELECT HEX(CONVERT(_utf8 0xE4B882 USING eucjpms));
+--------------------------------------------+
| HEX(CONVERT(_utf8 0xE4B882 USING eucjpms)) |
+--------------------------------------------+
| 8FB0A1                                     |
+--------------------------------------------+
1 row in set (0.00 sec)

漢字部分は大丈夫なのかも知れない。危ないのは、補助漢字の記号部分のようだ。

cp932, eucjpms を用いると、キャラクタセットの変換はうまく行くようだ。
ただし、補助漢字の記号部分に関しては要注意で、問題も残っているが、ほとんど使われていない補助漢字について、あまり気にしてもしかたあるまい。

こんな「いい加減」なことで良いのだろうか。でも、こういう判断で使うのが丁度「よい加減」かも知れない。

戻る：全角のバックスラッシュ(＼) はどう変換されるか

次へ：LENGTH()で文字列長を求める

フィードバック：

There is no comment.

Chat (Lingr.com)

Informaiton

Daily

Column

Zope Solution

Extra

アーカイブ

OSS案内所

Site Info

関連リンク

結論は