＠檸檬の家

Android携帯(HT-03A)搭載フォントは JIS X 0213 未対応

先月（2009年12月）に、Android 携帯の HT-03A （台湾の HTC 製） を購入した。今のところ（開発用機器を除くと）日本で唯一の Android 携帯なのだが、本体価格は投げ売り状態で、池袋の量販店では0円か1円かという有様だった。また、昨年末から NTT ドコモが、スマートフォン向けのキャンペーンや新料金プランを相次いで実施している（特に「タイプシンプル バリュー」は店員が案内しない場合もあるので要チェック）。他に乗り換えるなどして全然使わなくなっても、不要なオプション、保険、さらにパケット定額対象のプロバイダ契約も止めれば、月々の支払いを800円以下に抑えられる。2年後の契約切れまで使い切らなくてもさほど負担にはならないと思い、購入に至った。いろんな機能を試したり、Android アプリケーション作成に挑戦してみたり、まあそれなりに楽しめるオモチャである。

そしてついつい、改定常用漢字表対応も試してしまった。

この結果は Android アプリケーションとしての出力だが、同様の文字列の Web ページをブラウザで表示させても同様だった。改定常用漢字表（試案）の中で、旧来の環境では特に問題が生じる字体「塡」「剝」「頰」「𠮟」のうち、やはり「𠮟」（くちへんに「七」）だけは表示されない、ということだ。

ただし、Android プラットフォームとしては Unicode の4バイト領域を処理できていて、Android 用の日本語フォントが「𠮟」（くちへんに「七」）に未対応なため、このような表示となっているのではないかと予想する。Android の C/C++ ではワイド文字型の wchar_t が4バイトなのだそうで、Google Groupのandroid-ndkでも驚きを伴う話題になっていたようだ。今後 Google はそれをサポートせず、代わりに ICU (International Components for Unicode) を使用するとのことである（日本Androidの会でのTetsuyuki Kobayashi さんの投稿より）。この ICU はもちろん Unicode の4バイト領域を処理できるコンポーネントである。

Android のフォントについて検索してみると、mashabow さんという方のブログ記事「16000字超の漢字と11000字超のハングルが入った軽量CJKフォント Droid Sans Fallback」を見つけた。Android 用のフォントは Ascender Corporation が開発、提供していて、この記事が書かれた2009年2月時点では Droid Sans Fallback (DroidSansFallback.ttf) というフォントで日本語がサポートされていた。しかしその漢字サポートの範囲は、"GB2312, Big 5, JIS 0208 and KSC 5601" （2007年11月の同社のプレスリリース "Ascender creates the new Droid font collection for Open Handset Alliance's Android platform" より） であって、中国語や韓国語も表示可能な一方で、JIS X 0213 は未対応ということになる。

そして、旧来の文字コード（JIS X 0208）と Unicode とのマッピングで問題となる漢字が先の４字（「塡」「剝」「頰」「𠮟」）なのだが、Unihan Database Lookup によると、「塡」は韓国語（KSC 5601、現在の KS X 1001）、「剝」「頰」は韓国語と繁体字中国語（Big 5）で対応しており、残るは結局「𠮟」（くちへんに「七」）ということになる。それゆえ先の写真で示したような状況となっていると推測する。

なお mashabow さんの記事では「もちろん、ひらがな・カタカナもちゃんと収録されているが、デザインが若干ぎこちない。おそらくは華康ゴシック体のかなと同じもの。また、漢字の筆画処理が大陸風なので、日本語の表示には難があるかもしれない。」としているが、現在では Droid Sans Japanese (DroidSansJapanese.ttf) という日本語向けフォントが用意されている。Android 開発環境（Android SDK）を確認してみると、Android 1.5 と 2.0 には含まれていないが、Android 1.6、2.0.1 と 2.1 には搭載されている。購入時は Android 1.5 を搭載している HT-03A でも日本語向けフォントぐらいは先行搭載していただろうし、購入後すぐに 1.6 （2009年10月配信開始）へのアップデートが起動するので、いずれにせよ現在では日本語風の書体を利用できる。今年相次いで発売される予定の Android 携帯は、おそらくその点については心配ないだろう。

