小は大をかねるか？

１．誤解していたこと

２．小文字セットと大文字セット

３．文字包摂の問題点

１．誤解していたこと

　ほら貝に「文字コード問題」特設ページを開設したのは、昨年（1996年）9月のことだったが、今にして振りかえると、誤解や不適切な見方がすくなくなかった。

　事実関係の間違いについては、そのつど記述を直してきたが、全般的な考え方については誤解を訂正する機会がなかったので、ここに、現時点（1997年10月）における文字コード問題の展望を書いておきたいと思う。

　昨年 9月時点では、マイクロソフト社の推進するUnicode 対 坂村健氏のTRONコードという図式にとらわれ、JCS委員会（JIS原案調査委員会）は Unicode推進側と思いこんでいたが、この見方は誤りだった。

　また、Unicodeの文字種の上限が 6万5千字余（16bit）で、拡張の余地がまったくないと即断したのも間違っていた。ユニコード・コンソーシアムは、16bit平面に全世界の文字を収用するという理念が維持できないことを認め、サロゲートペアによる泥縄的な拡張（111万字余に増える）を設計に追加していたからである。今更こんな泥縄の追加をおこなって、ISO 10646制定時のごり押しはなんだったのかという思いは残るが、文字数が限られているといって Unicodeを批判するのはまとはずれだ。

　マイクロソフト社であるが、Unicode推進派の有力なメンバーにはちがいないが、日本で Unicodeの普及をはばんでいる最大の障害が、同社の OS製品（MS DOS、Windows3.1、Windows95、WindowsNT）であるという面も見逃せない。

　MS DOSと Windows3.1、Windows95はシフトJISの世界にとどまっているし、WindowsNTは内部コードこそ Unicodeだが（フォントが JIS X 0208の範囲でしか用意されていないので、現状では JIS X 0208の範囲でしか使えない）、シフトJISを処理する機構をそなえており、大半のアプリケーションではいまだにシフトJISを使っている。WindowsNTベースのローカル・ネットワークでも、ホスト・プログラムによっては、シフトJISで動いている場合があるという。マイクロソフト社の市場支配がつづく限り、シフトJISは使われつづけるだろう。

　Unicode推進ということでいえば、反マイクロソフトとされる Java陣営の方が深く加担している。Javaで日本語をあつかうには、Unicodeを使うしかないからである。

　Javaでプログラムを書けば、パソコンからメインフレームまで、あらゆるコンピュータ上で動き、特定の OSによる市場支配がなくなるといわれているが、日本で Unicodeが主流となるのは、Java陣営がマイクロソフト社の Windowsファミリーを圧倒した時かもしれない。

　JCS委員会を Unicode推進側とする見方は今でもあるようだが、これは不適切だと考える。

　確かに、現委員長の芝野耕司氏は、Unicodeに乗っとられた形の ISO 10646-1を JIS X 0221として国内規格化した際の委員長であり、現在、ISO 10646の改訂を審議する ISO/IEC第97技術委員会第2小委員会の委員長でもあるが、JCS委員会が 1999年施行を目指して開発をおこなっている JIS X 0213は、ISO 2022にもとづく文字面切り換え方式も用意されているものの、基本的にはシフトJISの枠内で 足りない文字を整備しようという規格であって（だからこそ、あるパーセンテージまでは急速に普及する可能性が高い）、Unicodeとはライバル関係にある。

　芝野委員長は、補助漢字（JIS X 0212）に対して、「補助漢字は，間違った理解から生まれた間違った漢字表だと思います」と、激烈な批判を展開されておられるが、実はこれは Unicode批判なのである（Unicodeの日本漢字カラムは、JIS X 0208と補助漢字で構成されている）。JCS委員会は JIS X 0213という手ずから作った文字セットの普及を目指していると考えた方がよく、 Unicode推進派とは異なる立場をとっているという見方もなりたつ。

