MySQL 6.0 の Unicode 4バイト対応と新常用漢字

（2009年12月15日追記： MySQL 6.0 は5月に開発凍結となっており、この記事で述べている新機能の行方は不透明な状況です。「MySQLの改定常用漢字表対応が危うい件」もお読みください。）

だいぶこの話題を書くのが遅くなってしまったが、新しい常用漢字表の議論がそろそろ佳境なので、このタイミングで書き記しておく。

オープンソースのデータベース管理システム「MySQL」は、特に Web システムを中心に、すでに国内外で多数の主要企業が導入している。しかし、マルチバイト文字については、たとえば商用の Oracle や、別のオープンソースの PostgreSQL などと比べて、対応が進んでいるとは言えなかった。

そんななか、遅まきながら昨年（2008年）の3月、MySQL 6.0.4 alpha にて、Unicode の4バイト領域を扱えるようになった。ただし正式版は MySQL 5.1 系が最新であり、現在でも MySQL 6.0.9 "alpha" となっているので、正式版としては未対応ということになる。

対応の方式としては、旧来の３バイト限定の utf8 は utf8mb3 と改名され、utf8 の命名のままで4バイト領域を扱えるようになった。これは Oracle も互換性維持のため2方式を残したのと同様であり、妥当なところだろう。

ただ、ドキュメントをよく見てみると、少々気になることが書いてあった。

The current rule that all supplementary characters are equal to each other is non-optimal. However, we don't expect the rule to cause trouble. These characters are very rare, so it will be very rare that a multi-character string consists entirely of supplementary characters. In Japan, since the supplementary characters are obscure Kanji ideographs, the typical user doesn't care what order they're in, anyway. If you really want to get rows sorted by MySQL's rule and secondarily by code point value, it's easy:

("MySQL 6.0 Reference Manual :: 9.1.13.1 Unicode Character Sets" より引用）

おそらくこの認識は MySQL（現 Sun Microsystems）日本法人の松信嘉範さんに由来するのではと、MySQL メーリングリストの投稿を思い出しながら推測していた。

私は、ユーザーにとってこの機能はどこまで必要性が高いのか、
日常的に使いそうもない文字ばかりだが本当に使うのか、
バイナリ型の利用では本当に受け入れられないのか、
といった具体的な事情を現時点では把握しきれていません。

（松信嘉範「[mysql 13823] MySQLの現行UTF-8の問題とその対処方法について」（2007年3月26日）より引用）

この投稿を見たとき、ちょっとまずいなと思っていた。JIS X 0213:2004 には、Unicode の4バイト領域にあてがわれてしまった漢字が303文字ある。しかしそれらには JIS なりに検討した上での採用理由があるはずで、技術者が「日常的に使いそうもない文字ばかりだが本当に使うのか」と考えてしまうのは、やはり出過ぎた判断だからだ。

特に、「𠮟」（口へんに七）は、現在議論されている新常用漢字（仮称）において、新たに追加されるのがほぼ確実な漢字である。少なくとも情報通信機器では一般的な「叱」が標準の字体として採用されれば良いのだが、安岡孝一さんの日記や小形克宏さんの日記を読む限りでは、どうやら「𠮟」（口へんに七）のほうが試案に掲載されているようだ。それは、表外漢字字体表の印刷標準字体に合わせるための改定である JIS X 0213:2004 にて追加された字体である。厳密に言うと表外漢字字体表では、「叱」はデザイン差（字体としては同じ）として示されているが、文字コードにて別のコードポイントを割り当てた IT の世界では、これらは別の字体と捉えなければならなくなる（きっと教育現場等でもそうだろう）。そして、その追加した字体は Unicode の4バイト領域にある。

（注： Windows XP の「MS 明朝」「MS ゴシック」では「𠮟」（口へんに七）などの漢字を表示できない可能性があります。その場合、表示させるためにはマイクロソフトのサイトから新バージョンの「MS 明朝」「MS ゴシック」あるいは新フォント「メイリオ」を入手してインストールする必要があります。Windows Vista や Mac OS X では標準設定でおそらく正しく表示されます。なお、インストールや設定変更はサイトの説明等を確認のうえ自己責任でお願いします。）

一応、自宅PCに入れてある Windows 版 MySQL 6.0.8 alpha にて、簡単なテストをしてみた。テーブル（char_test_table）の文字列カラム（name）に、「晴」「𠮟」「𠀋」「叱」「丈」の順番で挿入したのち、各種のSQL問合せを行った。各問合せとその結果（1行表示に別途整形済み）の羅列を以下掲載する。

SELECT name FROM char_test_table;  -- (1)
晴 𠮟 𠀋 叱 丈 
SELECT HEX(name) FROM char_test_table;  -- (2)
EFA892 F0A0AE9F F0A0808B E58FB1 E4B888 
SELECT HEX(WEIGHT_STRING(name)) FROM char_test_table;  -- (3)
FA12 FFFD FFFD 53F1 4E08 
SELECT CHAR_LENGTH(name) FROM char_test_table;  -- (4)
1 1 1 1 1 
SELECT name FROM char_test_table ORDER BY name;  -- (5)
丈 叱 晴 𠮟 𠀋 
SELECT name FROM char_test_table ORDER BY name COLLATE utf8_unicode_ci;  -- (6)
丈 叱 晴 𠮟 𠀋 
SELECT name FROM char_test_table ORDER BY name COLLATE utf8_bin;  -- (7)
𠀋 𠮟 丈 叱 晴 
SELECT name FROM char_test_table ORDER BY name COLLATE utf8_unicode_ci, name COLLATE utf8_bin;  -- (8)
丈 叱 晴 𠀋 𠮟 
SELECT name FROM char_test_table ORDER BY WEIGHT_STRING(name);  -- (9)
丈 叱 晴 𠮟 𠀋 
SELECT name FROM char_test_table ORDER BY HEX(name);  -- (10)
丈 叱 晴 𠀋 𠮟 

MySQL のドキュメントにも掲載されている問題点として、(3) の WEIGHT_STRING の返り値が「𠮟」でも「𠀋」でも「FFFD」となってしまっている。これが (5) (6) の整列に影響している。本来、昇順の整列では「𠀋」(U+2000B)「𠮟」(U+20B9F) の順に並ぶはずだが、WEIGHT_STRING が同値のため、テーブル内の順番どおりになってしまう。なお、(7) の結果はにわかには理解できない様相である。

MySQL ドキュメントでは (8) の方式を紹介しており、これだと確かにそれらしい整列順となっている。でも (10) のほうが直感的に理解しやすいかも（規格との整合性や性能については考慮していない）。

このほか、文字数はきちんと (4) のように1文字として数えているし、LIKE '𠮟' のような問合せ条件を別途試しても OK だったし、とりあえず普通の用途には大丈夫そうな印象である。ドキュメント等によると、MySQL 5.1 から 6.0 へデータを移行する際には、文字列カラムの文字数やインデックスの定義の変更が必要とのことで、無対応というわけにはいかないようだ。しかしながら、おおむね妥当なところで収まっているようで、きっと松信さんもいろいろと尽力なさったのだろう。無償で使わせてもらっている身としては素直に感謝したい。

それにしても、新常用漢字かぁ・・・今後あちこちで悲鳴が聞こえてきそうだ（苦笑）