とはいえ、つい数日前にリリースされた最新の Android 2.1 でも、DroidSansJapanese.ttf のファイルサイズ（1,173,140 バイト）に変化はない。Android SDK のエミュレータ (AVD) で先のアプリケーションをテストしても結果は変わらなかった。安岡孝一さんのブログ記事「【改定常用漢字表試案への意見】テンプレート」で列挙されている漢字に対象を拡大し、エミュレータ上でテストした結果は、下のような感じである。

他の携帯電話や Windows XP ともまた違う結果なのだが、要するに JIS X 0213 にはまだ対応していない。今月 Google が発売した Nexus One （Android 2.1 搭載）でもおそらく同様で、「𠮟」（くちへんに「七」）は表示できないだろう。ソニーエリクソン、シャープ、NEC 等、日本のメーカーが今年発売予定の Android 携帯は、果たしてどうだろうか？

MySQLの改定常用漢字表対応が危うい件

今年の1月の記事「MySQL 6.0 の Unicode 4バイト対応と新常用漢字」では、アルファ版ではあるものの MySQL 6.0 ならば Unicode の4バイト領域に対応しており、たとえ常用漢字として「叱」ではなく「𠮟」（口へんに七、U+20B9F）が追加されても MySQL としては対応可能だということを書いた。

ところが、その MySQL 6.0 は、今年5月の 6.0.11-alpha を最後に、開発を凍結してしまったそうだ。Sun Microsystems の奥野幹也さんのブログ記事「Good Bye MySQL 6.0」にいまさらながら気付いた。開発リソースを 5.x に集約するのが目的らしく、現在ベータ版の MySQL 5.4 には MySQL 6.0 の新機能がいくつか取り込まれているとのことである。だがしかし、5.4 に入っていない主な機能として、そのものずばり、「4バイトUTF-8」が挙げられていた。

MySQL の現在の正式バージョンは 5.1 であり、今年１月から変化していない。その次は 5.4、さらにその次は 5.5 となるそうで、MySQL のサイトを見た限りでは、5.5 はまだアルファ版の配布にも至っていない段階である。

一応 MySQL 5.4 と 5.5 のドキュメントを確認してみたが、やはり 5.5 でも今のところ対応の予定は無さそうに見える。

MySQL 5.5 supports two character sets for storing Unicode data:

• ucs2, the UCS-2 encoding of the Unicode character set using 16 bits per character
• utf8, a UTF-8 encoding of the Unicode character set using one to three bytes per character

These two character sets support the characters from the Basic Multilingual Plane (BMP) of Unicode Version 3.0. BMP characters have these characteristics:

• Their code values are between 0 and 65535 (or U+0000 .. U+FFFF)
• They can be encoded with a fixed 16-bit word, as in ucs2
• They can be encoded with 8, 16, or 24 bits, as in utf8
• They are sufficient for almost all characters in major languages

The ucs2 and utf8 character sets do not support supplementary characters that lie outside the BMP.

(MySQL 5.5 Reference Manual :: 9.1.10 Unicode Support より引用)

これはマズイのではないか。何とかしてください、MySQL 様、Sun Microsystems 様・・・あれ、Oracle 様でしたっけ。ちなみに、Sun の奥野さんには一度お会いしたことがある。たぶん私のことは忘れていると思うけど（苦笑）。

やっぱり、安岡孝一さんが呼びかけているように、改定常用漢字表試案のパブコメで訴えるべきなのだろう。でも、ここまでの漢字小委員会の様子を見る限り、「情報化社会の進展」を改定の動機に挙げておきながら、文字コード関係の専門家は委員会に見当たらないし、１回目のパブコメに対するフィードバック（字種の追加希望に対する可否の理由の説明など）を出すようなことを審議中に言っておきながら、結局は出さずじまいである。それに、「裁判員制度」「18歳成人」や「障がい者制度改革推進本部」など、常用の語彙を民主的に決めてから常用漢字の話をしたほうが良いのではと思えるような施策も出現している。そんな中での2回目のパブコメ募集には、それ自体についていろいろ思うところがある。どうしようかなあ。

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 へデータを移行する際には、文字列カラムの文字数やインデックスの定義の変更が必要とのことで、無対応というわけにはいかないようだ。しかしながら、おおむね妥当なところで収まっているようで、きっと松信さんもいろいろと尽力なさったのだろう。無償で使わせてもらっている身としては素直に感謝したい。

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

「叱」の印刷標準字体「𠮟」の表示テスト