　最後に Unicode批判の動きであるが、TRONがすべてではない。Unicodeは ISO 2022系の文字コードを押しのける形で国際標準文字コードの地位を奪いとったが、Unixの世界では ISO 2022系で多国語環境（正確には多用字系環境）を整備しようという研究が、いくつかのグループによって、一貫して進められている。

　テキスト・ベースながら、Emacsから生まれた Muleは日本では Unixの標準エディタといってよいくらいだし、片岡裕氏を中心とする早大グループの「国際化・多言語化テキスト処理プロジェクト」では、X Windowを拡張して Muleに匹敵する多用字系（多スクリプト）環境を実現している。

　他にも、Windowsの地域コードを使って文字面を切り替える方式など、いくつかのプロジェクトが水面下で動いているようである。文字コードをめぐる状況は、かつてないほど混沌とした様相を呈している。

２．小文字セットと大文字セット

　では、現在の問題点はどこにあるのだろうか？

　一部でいわれているような、Unicodeでは文字数に制限がある云々という議論は、不適切である。サロゲートペアによって、Unicodeの文字種の上限は 111万字余に引き上げられているのである。111万字といえば、ISO 10646-2から 10646-17までの16面分をカバーできる広大なスペースだが、もし、これでも足りなければ、16bit×4（=64bit）のサロゲート・カルテットによる拡張がおこなわれるだろう（事実、サロゲート・ペアで拡張される最後の二面は「予約領域」とされている。将来、ここが拡張に使われるのだろう）。温泉旅館的な、行き当たりばったりの拡張ではあるが、コードポイントが足りなくなる心配はないといえる。

　JIS X 0213の場合も、コードポイントが不足することは、多分、ないだろう。1999年に登場が予定されている最初のバージョンは 5千字ほどで、JIS X 0208と合わせると 1万1千字余にしかならないが、将来的に、いわゆる半角カナを廃止することが検討されており、このスペースを転用すれば、シフトJISでも 1万数千字が増やせる。あわせて 2万数千字という字種数は、諸橋大漢和の 5万字の半分にすぎないが、包摂規準を適当に塩梅すれば、この枠内で日本漢字をすべてカバーすることも不可能ではない。

　だが、この包摂が問題なのである。包摂とはなにか？　JIS X 0213の解説では、次のように定義している。

　この規格では，一つの区点位置が複数の字体を区別しないことを"包摂"とよび，包摂を字体ごと（区点位置ごとではない）に定めた"包摂規準"を規定として設けることによって，この明確化を図った。（JIS X 0208:1997「解説 3.7.3.2」）

「包摂」というと、包みこむというニュアンスであるが、英語では Unification、つまり「統合」である。JIS X 0208は、複数の字体を一つのコードポイントに統合すると宣言しているのである。

　もちろん、字形のゆれを、ある範囲で許容することは必要である。「高」と「」、「」は、グラフィックデザインや書籍のレイアウトといった特別な場面以外では、慣習的に同一の文字と受けとられている。そうであれば、「高」、「」、「」は、単なる書体の差、あるいはデザイン差として、同一のコードポイントに包摂してかまわないし、またそうすべきだ。

　だが、「高」と「」の違いは、慣習からいって、有意味な違いと見なされることが多い。特に人名においては、「高嶋」と「高嶌」が異なるように、「高嶋」と「嶋」は異なるのである。「高」と「」の差は、書体の差やデザインの差ではなく、字体の差である。

　JIS X 0208の 97年改正が包摂規準を明文化した点は評価したいが、デザイン差のレベルの包摂ではなく、字体レベルの包摂をおこなった点に疑問をおぼえざるをえない。

　Unicodeの乱暴な漢字統合を補正するために、ISO 10646-1制定にあたってつくられた CJK統合漢字では、字体レベルの包摂はしないとしているが、実はいっそう問題のある「包摂＝統合」をおこなっている。中日韓台の漢字文字セットをひとまとめにした Han Unification（統合漢字）である（「統合」も「包摂」も、英語ではともに Unification）。

