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

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

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

• 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.