とりあえず「𠮟」（口（くち）へんに七）を表示するテスト。ちなみに現在、文化庁の文化審議会国語分科会漢字小委員会にて、新常用漢字表（仮称）の策定作業が進んでおり、現在は表外字である「しかる」という字が新たに選出される可能性が高まっている。小形克宏さんのブログ記事によると、今のところ字体の選定はなされていないようである。もしも標準の字体として、情報通信機器では一般的な「叱」ではなく、表外漢字字体表における印刷標準字体の「𠮟」が採用されるようだと、その字は新常用漢字と人名用漢字の中でおそらく唯一、Unicode（UTF-8とUTF-16のいずれも）において4バイト（Unicodeスカラー値はU+20B9F）となる。ちなみに、漢字小委員会の直近の配布資料では、どうやらそちら（「𠮟」）のほうらしい。さて・・・

（2009年2月1日追記）以前はUTF-8の4バイト領域の文字をそのまま掲載可能だったのだが、いつの間にかその文字（口へんに七）が消去されてしまった。ブログサーバ運営側（ブログ人）による各種メンテナンスの際に、おそらくデータ形式の移行が発生し、4バイト領域の文字が扱えなくなってしまったようだ。推測するに、今までバイナリとして通していたのを、（4バイト領域未対応の）UTF-8文字列として扱うように変更したのではなかろうか。少々残念な気もするが事情は理解できるし仕方ない。「𠮟」という、数値文字参照の形式に変更しておく。

住基ネットの「統一文字仕様書」は「ソフトウェアの世界に対するテロ」？

(注) 住基ネット (住民基本台帳ネットワークシステム) 自体の是非については、この記事では何も言及していないことにご留意ください。

仕事半分、趣味半分で、文字コードに関する次の二つのメーリングリストに登録している。それぞれにおいて、回数はごくわずかだが発言したこともある。

• Legacy-Encoding-talk-ja (ML運営者： ミラクル・リナックス株式会社)
• XMLと文字メーリングリスト (ML運営者： 川俣晶さん)

Legacy-Encoding-talk-ja においては、Windows の機種依存文字を扱えるように ISO-2022-JP を独自拡張した符号化方式 (ISO-2022-JP-MS) をミラクル・リナックス (森山将之さん) が提案している。それに対し、NTTの風間一洋さんは、既存の文字集合にあらたな符号化方式を今から独自に作り出すのは有害無益であり、白紙に戻すべきだと主張している。

今でさえ，レガシーエンコーディングが山のように有ります．それらを使わざるをえないケースというのはあるでしょう．しかし，今更，それらと違う新しいレガシーエンコーディングを作っても，どちらにせよ完全に解決できない問題を，さらに複雑化するだけでしょう．

また，新しいことは，できる限り国際的にやるべきであって，局地的にやるべきではないと思います．局地的にゲリラ的にやるのは，ソフトウェアの世界に対するテロでしかないと思います．としたら，今はISO/IEC 10646に対しておこなうしかない．

風間一洋, "[LE-talk-ja 100] Re: ISO-2022-JP-MS について", 2006年4月30日

このように、NTT の風間さんは「ゲリラ的」「テロ」といった厳しい表現を使って批判している。主張の内容自体は正しいと思うものの、ｉモード (NTTドコモ) の絵文字などのほうが、あえて言うならば別の意味で「局地的」「ゲリラ的」「テロ」だったのでは？(笑) と意地悪な突っ込みを入れたくなるほどに、言葉が過ぎている印象も受ける。念のため繰り返すが、主張の内容自体は正しいと思う。風間さんの2006年3月17日のブログ記事では、もっと穏やかな表現を用いた同様の主張が展開されており、JIS X 0213 対応を意識する重要性にも言及されている。

さて、もう一方のML (XMLと文字メーリングリスト) では、ミラクル・リナックスCTOの吉岡弘隆さんが、住基ネット (住民基本台帳ネットワークシステム) の「統一文字仕様書」という文書の入手方法を誰かご存じないかと質問していた。それについての情報をまとめると、おおよそ以下のようになる。

• 財団法人地方自治情報センターに吉岡さん (ミラクル・リナックス) が問い合わせたところ、以下のような返答だったらしい。
  • 「統一文字仕様書」及び関連資料は、利用範囲を限定して、国及び地方公共団体にのみ提供している
  • 利用範囲に係る国または地方公共団体の業務を受託している場合は、委託元より入手して頂く
