XMLフロンティア探訪
第2回 XMLで解決する外字問題

名前や地名などには、あらかじめ用意されているフォントでは表示できない文字がある。これを解決してくれるのが外字だが、この外字の利用はさまざまな問題がからんでいる。XMLなら外字の問題は解決できるのかというと、どうも話はそう単純ではない。（編集局）

川俣 晶
Advanced IT School 学長
2001/6/27

今回の主な内容 あっさり発生する外字問題 「外字」とは規格に存在しない文字 外字問題の解決方法とは 目的の文字が検索できない 現実的な解決方法 XMLか、それともプレーンテキストか 大規模文字指定のデファクト「今昔文字鏡」 XMLによる画像参照交換方式 文字でなく画像として扱う 外字問題は、本当にこれでよいのか？ 外字をなくす選択肢もある

■あっさり発生する外字問題

　データや文書をパソコンに入力しているとき、いくら探しても入力したい文字が出てこないことがある。こんなときは、外字エディタを用いて自分で文字の形を作り、これを入力して使う。これが一般的な利用者から見た「外字」である。

　この外字が問題を起こすのは、それが利用者個人が作り出した完全にプライベートな存在であるからだ。例えば、外字を使った文章を電子メールを用いて送信したとしても、電子メールを受け取った相手は外字を正しく見ることはできない。外字は送信者のパソコンに登録されただけで、受信者のパソコンには登録されていないからだ。

　この問題は、決して遠隔地のパソコンにデータを送る場合にだけ起きるわけではない。隣のパソコンにフロッピーディスクで文書ファイルを持っていっただけでも、あっさりと発生するのである。

■「外字」とは規格に存在しない文字

　もっと専門的に見てみよう。外字という言葉の正確な意味は、内字ではない文字、ということである。内字とは、「何らかの文字集合に関する規格に収録された文字」を意味する。従って、どの文字集合の規格を前提にするかによって、外字の定義は変化することになる。例えば、半角文字として使われることが多いJIS X 0201を前提とすると、カタカナは内字だが、すべての漢字は外字ということになる。しかし、同じJIS規格でもJIS X 0208を前提とすれば、第1水準、第2水準の漢字は内字である。

　つまり、ユーザーが外字エディタで作った文字だけが外字なのではなく、規格に存在しない文字はすべて外字なのである。

　ここで1つ注意が必要だ。実は、多くの人に外字だと思われている文字の中には、専門的な定義によると外字に該当しない、というものがある。もちろん、「探している文字がない」と思い込んで外字を作ったが、実は第2水準にあった、というのであれば笑い話だが、そういうことをいいたいわけではない。実は、規格では、包摂というルールを定め、同じ文字に微妙に異なる複数の書き方がある場合には、それを同一の文字と見なす、ということが行われている。例えば、はねる方向や、点の数など、微妙な見かけ上の差を持つ文字がある。しかし、それは表記の違いであって文字の意味が違うわけではない。特に、人名漢字などに、このような例が多く見られる。そのことから考えると、一般の方々が「ない」と思った文字の多くは、実は規格に含まれていることが多い。ただ、意図したとおりの文字を表示させることができないため、「ない」と思い込んでいるにすぎない。

　では、規格に収録されているのに表示できない文字とは、いったい何だろうか。それは、フォントをデザインするときに、デザイナーによって選ばれなかった文字と言うことになる。微妙に異なる複数の文字に1つの文字コードを割り当てるわけだから、基本的に、それらの文字の中の1つだけを選んでフォントとして含めることになる（複数をフォントに含める技術もあるが、まだ一般的ではない）。

　以上をまとめると、外字問題がどのようなものか、見えてくるだろう。

• 規格に収録された文字種類が足りない問題
• 規格に収録された文字だが欲しい形がフォントに入っていない問題

　この2つは、まったく異なる性格を持つ問題である。これまで、両者が混同されることが多かったのは残念であるが、見て分かるとおり、原因が異なる以上、処方せんも異なってくる。

