インターネットと漢字 4/4

加藤弘一
承前

●4 異体字と符号化対象

表語という視点

 異体字は単なる字形デザインの問題と考える人がすくなくない。特にフォント関係者の多いユニコーダーには異体字をフォント技術の範囲で解決しようという傾向が強い。

 だが、異体字は果してデザインの問題なのだろうか。実はアルファベットの世界にも異綴語という、異体字と似たような問題がある。

 たとえば、カラーという単語は英国ではcolourと綴るが、アメリカではcolorと綴る。シアターは英国ではtheatre、アメリカではtheaterである。アンという名前にもAnnとAnneという複数の綴りがある。単語の綴りは時代的・地域的に変化しているのである。

 単語を表す、すわなち表語という視点から見ると、漢字の異体字と英語の異綴語はよく似ている。そもそも、「猫」はCやAやTに相当するというより、CATという単語に相当すると考えるべきではないか。

 近代の漢字廃止論者は、英語はアルファベット26文字を憶えるだけでいいのに対し、漢字は何百何千という文字を憶えなければならず、非民主的・非能率的だと主張したが、欧米語でもアルファベットをおぼえただけでは駄目で、単語を何百何千と憶えなければ読み書きできない。そして実際、漢字削減論に相当するBasic Englishのような単語削減論や、字体簡略化論に相当する綴り簡略化論があるのである。ドイツは1998年に新正書法を施行し、kusをkuss、PhotoをFotoのように綴りを単純化したが、これは日本の国語改革に相当する政策だろう。

 アメリカ生まれのメジャーなワープロソフトには、日本語化された初期の版から異体字検索機能(「真紀子」で検索すると「眞紀子」もヒットする)が実装されていたが、これは実は異綴語検索機能(「color」で検索すると「colour」もヒットする)を転用したものだった。

符号化対象の抽象化

 もちろん、すべての異体字が異綴語に相当するわけではなく、なかには字形のデザイン差にあたると考えた方がいいものもあり、その境界は曖昧である。新字種についてはどんどん追加していけばいいが、異体字はどの範囲まで独立の符号をあたえるか、どの範囲まで同一符号であつかうかについて、議論がつづいている。

 異体字の符号化の問題にはいる前に、ここで符号化される文字とはなにかについて考えてみたい(注16)。

 一番素朴な考え方としては、文字=字形説があるが、字形そのものに符号をふると、文字コードならぬグリフ・コードになってしまい、規格票の字形をそのままフォント化しないと規格不適合になる。

 その意味で純粋なグリフ・コードは成立しえないが、GB 2312は中国文字改革委員会の「簡化字総表」と「第一次異体字整理表」に、CNS 11643は中華民国教育部の一般向けおよびコンピュータ向け字体表にもとづいており、グリフ・コード的な志向をもっている。また、後述するように、JIS X 0213の康煕別掲字(注17)は包摂の例外とされており、グリフ・コード的性格を帯びている。

 自分の機械に表示されている文字が、別の機械では別の字形で表示されているなどということは実感しにくいので、コンピュータの専門家といえども、どうしてもグリフ・コード的な発想から抜けきれない傾向があるが、グリフ・コードと文字コードは別物だという点は押さえておきたい。

 符号化対象について先駆的な認識を示したのは78JIS(JIS C 6226の第一次規格)である。

 78JISは規格本文において、文字の「特徴」として「文字概念」、「名称(又は読み)」、「用途(又は用法)」、「字形」、「符号」の5項目をあげ、符号がふられる対象は「文字概念」だとしている。

 文字の特徴の一つにすぎない文字概念に符号をふるのは矛盾だという批判が一部にあるが(注18)、それは誤解である。自動車を例に説明しよう。

 自動車にはボディカラーやタイヤ、フレーム、車体番号といった特徴があるが、白い車を黒く塗りかえたり、タイヤをスノータイヤに交換しても、その車が別の車になるわけではない。しかし、フレームは廃車にするまで変更できない。フレームは自動車の不変要素であり、車検証ではフレームにふられた車体番号によって車を同定している。

 文字についていうと、フレームにあたるのが文字概念、車体番号にあたるのが符号である。字形が「父」、「父」、「父」に変わろうと、文字概念は不変であり、その文字概念につけられた「41 67」という符号も変わらない。

 78JISは符号化対象を字形から文字概念へ抽象化するというモデルを提出したが、ネットワーク以前の時代だったので、文字概念を定義する手続も、個々の文字を一意的に同定する方途も用意されなかった。78JIS主査の西村恕彦は「漢字のJIS」で「父」を「男親を表す漢字」と定義する例を示しているが、「龍」と「竜」のような異体字をどう定義するかという問題にまでは踏みこんでいない。今日的視点から見れば歯がゆいが、当時はそれで十分だったのである。

 78JISは理論的には文字概念によって例示字形を相対化したわけだが、文字概念を定義する方途が用意されていないので、文字概念に接近するためには例示字形を手がかりとするほかはない。皮肉なことだが、例示字形は結果的にいよいよ重要性を増すことになった。

 ISO/IEC 10646は抽象化された符号化対象を文字名によって区別している。文字名という概念はOCRの規格を審議する中から生まれたらしいが、ISO/IEC 10646にとりいれられ、全世界の文字を一意的に区別する概念的枠組となった。既存規格の文字との対応づけも文字名によっておこなわれている。

 文字名は「表記体系の名称+文字の名称」という形式をとる。表記体系内の文字は音価、音価+付加記号、記号の場合なら機能にもとづいて命名されることが多い。 同一字形であっても、表記体系が異なれば別の文字名があたえられる。

 たとえば、ラテン・アルファベットとギリシア文字を借用するチェロキー文字では「D」にAという音価をあたえている。ラテン・アルファベットの「D」とチェロキー文字の「D」は字形は同一だが、