　用字系（スクリプト）レベルでの包摂＝統合は、字体レベルの包摂＝統合よりもたちが悪い。現代中国漢字の用字系、日本漢字の用字系、韓国漢字の用字系は、等しく古典中国漢字に淵源しているとはいえ、歴史的に異なる発達をとげてきた。同じルーツを持つ漢字でも、意味が異なるだけでなく、字体の体系も異なれば、デザインのバリエーションの範囲もかなりずれてきている。そうした固有の歴史を背負った用字系を、16bitの枠内に世界中の文字を収用するという実現するはずのない理想（妄想）のために、ひとつにくくってしてしまえというのである。次の版ではシンガポール漢字とベトナム漢字（字喃）の用字系まで統合するという。

　字体の統合や、用字系の統合をおこなえば、必要なコードポイントを数分の一に減らすことができる。CJK統合漢字では、中日韓台の公的規格に収められている漢字のべ 54015字が 20902字に圧縮されている。規格票には、中台日韓の字形が四欄併記の形で例示されているが、ISO 10646-1を国内規格化した JIS X 0221の解説には、「統合した各欄の文字を異なる文字と認定していないし、区別して使用することも意図していない」と明記してある。

　まとめる（unifyする）とは、もとの文字の情報の一部を切り捨てることでもある。切り捨てた方がよい場合もあるが、困る場合もある。

　手書き原稿から活字に移す際も、多くの情報が切り捨てられる。手書き原稿には書き手の癖があらわれ、見る人が見れば、体調、気分、年齢までおしはかれるかもしれない。活字では、こうした情報は失われる反面、悪筆に苦しむこともない。筆跡情報が捨象されるからである。

　手書き原稿や活字から電子データに移した場合、JIS X 0208:1997では字体情報が失われる。3962h、あるいは8B67hというコードポイントだけでは、「高」なのか「」なのか、「吉」なのか「」なのかはわからなくなる。Unicodeでは、日本漢字であるか、中国漢字であるか、韓国漢字であるかすらもわからなくなるのである。

　次に例示する文字をご覧いただきたい（GIFアニメ対応のブラウザで見てほしい）。

　 　 　

JIS X 0208:1997の包摂規準に従って、究極のフォントを作ってみたのだが、いかがだろうか。電子インクが実用化すれば、この究極のフォントで印刷物を刷れるようになり、JISマークがつくだろうが、こういう印刷物ははぞっとしない。

　JISや Unicode側では、字体レベル以上の包摂をおこなっても、フォント名指定で字体を特定すればよいと考えているようである。文字コードは複数の字体をふくむ粗い網の目にとどめておき、個別の字体は文字コート＋フォント名であらわすわけだ。この立場を小文字セットと呼ぼう。

　それに対して、個別の字体ごとにコードを割り当てていくという立場もある。字形を分類する網の目が密になり、コードポイントが増えるので、大文字セットと呼ぶことにする。

　現在の文字コードをめぐる論点は、結局、小文字セットを選ぶか大文字セットを選ぶかの問題に集約されると考える。従来いわれてきた、文字種が多いか少ないかという議論は、字体を切りわける網の目が粗であるか、密であるかという観点からとらえ直すべきである。

３．文字包摂の問題点

　異体字がたくさんはいった大文字セットでは、検索が困難になるという意見がある。「高嶋」か「嶋」かわからない場合があるし、「嶋」が「高嶋」と誤表記されている場合もあるので、「高嶋」と「嶋」で二回検索しなければならないというわけだ。

　しかし、データベース関連技術の一つに、シソーラス検索（同義語検索）がある。「高嶋」を検索する際、異体字シソーラスで「嶋」を自動的にわりだし、「高嶋」と「嶋」を同時に検索するというものだ。もちろん、「高嶋」ないし「嶋」だけを検索したければ、通常の検索をおこなえばよい。大文字セットの密な網の目の上に、異体字シソーラスによって、粗な網の目を一時的にかぶせると考えればよいだろう。