■外字問題の解決方法とは

　規格に収録された文字種類が足りないという問題を解決することは簡単である。要するに、収録する文字種類を追加すればよい。問題は追加できるだけの枠が残っているかどうかである。現在主流になりつつあるUnicodeでは、約100万文字の枠があり、しかも枠はほとんどガラガラである。世の中にある、あらゆる文字を入れても足りるのではないかといわれているぐらいなので、おそらく日本で必要とされるあらゆる漢字を入れてもお釣りがくるだろう。この件に関しては、単純に何を追加すべきかを確定し、追加の手続きを行うだけでよい。追加対象を確定させる議論は混迷する危険もあるが、それさえ乗り越えれば、それほど込み入った問題というわけではない。

　問題は、規格に収録された文字なのに、その文字の欲しい形がフォントに（例えば「MS明朝」などに）入っていないという方である（「斉藤」さんの、微妙に異なる「斉」の字がないなど）。これは、厳密にいえば、文字の問題というよりも、フォントの問題である。最も簡単な解決方法は、自分が出したい文字の形を収録したフォントを手に入れて、それを使うことである。これで、思いどおりの文字を表示、印刷することができる。

　しかし、これで万事解決とは行かない。なぜなら、この方法には重大な欠陥があるためだ。まず、使用したいフォントがインストールされていないシステムにデータファイルを持っていくと、意図した通りに表示されなくなる。さらに、フォントを自由に切り替えられないソフトでは、そもそも、このテクニックを使うことができない。

■目的の文字が検索できない

　他にも問題がある。それは検索にかかわる問題だ。ある人名のちょっと特殊な「斉」の字が、フォントAとフォントBに収録されているとしよう。このとき、技術的には「フォントAで指定されたある文字」を検索することはできるが、この条件ではフォントBにも同じ文字があるのに、それは無視されてしまう。さらに、フォントはフォントベンダが自由に開発するものだから、同じ文字を含むフォントCやフォントDが存在するかもしれない。ところが検索時にそれらのフォントの名前を知らねば、そもそもそれを指定した検索を行うという考えが浮かぶはずもない。しかし、インターネットなどでごっそり集めてきたファイルに対して検索する場合は、そこで指定されているすべてのフォントに精通することなど、できるはずもない。

　HTMLのスタイルシートであるCSSを用いると、フォントをダウンロードさせ表示させることはできるので、この技術を使えば、異なるパソコン上でのフォントの表示も印刷も再現可能になる。しかし、相変わらず、検索条件に使えるような、フォントAのある文字とフォントBのある文字が同じかどうかを判断する根拠は提供してくれない。

■現実的な解決方法

　このような問題を解決するには、よりきめ細かい文字の指定方法が必要とされる。1つのアイデアは、もう一度文字コードを振り直して、どんな細かい文字の違いにも異なる番号を割り当てることだ。しかし、この方法はまったく現実的ではない。日常生活において、それほど細かい文字の分類を必要とすることはない。要するに、意味が分かればよいのである。むしろ、そのような選択は苦痛の増大をもたらす。例えば、「斉藤」という名前を探すときに、全国に無数にある微妙に異なる「斉藤」という文字の中で、探したい人の「斉藤」がどれかをいちいち確認しないと検索もできないようでは不便極まりない。しかも、文字を細かく分類して処理するということはコストアップ要因である。あなたは、どこのだれかも知らない多くの人たちが使っている、素人目には区別がつかないような微妙な文字の違いを再現するために、パソコンが値上がりすることを容認できるだろうか？

　もう少しだけ現実的な解決策は、現在の文字コードはそのままにしておき、それに微妙な文字の形の違いを表現する補助的なコードを追加記述する方法である。この補助的なコードは読み飛ばすのも容易であり、より現実的な解なのだが、それでもシステムの構造に与えるインパクトは大きい。つまり、これまで文字列を表現する最もシンプルな方法であったプレーンテキストに、より複雑な構造を持ち込むことになり、抵抗感を持つ者も多い。