LATIN CAPITAL LETTER D(ラテン大文字D)
CHEROKEE LETTER A(チェロキー文字A)

と異なる文字名をもち、異なる符号があたえられている。

 定義には概念的に定義する内包的定義と、要素を枚挙する外延的定義の二つがあるが、文字名は文字を内包的に定義しているといってよく、言語文化上の問題は残るにせよ、定義の手続を明確にした点において、文字概念よりも一歩進んでいると考えられる。

 漢字の文字名はどうなっているのだろうか?

 ユニコード側が最初に用意した原案では、すべての漢字に字義の英訳による文字名がつけられていたという。「父」を「男親を表す漢字」と定義するようなものだが、漢字の字義と英語の単語の語義の間にずれがあっただけでなく、日中韓で字義の異なる字が続出したために、この方法は却下され、符号表の16進番号(符号)をそのまま文字名とする便宜的な命名法がとられることになった。U+9592の「閨vはCJK UNIFIED IDEOGRAPHE-9592、U+9593の「間」はCJK UNIFIED IDEOGRAPHE-9593という具合で、符号から逆に文字名を決めているに等しく、漢字を定義する難しさを浮彫りにした。

 むしろISO/IEC 10646で重要なのは、夫々の漢字について、各国の規格票の例示字形を併載した点である。文字名が包含する字形を列挙することで、結果的に外延的な定義に近いことをおこなったことになる。

 もちろん、列挙された字形は1991年時点における例示にすぎないし、それぞれが揺れをふくんでいて、外延的定義とはとてもいえないが、外延的定義の可能性を示唆した意義は大きい。

 97JIS(JIS X 0208の第4次規格)はISO/IEC 10646の文字名もとりこんではいるが、「区点位置と字体の対応」、「過去の規格で字体・字形の変更があった区点位置」等とあるように、「区点位置(code point)」という概念によって、符号化対象を実定法的に定義している。

 97JIS規格票の「4. 定義」の項を見ると、

d) 区(row) 2バイト符号の中で、第1バイトによって区別される符号又は図形文字の集合

e) 区点位置(code-point) ある区の点。区点番号(区点)によって参照できる。