• 加除出版、富士通、日立、TRONプロジェクトなどは、この「統一文字仕様書」を入手した上でのビジネスを Web 上で PR している

要するに、文字コードを盾に取った参入障壁が、住基ネットを元にして (住基ネットの外でも) 築かれている。住基ネットの文字コードが情報非公開で、Unicode の漢字以外の領域に勝手な外字追加を実施しているらしいということは、加藤弘一さんの「ほら貝」の「文字コードから見た住基ネットの問題点」という記事でうかがい知ってはいた。あらためて検索してみると、testnodaさんという方のブログ記事「統一文字コード」にも同様のことが記されている。どうやら確かな話らしいが、本当にそうなのか私には確認できない。言うまでもないが、私が悪いのではない。

吉岡さんは以下のようにやりきれなさを表明している。

やはりそうですか？
できない事情があるんでしょうね。

うーん。

いろいろ大人の事情はあるかと思うのですが、
見えない参入障壁があるというのはフェアじゃない
ですよね。

吉岡弘隆, "[XML MOJI 01686] Re: 住民基本台帳ネットワークの文字コード", 2006年4月26日

なんか秘孔をついてしまったのかもしれない。

国または地方公共団体へのオープンソースソフトウェアの導入
推進という意味で、非公開の資料があるという現状は制度的に
導入を阻害している要因だという風に認識いたしました。

吉岡弘隆, "[XML MOJI 01687] Re: 住民基本台帳ネットワークの文字コード", 2006年4月28日

まったくその通りである。

吉岡さんは2006年3月17日のブログ記事やMLにおいて、動くコードをとにもかくにも実装して世に問うオープンソースの「バザールモデル」の利点を、厳密だが時間のかかる公的標準の制定プロセスと対比して主張している。それらの優劣はさておき、バザールモデルにせよ、公的標準にせよ、公開性 (情報や権利を公開し新規参入を妨げない性質) を指向している点では共通しているはずだ。住基ネットの「統一文字仕様書」が非公開であることは、バザールモデルか公的標準かという議論以前の問題である。

住基ネットの活用が拡大し、他のシステムと連携する場面が増加すれば、こうした参入障壁の弊害も拡大し、仕様の公開を要求する声も増加することになる。そして、「統一文字仕様書」への準拠を多くのソフトウェアが求められるような状況となったら、その内容次第では、「ソフトウェアの世界に対するテロ」というような事態に陥ってしまう恐れがある (・・・やはり言葉が過ぎている？)。本当にそうなのか私には確認できない。言うまでもないが、私が悪いのではない。

株券等の電子化でも Unicode を採用し JIS X 0213 に対応

ほふり (証券保管振替機構) の株券電子化小委員会が「株券等の電子化に係る制度要綱」をとりまとめ、機構の先月 (2006年3月) の取締役会にて承認されたとのことである。それによると、文字コードについて、符号化方式は Unicode を採用し、文字集合は、経過措置として当初は JIS X 0208 (JIS第2水準まで) に人名用漢字を加えたものとし、そして、制度移行後の早い段階でJIS X 0213 (JIS第4水準まで) に完全対応することを目指すものとされている。

この新しい制度の策定について、文字コードはシフトJISの拡張で済ませる可能性があるとの観測を耳にしていた。JIS第3、第4水準に完全対応せず、一部の抜粋で済ませ、既存の外字と併用する、というような話だった。そんな怠惰にユーザ (株式会社や株主) が納得するとはとても思えなかっただけに、おおよそ妥当なほふりの結論を聞いてほっとしている。

ネット上で公開されている株式電子化小委員会における審議状況を見ると、文字コードについての方向付けが決まったのは、2005年8月の第3回委員会 (正確にはそれに先だって開かれた分科会) での議論だということである。委員会の配布資料には、(結論は Unicode とほとんど決まっているにしても) 今後他でも展開されそうな議論の論点が整理されており、とても参考になる。

この株式電子化小委員会においては、以下の三つの項目を文字コードに関する基本的な考え方として掲げていた。

• 漢字情報を含み、汎用性が高いものであること。
  → 規格化されたコード体系を採用する（独自コードの設定は行わない）。
• 株主の氏名等が適切に表現可能なものであること。
  → 広範な文字集合をカバーしたコード体系を採用する。