■XMLか、それともプレーンテキストか

　このような考え方が出てくる背景には、構造を持ったデータを記述する優れた標準の出現がある。つまり、それがXMLである。XMLは、リッチなプレーンテキストと呼ばれることもあるぐらいで、現在プレーンテキストが担っている役割の一部を継承していくことが確実視される。つまり、プレーンテキストに複雑な構造を持ち込むのではなく、もともと複雑な構造を記述する許容力のあるXMLを使えばよいではないか、というアイデアが生じる。このような、プレーンテキスト上で実現するか、あるいは、XML上で実現するかという対立が起きているのは、ここで紹介している文字の問題に限らない。言語を指定する「言語タグ」や、文字に添える小さな文字であるルビを記述する「ルビタグ」などでも、同じような考え方の対立が存在する。

　対立が生じる理由は、主に、何が標準なのかという考え方の違いによると考えられる。つまり、プレーンテキストの拡張（つまり文字コードへの機能追加による問題の解決）で問題を解決しようと主張する者たちの世界観では、XMLとはいくつもある応用技術の1つにすぎない。XMLでしか利用できない解決手段を用意したところで、ほかの技術のためには同じような手段をいくつも準備する必要が生じるだけである。これは、あまりに無駄な手間であり、もっと根本的なところで対策を打つべきだと考えるわけだ。一方、XMLによる解決を主張する者たちの世界観では、XMLは次世代のプレーンテキストであり、世の中がXML時代に入れば、XMLによる解決はすべての問題を解決する、と言うことになる。

　筆者は、後者の意見を支持している。現在の勢いからすれば、XML文書がプレーンテキストのようにありふれた存在になる未来は避けようがない。どこにでもあるXML文書で簡潔に表現できる機能なら、無理にプレーンテキストで実現する機能を付け加えることにメリットはないと感じるためだ。しかし、XMLについて詳しい知識や経験を持たない者達の間では、まだまだXMLによる解決に懐疑的な意見が根強い。

■大規模文字指定のデファクト「今昔文字鏡」

　文字集合の規格の範囲を超えた文字を指定するためには、それぞれの文字に何らかの識別用の番号や名前を付けねばならない。表示や印刷を行うだけならフォントの問題だけで済むことはすでに述べたとおりだが、その枠を踏み出そうとすると、全世界でたった1つの固有の番号や名前を付ける必要が生じる。現在、その目的のために使用されデファクト・スタンダードとなっているのが、「今昔文字鏡」という漢字検索システムである。このソフトは、漢字をはじめ研究用の古代文字など9万種類の文字に対して、固有の文字鏡番号というものを割り当てている。この文字鏡番号を用いて、いわゆる外字を指定するようにすれば、制限なく相互にコミュニケーション可能な文書を作成できる。つまり、同じ文字鏡番号が指定されていれば、だれでも同じ文字だとその番号から判断できるのだ。

　実際に、文字鏡番号は大蔵省（当時）による官報のXML化などで利用された実績がある。

■XMLによる画像参照交換方式

　では具体的に、XMLを用いて外字問題をどう解決するのか具体的なところを見てみよう。より具体的に分けると、3つの機能が必要とされる。

• 文字（の画像）に固有の名前を付ける
• XML文書中で固有の名前を指定する手段を標準化する
• 固有の名前から表示情報を得る方法を標準化する

　指定されたフォントに関係なく、同じ文字を同じ文字と見なす判断の根拠を提供するために、すべての文字には固有の名前を与えることにする。ここで重要なことは、文字コードという数値ではなく名前を使うことである。名前とはつまり文字列である。文字コードの世界とはまったく独立した別の世界を作ることによって、文字集合に関する各種規格の規定と競合することはなく、別の規範を持ち込むこともできる。また、ここでは「文字」に固有の名前を付けるとしたが、すでに説明したとおり、より正確に一般ユーザーのニーズを反映するなら、ここは「文字の画像」とすべきところだ。