となっている。点=文字という言い方を避けて、回りくどい表現になっているが、それには意味がある。「区点位置」は区点番号そのものではなく、区点番号によって参照される何かである。その「区点位置」を媒介にして符合と図形文字が結びつけられるのである。

 図形文字とはなにか? 図形文字は「手書き・印字・表示の可視的表現をもち」と定義されているように、グリフそのものではなく、グリフの背後に想定されるもの、グリフを抽象したものであり、それが区点位置によってあらわされるのである。

 符号表上の位置にすぎない区点位置にはなんら内容はなく、文字を一意的に定義する役には立たないと考える向きがあるかもしれないが、それは違う。確かに78JISやユニコードのような、ゼロから創設された文字コードの符号表の場合には、区点位置はなにも内容を含まないといえるだろうし、JISの改訂には過去のしがらみを敢えて断ち切っておこなわれたものもある。だが、97JISは、JIS X 0208の符号表の20年近い歴史をまるごと引き受けようとしたのである。

 文字概念、文字名といってしまうと、符号表とは独立に存在する超歴史的なものであるかのような意味合いをおびるが、97JISの区点位置はJIS X 0208という固有の歴史をもつ符号表の区点位置であって、符号表の歴史によって拘束され、内容をあたえられている。実際、97JIS規格票で大きな分量を占める「区点詳説」という文書では、JIS X 0208符号表の例示字形変遷史をあつかっている。

 もちろん、例示字形の変遷史をそのまま提示したのでは規格として使いものにならない。97JIS原案委員会はJIS X 0208の符号表の歴史と運用歴、さらには78JISの字形決定にあたった林大の個人的なメモをもとにして(注19)、字形の揺れをどこまで許容するかというルールを創設し、「包摂規準」として規格中で明文化した。JIS X 0208の歴史の中でも、83JISは「鷗」を「鴎」にするといった字形変更をおこなって多くの混乱を引き起こしたが、この錯誤の歴史をも「過去の規格との互換性を維持するための包摂規準」としてとりこんでいる。

 「包摂」には規格票中でunificationという訳語がつけられていることからもわかるように、ユニコードの漢字統合(Han unification)の影響が明白だが、包含される字体を列挙するという方法ではなく、例示字形を出発点として、その文字に許されている包摂規準を適用していくと、包含される字体が演繹されるという手続をとっている。間接的な外延的定義といえよう。

 JISは過去に歴史を無視した改正をおこなったことがある。それを考えるなら、符号表の歴史を、矛盾も含めて、まるごと抱えこもうとした97JISの決断は十分評価しなければならない。しかし、JISの歴史の内部でのみ包摂基準の整合をとろうとしたために、法務省の戸籍法施行規則附則別表やISO/IEC 10646などとの間で齟齬が生れたのも事実である(たとえば「」と「高」を包摂した点。「」は戸籍法施行規則附則別表でも、ISO/IEC 10646でも、後述の住基ネット「統一文字コード」でも独立の文字としてあつかわれている。IBMやNECのメジャーなパソコンにも昔から独立の文字としてはいっており、Windows外字に引き継がれている)。

 もう一つの問題点は、歴史主義的な考え方を背景にしているとはいえ、包摂字体の範囲(粒度)を決定する手続が事実上、例示字形を出発点にしていることである(明文規定はないが、それ以外の手続は不可能)。97JIS規格票では粒度を厳密に定義しているように見えるが、出発点である例示字形が動いてしまえば、包摂にグレイゾーンが生じるのは避けられない。

 これは杞憂ではない。過去の混乱を考えると、例示字形の変更はおこなうべきでないが、そうも言っていられない状況が生まれたのである。

 1981年の常用漢字表は、前文で表外漢字の字体については「各分野における慎重な検討にまつことにした」と拙速な簡略化に歯止めをかけたが、83JISが「鷗」を「鴎」にするといった例示字形の変更をおこなったために、ワープロでは「鷗」では「鴎」としか打ちだせないという状況が生じ、教育現場などではどちらの字体を使うべきか、指針を示してほしいという要望が生まれた。

 この要望にこたえるために、国語審議会は2000年に「表外漢字字体表」を答申した。「表外漢字字体表」は83JISがくわえた字形変更を元にもどすという方向性をもっており、当然、JIS規格票との間に不整合を生じた。

 この不整合を解決するために、JIS X 0208とJIS X 0213の改正が準備されているが、例示字形の変更やむなしという方向でまとまりつつあるという。しかし、現状のまま、例示字形を変更すると粒度が揺らいでしまうので、粒度決定の手続になんらかの変更がくわえられる模様である。