• 関係者の負担が、振替制度への移行に伴うコストの削減効果に見合うものであること。
  → 各社の社内システムにおける文字情報の取扱い実態を踏まえて判断する。

第2回 株券電子化小委員会 (2005年7月5日) 資料3-3 「振替機関の指定する統一文字コードの決定に係る基本的な考え方」より編集

まっとうな考え方であり、文字コードの事情を多少なりとも知っていれば、時期はともかくも Unicode への移行を容易に想到するだろう。しかし、当初は必ずしもそうではなかったらしい。

アンケートでは望ましい文字コードとして、汎用性の高さを理由に22社中8社が「シフトJIS」を挙げ、5社が「Unicode」を挙げている。

第3回 株券電子化小委員会 (2005年8月30日) 資料3 「統一文字コード案について」

シフトJIS派の方が当初は多数であった。冒頭で紹介した、「文字コードはシフトJISの拡張で済ませる可能性がある」という観測の出所は、こうして公開資料からも確認することができる。本気で「望ましい」と思っていたのか、あるいは移行コストを避けたい願望の吐露なのか、その辺の真意はよく分からない。いずれにせよ、既存技術志向の反映であるのは間違いないところである。

しかし、その同じ第3回の資料において、

仮に過渡期の対応として、「JIS X 0208＋α」案を統一文字集合として採用する場合であっても、将来の拡張性を念頭に置いた場合、文字コードについては、Unicode としておくことが適当と考えられるがどうか。

第3回 株券電子化小委員会 (2005年8月30日) 資料5 「統一文字集合及び統一文字コードについて（案）」

と、議論の方向性が言及されており、これ以降、文字コード (符号化方式) は Unicode ということになったようである。将来の拡張としては、JIS X 0213 にとどまらず、高島屋 (東証1部: 8233) の「髙」 (はしご高、U+9AD9) や、吉野家ディー・アンド・シー (東証1部: 9861) の「土」の下に「口」 (つちよし、U+20BB7) に対応するということも、Unicode の上で想定される。

ただし、Unicode 万歳とはいかない問題が、やはりここでも議論されている。

文字集合は「JIS X 0213」又は「JIS X 0213によって限定されたISO 10646中の日本語漢字」（※3）とすることでどうか。

（※3）「ISO 10646（UCS）」には2つの規格があり、実装済みのUCS-2では「JIS X 0213（JIS第一～第四水準）」のうち303文字が包含されない。一方のUCS-4では完全に包含される。

第3回 株券電子化小委員会 (2005年8月30日) 資料3 「統一文字コード案について」

UTF-16 で2バイト、UTF-8 でも3バイト以下に JIS X 0213 が収まってくれたならば、「JIS X 0213によって限定されたISO 10646中の日本語漢字」などという奇っ怪な選択肢を検討せずに済んだはずである。しかし現実には、303の漢字については1文字につき4バイトを使用する必要がある。(4月12日訂正: 4バイトの漢字数を302としていましたが、引用文の通り303が正しい数字でした。詳しくはコメント欄をご覧ください。安岡孝一さんご指摘どうもありがとうございました。)

結論としては JIS X 0213 完全対応を目指すこととなったものの、4バイトを忌避する議論は他所でもきっと展開されることだろう。あえてここで詳しく過去の議論を繰り返しはしない。しかし、JIS を中心とした文字コード規格行政の失敗がこうした事態を招いていることを、やはり指摘せざるを得ない。

画像掲載テスト＆記事予告

記事の予告をかねて、画像アップロードと掲載のテストをする。

(JIS X 0213 付属書4表9「一般記号」より引用)

JIS第3水準の「連こう (桁) 付き八分音符」「連こう (桁) 付き十六分音符」の字形例である。一見して、何か変だ。3通りの字形例が両方のコードポイントに記されてもよいようなものだが。安価なDTM (DeskTop Music) ソフトを使用しているおかげて、どうでもいいトリビアに気づいてしまった。

ともあれ、JIS X 0208 では「♪」「♭」「♯」しかなかった音楽記号が、JIS X 0213 ではいくつか補充されている。Unicode も調べてみたら、「本気でこんなの実装するのか?」というような仕様が規定されている (笑)。それらについては、また後日ということで。

Adobe の GB18030 対応