　このコンセプトに基づき、拡張漢字処理協議会（XKP）が2000年7月28日に採択したものが、XKP GAIJI交換仕様書である。これにより、同協議会が名前の登録を受け付けるとともに、この仕様書で、「XML文書中で固有の名前を指定する手段」と「固有の名前から表示情報を得る方法」に用いる言語(XMLによる)を定義した。とはいえ、名前の登録を受け付けるといっても、実際には文字鏡番号のみを使用することが暗に想定されていた。

　この仕様書を、日本規格協会 情報技術標準化研究センター（INSTAC）に設立された次世代ネットワークの標準化に関する調査研究委員会が、徹底的に検討を加えたうえでテクニカルレポート（TR）化したものが、「標準情報(TR) TR X 0047:2001 XMLによる画像参照交換方式」である。

　TR化する際に、非常に大きく変化したことが2点ある。

• 文字用という制限を外して画像全般を意図した
• 名前を付けるルールにISO/IEC 10036を採用

■文字でなく画像として扱う

　最初の点は、この技術仕様が文字以外にも活用可能であることによる変更である。もちろん、最初の仕様書でも、「文字」ではなく「文字の画像」を扱うことが明示されていたが、このTRでは「文字の画像」とすらいわず、ただの「画像」である。文字以外でも共有されるシンボルは、この言語を用いて指定する余地がある。例えば、トイレのマークなど、社会全般で共有される画像を、膨大な情報の蓄積の中から検索して抽出するために、このTRを利用しうる可能性がある。

　2番目の点は、少しだけ長い説明を要する。そもそも、SGMLの世界には「公開識別子」と呼ばれる、名前を登録する標準手続きが存在する。ここに登録された名前は、世界でたった1つしかないもので、世界のどこに行っても意味が1つに定まる。公開識別子の利用目的は多いが、その中の1つが、フォント関連のオブジェクトに付けられる名前である。その登録手順を定めたものが、ISO/IEC 10036:1996, Information Technology -- Font information interchange -- Procedures for registration of font-related identifiersである。

　このような手順が存在する以上、当然、SGML文書からここで登録された名前を参照する手段は存在する。また、SGMLの後継言語という位置付けのXMLから参照することも不可能ではない。にもかかわらず、新しいTRを作成しなければならなかった理由は、これらの名前を指定するために一般的に使われる記法（notation）という機能が、XMLでは一般的に使われない機能であるためだ。記法は、DTDの内部で指定するものなので、整形式（well-formed）なXML文書では原理的に利用不可能である。そのため、記法は使わないのがXML界の一般的な状況である。ということは、XML文書からSGML公開識別子を参照することは不可能ではないが、実用的に使うことを考えれば、ほかの方法が必要となるのである。そこで、記法の代わりに属性を用いて指定する方法を用意することにした、これがこのTRの存在意義である。

　このTRが実用性を持つために必須要件となるのは、実際に利用される画像を1つずつ名前登録することである。何も登録されていなければ、登録手段だけあっても何の意味もない。そのために、別途、今昔文字鏡のすべてをISO/IEC 10036の手順によって登録作業中である。

　このTRを用いてXHTML文書の中に画像識別情報を埋め込んだ例を以下に示す（TR掲載の例より引用。xpr:name属性の値はダミー値）。

1:　<body xmlns:xpr="http://www.xml.gr.jp/PRE/Reference"     2:　<p><img xpr:name="ISO/IEC 10036/RA//Glyphs:123456789     3:　src="http://www.mojikyo.gr.jp/gif/003/003290.gif     4:　alt="吉(上が土)" />田茂は昭和21年より5次に渡る内閣を組閣した。</p>     5:　</body>

XHTMLの中に、画像識別情報を埋め込んだ例

　見て分かるとおり、xpr:name属性を無視すれば、何の変哲もないXHTML文書（の一部）である。つまり表示や印刷だけなら、xpr:name属性を無視するだけで通る。厳密な画像の一致判定を行う必要がある場合は、xpr:name属性を調べることで、上が土になった「吉」が使われているかどうかを判定できることになる。