フォントによる異体字情報交換

 包摂されている字体を特定して、情報交換したい場合はどうしたらいいのだろうか? 97JIS公開レビューの際、掲出された「本規格の考え方」には次の一節がある。

 漢字については、包摂されている字形についての情報交換の要望が出されているが、これについても、原則として拡張された組版の機能による実現を想定しており、包摂規準については、前述のように、JIS X 0208と同様のものとしている。

 字体包摂の考え方からいえば、粒度内なら、規格票と異なる字体のグリフを符号位置に置いた異体字フォントを作っても規格適合であり、アドビ社のCIDフォントのように、一つの符号位置に複数のグリフを用意し、付加情報によって選択するようにした特殊なフォントも開発されている。「拡張された組版の機能」とは、このようなフォント技術の活用をさすものと思われる。

 この方式は「文字符号+フォント名」によって特定のグリフをピンポイント指定するわけで、グリフ・コード的解決といえる。

 ただし、問題点が二つある。

 第一は受け手側の機械が、送り手が使用したのと同じフォントが搭載されていなければ、代替グリフ(受け手の環境によって異なる)が表示されてしまい、送り手の伝えようとした字体がわからなくなるという点である。フォント依存の異体字情報交換を担保するためには、異体字フォントの標準化と普及が不可欠である。

 第二はフォント名指定は書式指定情報でおこなわれることである。書式指定情報はアプリケーション依存であり、文字コードと違って安定性にとぼしい。情報交換の過程で書式指定情報が欠落する危険性は高く、同一の機械内であっても、ウィンドウからウィンドウへ文字列を複写しただけで、フォント指定が落ちることがよくある。

 また、仮名漢字変換ソフトは書式指定情報を含んだ文字列に対応しておらず、文字列入力後にいちいちフォント指定をしなければならない。

 ユニコードはこうした問題を解決するために、variation selecter(表示形選択子)という機構を設けた。

 variation selecterはBMPのR領域にマッピングされており、もともとは異体字グリフを指定する異体字選択子として提案された。制御符号的なあつかいで、通常は表示されないが、文字コードのレベルの情報なので、情報交換の途中で失われる危険性はすくない。

 よく考えられたスキームであるが、文化依存性の高い異体字を国際的に標準化する点に疑問が提起されたため、現在はモンゴル文字の表示形を指定する用途ぐらいにしか使われていないという。

 異体字情報交換が必須となるのは固有名詞、とりわけ人名・地名においてである。

 日本政府は電子政府を実現するためにe-Japan構想を進めているが、すべての公文書を電子化するためには、全国民の氏名・住所が正確に記録できなければならない。電子政府にはISO/IEC 10646が使われることになっているが、ISO/IEC 10646は粒度が大きすぎて、人名異体字・地名異体字を特定することができない。たとえば、「」と「」はJIS X 0208でもISO/IEC 10646でも同じ字として扱われるが、住民基本台帳では区別されている。

 日本の経済産業省は字体の違いを含めた情報交換の重要性に気づき、「汎用電子情報交換環境整備プログラム」を立ちあげ、総務省、法務省、文化庁との連携のもとに、ユニコードのvariation selecterとは別に、異体字情報交換方式の開発を進めている。

 その一方、2002年から運用のはじまった住民基本台帳ネットワークでは「統一文字コード」という独自文字コード(ISO/IEC 10646を基本とするが、BMP内の漢字領域以外の場所に異体字をマッピングしており、ISO/IEC 10646との互換性はない)と、「住基ネット明朝」という独自フォントによって、自治体間の情報交換をおこなっている。

 独自文字コードという点だけでも問題だが、「統一文字コード」はJIS第1〜4水準、法務省許容字体、各ベンダーの外字セットを集めた2万1千字しか収録していない。「統一文字コード」に含まれていない異体字は「残存外字」と呼ばれ、画像として交換される。

 住民基本台帳ネットワークはe-Japan構想以前から準備されており、基本的に紙の書類を打ちだせればいいという発想で設計されているようである。