アンテナソフト (XML や PDF の関連ソフトを開発・販売している日本の会社) のブログ「PDF　千夜一夜」に、Adobe が GB18030 (中国の国家標準文字コード) に対応していないのではと疑問を投げかける記事 (PDF　千夜一夜: 2006年01月16日 「PDFと文字 (24) – Adobe-GB1, Adobe-CNS1, Adobe-Korea1」) があった。

しかし、これらはどうも古いですね。Adobe-GB1なんて2000年の日付になっています。それに肝心のGB18030がカバーされていません。Adobe -CN1、Adobe-Korea1いづれも2003年5月です。これに対して、Adobe-Japan1は2004年6月なので比較的新しいですが。中国や台湾ではアドビシステムズはあまりまじめにやってないのでしょうか？そんなことはないと思いますが。分かりません。

(PDF　千夜一夜: 2006年01月16日 「PDFと文字 (24) – Adobe-GB1, Adobe-CNS1, Adobe-Korea1」)

GB18030 は法的拘束力を持つ国家標準であるのに、さすがにそれはないだろうと思い、原文 ("Adobe-GB1-4 Character Collection for CID-Keyed Fonts") を当たってみた。

1 Introduction

This document describes the Adobe-GB1-4 character collection which supports the Chinese GB 2312-80, GB 1988-89, GB/T 12345-90, GB 13000.1-93, and GB 18030-2000 character set standards.