　「標準情報(TR) TR X 0047:2001 XMLによる画像参照交換方式」は日本規格協会に注文すれば入手できる。TR作成作業の便宜のために公開されているテキストもあるが、正式なものは紙媒体で出版されるものである。

■外字問題は、本当にこれでよいのか？

　話を外字問題の原点に戻そう。誤解されている人もいるが、アメリカには外字は存在しない。外字という概念もない。外字エディタというソフトは日本では必須とされるが、アメリカには存在しない。中国などで必要とされる場合もあるので、まったく日本だけの独自機能というわけではないが、外字エディタの存在が、世界の中で特殊な事例であることは間違いない。

　しかし、漢字圏なら必ず外字が必要とされるかというと、必ずしもそうではない。政府が強い自国語政策を持っている場合には、外字のない世界があり得る。つまり、利用可能なすべての文字を政府が定め、それに反するものは一切認めないという立場である。

　つまり、外字というものが一般的に使われる社会というのは、以下の条件を満たしているということになる。

• 自国語を厳密に1つにするだけのコンセンサスが得られていない
• 中央政府が国内の言語を強制する力を持たない。あるいは行使しない

　ここで、しっかりと把握しておく必要があるのは、外字がある社会というのは決して当たり前ではないと言うことである。外字を使う社会に進むか、それとも外字のない社会に進むかは、日本人が自分たちが利用する言語の在り方として、選択する余地を持っているのである。では本当に外字は必要なのだろうか？ ここで、3つのニーズをはっきり分けて考ええる必要がある。

• 日常的なメモ（電子メールなども含む）
• 公的な拘束力を持つ文書
• 文化的な文書

　まず、最初のものに関しては要するに通じればよいのだから、外字がなくてもそれほど困らない。むしろ、余計な文字を利用可能にするために、コストアップしては迷惑になる。2番目は、日本では人名にこだわる人がいるので、外字抜きには実現できない。3番目も、過去の文書をあるがままに後世に残すためには、外字が必要とされる。

　ここで着目すべきことは2つある。1つは、外字などなくても安上がりな方が好まれるニーズもあれば、外字なしではどうにもならないニーズもあるということだ。つまり、たった1つの解決方法ですべての問題を解決しようとすることは建設的ではない。

　もう1つは、「公的に拘束力を持つ文書」、例えば契約書のような書類を作成するにあたって、外字が必要とされることに着目する必要がある。つまり、政府や司法機関などが、個人レベルの「この文字は私の名前の文字ではないから、この文書は無効だ」という主張を認めてしまっているのである。このことの是非は問わない。しかし、このような態度が、システム全体のコストアップを招いていることは事実である。例えば、請求書に記載された名前の文字がわずかでも違っていると受け取らないという人もいるそうだ。もちろん、そんなわがままな人はほんの一握りだろうが、その「ほんの一握り」の人たちのために、外字機能が必要とされ、日本全体で多くのコストを余計に払っているのである。

■外字をなくす選択肢もある

　1つの選択として、政府が公的な文書で使用してよい日本語の文字表を定め、そこで示された文字を使っていれば法的な拘束力が発生すると決めることはできる。これは、決して文化の否定ではない。文字を自由に使う権利を奪うことではない。ただ、法的な拘束力が発生する条件を狭めるだけである。しかし、たったそれだけのことでも、日本国内で必要とされる情報化コストを減らす効果が期待できる。

　先祖伝来の名前を守り続けることが日本の未来のためなのか、それともコストダウンのために思い切った文字改革を行うことが日本の未来のためなのか、何が正しいかは分からない。しかし、現在の日本人は、選択権を握っているのだということは事実である。選択は日本人が全体で下すべき性格のものである。だが判断は総合的に行わねばならない。コスト意識を欠いた理想論では、現実のシステムを円滑に稼働させることはできないのである。

（次回は7月下旬に公開予定です）

「連載 XMLフロンティア探訪」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）