　この関係を表で示すと、次のようになる。

　最近の日本語IME（仮名漢字変換ソフト）は、複数の辞書を併用したり、ユーザー辞書を分離したりしているが、シソーラス辞書も、複数辞書引きや、自分専用の同義語を定義したユーザー辞書の作成が可能である。

　JIS X 0208:1997の包摂規準に準拠した異体字シソーラスも作れるが、使い勝手はあまりよくないだろう。JIS X 0208:1997の包摂規準では、「辺」、「邊」、「邉」は別字とされている。「龍」と「竜」も包摂されていない。「龍」と「竜」、「辺」、「邊」、「邉」を同値とする、JIS X 0208:1997よりも粗い網目を提供するシソーラスがあれば、一回の検索ですむ。シソーラスは元のデータを改変するわけではないのだから、粗さの段階の異なる複数のシソーラスを用意し、用途に応じて使いわければ便利だろう。大文字セットは小文字セットをかねるのである。

　シソーラスは、異体字だけでなく、用字系間でもつくれる。Unicode推進派は、ISO 10646の乗っ取りを強行した際、ISO 2022系や DIS 10646では、同じ漢字に、中台日韓で別のコードをふることになり、検索が困難になるから、漢字は統合して同一の国際共通コードをふるべきだと主張した。これに対して、DIS 10646を擁護していた日本は、多用字系シソーラスを提案したという。

　多用字系シソーラスを実装すれば、「毛沢東」を検索する際、中国漢字、台湾漢字、日本漢字、韓国漢字の「毛沢東」のコードを自動的にわりだし、一度に検索できるわけである。多用字系シソーラスは、各国の異体字シソーラスを統合するわけであるから、数十万字規模の漢字の同値関係を網羅した大規模なものになる。1991年の時点では、そんな辞書は経済的に実装が困難だったが、現在のハードウェアなら十分に可能であろう。

　Unicodeの検索における優位性はすでに失われたといってよいが、現在では用字系の特定をフォント名に依存した点が欠陥として浮上してきている。「ＭＳ明朝」とか「」、「」とフォント名を指定することによって、日本漢字か、中国簡体字か、中国繁体字かが特定できるが、すべてのマシンに同一のフォントがはいっていなければ、どの国のどんな用字系かがわからなくなってしまうのだ。

　小といい、大といっても、所詮、相対的な問題にすぎないという見方があるかもしれない。実際、JIS X 0208ではすべての異体字が統合されているわけではない。「壷」と「壺」、「辺」と「邊」、「邉」のように、複数の字体が別々にコード化されている例がすくなくないのだ。その一方、大文字セットの代表である「今昔文字鏡」や東大明朝でも、はねや起筆、はらいの相違まですべて網羅して、JIS X 0208:1997でいうところの別字体としているわけではないようだ。どこまでがデザイン差で、どこからが字体差かの境界は曖昧である。とすれば、小文字セットと大文字セットを区別すること自体がナンセンスということにならないだろうか？

　そうではあるまい。デザイン差と字体差の間の境界線は、慣習にもとづいて引かれるべきものである。慣習というと、明文化できないあやふやなものと受けられるかもしれないが、人間の言語自体、慣習にもとづいて成立した差異の体系である。

　慣習には幅がある。デザイン差と字体差の線引きについても、年齢や教育水準、その人の必要にしたがって（「渡邊」という姓の人は「辺」の字形に敏感な傾向があるようだ）、かなりのゆれがあることはいうまでもない。漢字の字形を判別する網の目には、さまざまな背景に応じて、ある程度の粗密が見られるのである。