漢字統合のその後

 97JISの3年後、JIS X 0213が制定された。UCS未収録の新字種303字が拡張Bに追加されたが(注20)、ISO/IEC 10646側の対応表にはJIS X 0213との関係の記載がなく、JIS X 0213の規格票の方でUCSとの対応関係を一方的に規定するという形式をとっている。国によってはISO/IEC 10646の対応表に記載されることをもって、自国の文字が国際的に認知されたと考えるところもあるが、日本はフリーハンドを確保するために、あえて記載をもとめなかったといわれている。

 JIS X 0213にはJIS X 0208で包摂されていた康煕別掲字と法務省の許容字体の一部を独立の文字として収録している。その結果、JISの包摂規準はJIS X 0208版とJIS X 0213版に分裂することになった。

 ISO 2022-JPをJIS X 0213があつかえるように拡張したISO 2022-JP3では、JIS X 0208環境とJIS X 0213環境の間で情報交換する場合は、「海」、「歩」、「黒」など、包摂規準にずれのある漢字をあらかじめ使えなくしている。

 国語審議会は最後の仕事として2000年に「表外漢字字体表」を発表した。「表外漢字字体表」とJIS漢字コードの齟齬を解消するために、JISの改正が準備されているが、統合されていた異体字のいくつかが独立の字として追加されると見られており、JIS内部の包摂規準のずれはいよいよ複雑になっていくだろう。

 また、統合を解かれた異体字は包摂の適用外とされるために、規格票に掲出されている字体通りでなければ規格不適合になる。「徴」にふくまれる「王」という部分字形は、包摂規準によって「王」でも「壬」でもよいが、康煕別掲字の「徵」の場合は「壬」でなければならないというように。97JISとJIS X 0213の包摂規準の間にずれがあるだけでなく、JIS X 0213の内部でもズレがあり、規格票を隅から隅まで何度も注意深く読まなければ、包摂されているかどうかはわからない。

 一度統合した異体字を分離しようとすると、一国内でもこれだけややこしいことになるが、国際的情報交換だと問題はさらに深刻になる。

 中国の簡体字くらい簡略化がおこなわれていれば、統合されずに独立の文字としてあつかわれるが、康煕別掲字に対応する日本の新字体は、一点一画にこだわった簡略化だったので、他国欄の伝統的な字体と統合されているものが多い。わかりやすくいえば、康煕別掲字に相当する字体は他国欄にすでにはいっているのである。

 もし独立の文字として追加するとすれば、互換漢字として追加するしかない。しかし、互換漢字の追加は漢字統合ルールを根本から脅かすことになるので、事実上のタブーとなっていた。

 日本はJIS X 0213に収録した統合範囲の異体字60字を互換漢字として追加するようにもとめた。巨大な市場を擁する日本の提案だけに、追加はあっさり認められ、互換漢字追加が解禁された。台湾がかねてからもとめていたCNS 11643第3面以降の異体字も認められ、互換漢字は500字以上も追加された。

 互換漢字解禁にともない、互換漢字の位置づけも「限りなく使用禁止に近い」文字から、「統合漢字と使用上の区別はない」文字に変った(注21)。

 統合されるべき範囲の異体字でも自国規格に収録した後、国際規格に追加できるようになったことは重大である。しかし、使用上の区別がないとしても、理論上は依然として区別があった。

 まず、第一点は、互換漢字は原規格との互換性維持のためにもちいられる文字なので、他国では使えず、ドメスティックな存在にとどまったことである。

 第二点は、互換漢字は例示字体以外の字体を有さないので、粒度(包摂の範囲)をもたなかったということである。

 第三点は、互換漢字として追加された文字は、統合漢字のどこかの国の欄にすでに掲出され、統合(包摂)されているということである。自国の規格で統合(包摂)分離をしたとしても、国際的には統合(包摂)は依然としてつづいているのである。

 たとえばU+05688は日本欄だけが「器」(点なし)で、中国を含む他の国の欄では「」(点あり)となっている。

 日本は康煕別掲字のの追加を申請し、U+0FA38に収録されたが、台湾は日本欄の字体と同一の「器」(点なし)の方を追加申請し、U+20F96として収録された。一方、もともとのU+05688は「」(点あり)・「器」(点なし)両方の字体を統合(包摂)したままである(注22)。

 「」(点あり)・「器」(点なし)を区別する場合、日本では「」(点あり)をU+0FA38、「器」(点なし)をU+05688であらわすが、台湾では「」(点あり)をU+05688、「器」(点なし)をU+20F96であらわすことになる。