(Adobe Systems, "Adobe-GB1-4 Character Collection for CID-Keyed Fonts", Adobe Developer Support Technical Note #5079, 2000, p.1.)

いきなり1ページ目の introduction の冒頭から、GB18030-2000 をサポートしていると書かれている。Adobe-GB1-4 が2000年の日付となっているのも、GB18030 に合わせた改定だと解釈すれば、むしろ自然に思われる時期である。

一般に、GB18030-2000 対応と言えば、GB2312、GBK との互換性を保った上で、Unicode 3.0 (ISO/IEC 10646-1:2000) の文字集合 (のうち主にCJK統合漢字と拡張A) に対応していることを指しているはずである。どうも、当該ブログの筆者は、

The major part of Supplement 4, CIDs 22428 through 29058, provides characters to cover the Unified Han Ideographs Extension A, as listed in Unicode Version 3.0/ISO 10646-1:2000.

(Adobe Systems, "Adobe-GB1-4 Character Collection for CID-Keyed Fonts", Adobe Developer Support Technical Note #5079, 2000, p.3)

という記述が実質的には GB18030 対応を意味していることを見落としているように思われる。

ところで、Microsoft の GB18030 対応パッチ (GB18030 Support Package) を当ててみると、このパッチには漢字だけでなく、アラビア文字やイ文字も含まれていることが分かる。GB18030 には、Unicode の文字集合をそのまま収録するためのコードポイントが用意されていて、そうした文字を必要に応じて扱うことができる。

そこでふと疑問に思ったのは、そうした (中国における) 少数民族のフォントも国家標準なのだろうかということである。もしもそうであるなら、そうした文字のフォントも中国の検査機関の審査を通る必要がある (詳しい事情はダイナコムウェア「中国新文字コード規格 GB18030」 などを参照)。もしや英数字も？などと妄想が膨らんでしまうところだったが、そうした疑問への答えは、フォントの審査に関する以下の規格名にあった。

GB/T11460-2000 信息技术汉字字型数据的检测方法

「汉字」、つまりあくまで審査の対象は漢字である。そして、前述した Adobe のドキュメントには、次のように書かれている。

The typeface used to illustrate each character in this section is STSong™ Light, a product of Changzhou SinoType Technology Co., Ltd. STSong Light is certified by the Press and Publication Administration of the People’s Republic of China, the China State Language Commission, and the National Typeface Committee; and is recommended for use in official and professional publications.

(Adobe Systems, "Adobe-GB1-4 Character Collection for CID-Keyed Fonts", Adobe Developer Support Technical Note #5079, 2000, p.3)

ここで "this section" とは、"2 The Adobe-GB1-4 Character Collection" のことであり、Adobe-GB1-4 に収録されている文字集合の全体を指す。書体として STSong Light を使用し、それは中国の各当局から認証 (certified) されているとのことである。かくして、Adobe が GB18030 (とその関連規格) に対応していることを再確認できる。

小形克宏さんからレビューを頂いた

先月気づいたのだが、勤め先の大和総研で執筆、掲載していた、「漢字文化圏における文字コードの過去・現在・未来」というレポートに、小形克宏さんのブログ (もじのなまえ) でレビュー (「キャラクターセットの情報交換からグリフセットの情報交換へ」) を頂いていた。

小形克宏さんは、INTERNET Watch の連載企画「小形克宏の「文字の海、ビットの舟」―― 文字コードが私たちに問いかけるもの」で知られる方である。そもそも、私はこの方に触発されてレポートを書いたようなものであり、レビューを頂けたこと自体、本望である。当のレポートについては、立てた主題の壮大さと比して、時間もページ数も私の能力もいささか不足し、個人的には少々消化不良で終わってしまった感がある。それでも言いたかったことはそれなりに伝わっていたようで、評価して頂き大変うれしく思った。どうもありがとうございます。

以下、いくつかコメント。

それから文字についてスッキリ視点が整理されていることも特徴。今まで僕はグリフ（Glyph）*1をJIS X 0208などにおける「字体」と、本当に同じに考えてよいのかためらっていましたが、この文章ではきっぱり同じに定義しており、僕としては「そっか、これでよかったんだ」と力を得ました。となると、グリフを包摂したものが文字コード規格の「キャラクター」（正確には制御文字を除いた図形文字）であるということになりますね。こうすればAdobe-Japan1-5なんかのグリフセットを、JISなどのキャラクターセットと同じ文脈で論じ分けることができます。おお、一歩前進だ。

(もじのなまえ - キャラクターセットの情報交換からグリフセットの情報交換へ)

「グリフ (glyph)」と「字体」について、当のレポートでは、「きっぱり同じに定義」ではなく「同義と見なす」とした (PDF の28ページ)。小形さんと同様に私もかなり迷い、最終的には、レポートの脚注にも記した情報処理学会・情報規格調査会「文字コード標準体系専門委員会報告書」（2002年）  におおむね倣った。この報告書には以下のように記されている。

– 字体 (glyph)
文字の抽象的な形 (骨格) の概念で、文字の骨組みなどともいわれ、具体的に視覚化することは不可能である。(ISO/IEC TR15285、国語審議会資料などから。) 本委員会では、漢字部首も符号化文字に含まれる、という立場から、部首にも“字体 (glyph)”が存在すると考える。

(情報処理学会・情報規格調査会, 「文字コード標準体系専門委員会報告書」 p.69, 2002.)

つまり、「字体」の英訳自体が「glyph」となっている。漢字の議論をする際には、これが適切だろう。そうすれば、(漢字の議論において) 「文字コード」と「グリフセット」を、字体包摂の有無によって明確に区別可能となり、議論がしやすくなる。小形さんのご指摘の通りである。

ただ、たとえばアルファベット2文字の「fi」が uniscribe によって一つのグリフとして扱われるということはあるし、「字体」と「glyph」は、一般的な定義としてはまったく同じではないのだろう。あくまで当レポートにおいては差し支えない、ということで、「同義と見なす」とした。「見なす」というのは、法律などで多用される、便利な表現である (濫用は禁物だろうが・・・)。

なお、参考文献として小形さんの連載 (「文字の海、ビットの舟」) を挙げさせていただいたことについて、現在は URL が変更されているとのご指摘を頂いた。勤め先の担当者に連絡して訂正させて頂いた。ご推察の通り、昔から拝読しています。連載の今後に期待しています。

lang 属性をつけて再テスト

普段は Web ブラウザとして Firefox を使っている。Firefox では UTF-8 の Web ページに中国語の簡体字が混じっていても、文字化けせずに表示される。しかし Internet Explorer では文字化けしてしまった。span タグを挿入し、lang 属性を zh に指定して、以下再テスト。

你们好。我叫小川创生。 (lang="zh" と指定)
你们好。我叫小川创生。 (xml:lang="zh" と指定)
你们好。我叫小川创生。 (lang 指定無し)

試しにブログを書いてみる

トラックバックをかけて実名で記事を書いてみたくなることが時々あり、これからもありそうなので、試しに始めてみることにする。

始めるついでに、せっかく UTF-8 のブログサイトを意識して選んだのだから、以下、中国語の出力テスト。

你们好。我叫小川创生。
Hello.  My name is Motoyuki Ogawa.