　わたしは文字コードは、できるだけ密な網の目にもとづいて作られるべきだと考える。つまり、大文字セットの文字コードを支持する。粗な網の目でつくられた文字コード（小文字セット）では、失われる情報が多いからだ。「高」と「」を区別しない文字コードでは、ある人が「高嶋」氏であるか、「嶋」氏であるかはわからなくなる。フォント指定で「嶋」としても、アプリケーション間でデータをやりとりしているうちにフォント情報がとれてしまえば、「高嶋」にもどってしまう。文献の保存でも同じことがいえる。一度失われた情報を、あとから回復することはきわめて困難であり、多くの場合、不可能である。

　それだけではない。粗な網の目は、字形のバリエーションをどこで切りわけるかについて、さまざまなブレを生じやすい。実際、現在、日本には五種類の公的文字コードがあるが、その間に、以下のようなズレがあるのだ。

五つのJISコードと字体包摂

78JIS	445B	5464	3022		322A		3962		3456
83JIS	5464	445B		3022		322A
90JIS & X 0212			3560		6C3F
97JIS			3022		322A		3962		3456
JIS X 0221	58FA	58F7	555E	5516	9DD7	9D0E	9AD8	9AD9	9593	9592

青字は JIS X 0212（補助漢字）のコードポイント

1978年制定の第一次規格（78JIS）を表にふくめている点について、疑問をもつ人があるかもしれない。しかし、過去のデータが存在するだけでなく、IBMの OS/2や、NEC版の MS-Windowsでは、インストールの際に、78JISか、90JISか（97JISは90JISと同じ）を尋ねてくるのだ。Mule用の 78JISフォントも流通している。78JISはいまだに生きている文字コードなのである。

　補助漢字（JIS X 0212）は、当初意図されていたJIS X 0208＋補助漢字という形ではあまり使われていないが、Unicodeの中にはいっているので、これから広まると見ていい。一度、公的規格となった文字コードは、なかなか消滅しないのである。

　JIS X 0208:1997の解説では、文字包摂の範囲が JIS X 0221（Unicodeと等しい）のそれとずれることを認めている。

　JIS X 0221の区点位置の解釈は必ずしも明確ではなく，そのため，この規格（JIS X 0208）の区点位置の解釈は，JIS X 0221のそれと必ずしも同一にはならないことがある点に注意されたい。
　例えば，JIS X 0221は，姫とを，別区点として区別しているが，この規格では，これらは包摂されており，互いに区別されない。（JIS X 0208:1997「解説 3.6.3」）

　Unicodeの漢字統合の問題点は、最新のJIS X 0208との間にズレがあるという点にとどまらない。漢字統合にあたって、中台日韓の国内規格の上位互換性が成立するように、原規格分離漢字規則（Souce Separation Rule）という規準を立てた。中台日韓の国内規格で別字とされている漢字は、統合するほど字形が似ていても、別のコードポイントをあたえるという約束である（JISでは同じコードポイントに包摂されている「高」と「」が、CJK統合漢字では別のコードポイントに割当あてられているのは、台湾の国内規格で区別されているためである）。

　いくら JISが厳密な包摂規準を作ったとしても、将来、ISO参加の漢字使用国（中台日韓にベトナムとシンガポールがくわわる）が、国内規格の改訂で新しい異体字を追加すれば、原規格分離漢字規則により、自動的に JIS X 0221にも追加され、字形切りわけの規準が動いてしまうのだ。

　異なる歴史と慣習をもち、字体体系の異なる国の漢字を、ルーツが同じという理由で統合した弊害が噴きだした形であるが、どこまでがデザイン差で、どこからが字体差であるかは、その国固有の歴史と慣習にもとづくだけに、工業規格で一律に決めるのはおかしいし、これでは文字の同一性が保証されない。

　異体字シソーラスは、検索の際に、一時的に同値関係の文字を設定するだけだから、さまざまな切りわけ方をしたシソーラスをつくっても差し支えないが、コードポイントの割当は、文字のアイデンティティにかかわるので、ズレがあっては、データの信頼性が怪しくなる。情報交換を担保する公的規格として致命的である。小文字セットは大文字セットをかねないのである。