U+05688U+0FA38U+20F96
日本 
台湾 

 1991年時点の規格で漢字統合を強行したつけがまわってきたわけだが、いっそのこと、U+05688を使うのをやめて、日本でも台湾でもはU+0FA38、「器」(点なし)はU+20F96とすればすっきりするのだが、それにはISO/IEC 10646の一部となっているUCSと各国文字コードの対応表を改訂しなければならず、まず無理である。

 ところが、2002年のIRG東京会議における北朝鮮提案の互換漢字をめぐる審議の中で、理論上の区別も解消されてしまった。

 北朝鮮が追加申請した異体字は、台湾ないし日本のために追加された互換漢字と重なるものが多かったので、ほぼ同一字といってよい異体字を重複登録するかどうかが議論になった。ユニコード側は重複登録は避けるべきで、互換漢字も統合すべしと主張し、最終的にユニコード提案が通った。

 この決定の影響は甚大である。まず、互換漢字はドメスティックな存在だったが、多国間で使ってよくなってしまったこと。第二に、互換漢字は包摂範囲を有さなかったが、統合したことによって包摂範囲をもってしまったこと。

 ユニコーダーがなぜ漢字統合の破壊に等しい提案をみずからおこなったかは謎だが、これで1993年の漢字統合は決定的に有名無実化した。

さまざまな模索

 国際規格が混迷の度を深める一方、コンピュータはこれまで使われていなかった分野にまで導入され、新規字種や異体字の追加が早急にもとめられるようになった。そこで緊急避難的な漢字情報交換方式が模索されている。

 ここではTRONコードと今昔文字鏡、国立国語研究所の三つの試みを紹介する。

TRONコード

 坂村健の提唱するTRONプロジェクトではTRONコードという独自の文字コードを定めている。TRONコードはパソコン向けの仕様、BTRONを実装したパーソナル・メディア社の「超漢字」で使うことができる。

 TRONコードはISO/IEC 2022同様、文字面切り換え方式をとっており、150万字が収用可能だが、現時点では17万4千字(漢字は17万字)を収録している。収録文字は「TRON文字収録センター」で確認することができる。

 TRONコードの特徴は独自の文字セットを編成することなく、既存文字コードの文字セットをそのまま収録していることである。

 日本、中国、台湾、韓国の公的規格の文字セットを別々にいれているところまではISO/IEC 10646の最初の原案と同じだが、それに加えて東京大学多国語処理研究会が策定したGT書体文字セットと、大修館書店の『大漢和辞典』収録文字の文字セット(ただし、字形は異なる)という日本製文字セットもそっくりいれてある。将来的にはUCS漢字セットもはいるらしい。

 TRONコードには「一」や「人」のような基本的な文字は五つも六つも重複して登録されているが、同一文字の重複登録なのか、異体字なのかは定義されておらず、文字同定は不可能である。文字同定ができない以上、漢字セットとしては破綻しているという見方もありうる。

 既存文字セットをそのまま収録したことにより、文字コード変換による包摂規準のずれの問題は一時的に棚上げされるが、これで解決といえるかどうかには疑問がある。既存文字コードから変換した文書にまったく変更をくわえないのならまだしも、加筆、書き換え、置換などの編集作業をおこなった場合、漢字セットとしての破綻が表面化するだろう。

今昔文字鏡

 今昔文字鏡はエーアイネットと文字鏡研究会が構築した文字データベースとフォント・ライブラリで、現在、漢字10万字、甲骨文3300字、篆文1万字(『説文解字』収録字)、梵字1800字、西夏文字6000字におよび、東アジアの文字を網羅しつつある。

 もともと学術目的ではじまったプロジェクトだが、一般利用者向けにいちはやくフォントの無償公開に踏み切った結果、官報のXML化の標準外字セットや情報処理学会試行標準に選ばれており、大規模文字セットのデファクト標準的な位置にある。

 エーアイ・ネットは文字鏡フォントのはいっていないマシンでも、文字鏡文字を使ったWWWページが表示できるように、インターネット上で文字画像を配信するシステムを有償・無償両形態で稼働させている。文字画像を自分で作り、貼りつけるのと原理は同じだが、文字鏡サーバーのURLという共通の文字識別子をつかうので、外字の一意性が担保される。

 今昔文字鏡は文字セットを提供するだけで、文字コードではなかったが、グリフ登録規格ISO 10036による国際登録簿にそっくり収録され、文字鏡番号はグリフ・コード的な性格を帯びるようになった。グリフ・コード的な解決がもとめられる分野では、今後、今昔文字鏡は重要な役割を果たすことになるかもしれない。

国立国語研究所

 海外の日本語学習者は学校で学んでいるだけで200万人を越えているが、教材や日本語書籍情報が慢性的に不足しているという。インターネットは有効な解決法になる可能性があるが、現状では日本語が表示できるパソコンがすくないために、日本語ページを閲覧できるのは、一部の学習者に限られるという。

 国立国語研究所は画像文字の組みあわせによって、日本語フォントのはいっていないマシンでも日本語のWWWページを表示できる「文字配信システム」を開発し、2001年から海外の日本語学習者を対象に、日本語書籍の書誌情報を提供するJiBooks()というサービスを提供している。

JiBooksは初年度は日本書籍出版協会による『日本書籍総目録』(注23)だけだったが、2002年から早稲田大学図書館の書誌情報サービス、WINE(注24)のデータがくわわった。提供データは今後も追加されていく模様である。

 日本の図書館検索システムは、JIS X 0208というしばりがあるために、ケ小平を「トウ小平」、飾北斎を「葛飾北斎」のようにしか記述できない。ISO/IEC 10646という解決法もあるが、まだすべての字体が収録されているわけではないし、すべての機械に必要なフォントがはいるのはかなり先になるので、JIS X 0208のしばりはしばらくつづくと見なくてはならない。

 国立国語研究所と日本書籍出版協会は、JIS X 0208 やUCSにない漢字もデータベース化する方法を「文字配信システム」の延長で共同開発しており、2003年10月からBooks.or.jpに組みこまれた。

 経済産業省は電子政府のために「汎用電子情報交換環境整備プログラム」を進めているが、その中核となる「電子政府文字情報データベース」(注25)は「文字配信システム」の漢字データベースをもとに構築されるもようだ。

 「電子政府文字情報データベース」には、住民基本台帳、戸籍等で独立の文字としてあつかわれるすべての漢字を同定した上で収録し、字体情報・読み情報・国語施策情報・文字符号・異体字関係を付与していく。収録字は最終的には6万文字程度になるらしい。

 この成果はインターネット上で公開するとともに、個々の漢字の平成明朝書体(注26)によるグリフを、「文字配信システム」を発展させたシステムで、画像として提供するという(外字のあつかいになるが、一意的な番号がつくので、情報交換はできる)。

 こういう作業は、本来は1978年までに完了しておくべきだったが、時代的制約から無理だったのだろう。四半世紀遅れたとはいえ、ようやく日本語の実態に即した漢字データベースが完備されることを喜びたい。

← 前
Copyright 2004 Kato Koiti
This page was created on Nov11 2004.
文字コード
ほら貝目次