似ている漢字とは（その1）

ユニコードには、統合規則(Unification Rule)、JISには包摂規準という、似ている漢字を同一の符号位置だと見做す決まりがある。ご存じの方も多いと思われる。

このような決まりの背後には、字体(character)と字形(glyph)の違いという、言語学的な概念の違いがある。この字体と字形の概念については、ぼく的には、以前書いた下記の文章がわりとよく書けていると思っている。

[https://www.jstage.jst.go.jp/article/johokanri/58/3/58_176/_article/-char/ja/] 

また、早稲田大学の笹原宏之さんたちの力作、

「常用漢字表の字体・字形に関する指針」（文化審議会国語分科会報告）

https://www.bunka.go.jp/koho_hodo_oshirase/hodohappyo/pdf/2016022902.pdf

が、文字行政での運用に関しては、基本資料と考えていいだろう。

何かの会議のあと、文化庁国語課の武田さんが、わざわざ近づいてきて、上に挙げたぼくの文章のことを気恥ずかしくなるほど褒めてくれたので、ぼくの考えも、文化審議会の考え方とそれほどは違っていないのだろう。

ちなみに、JIS X 0213では、2014年だったかの改正の折、従来は解説で、常用漢字表の字体と字形についての図版だけを引用していたところを、本文もごそっと引用して、文化審議会に対する（というか内閣告示・訓令に対する）恭順の意を明確にしている。

そんなわけで、前回触れた、文字情報基盤のいわゆるMJ文字図形とUCSの符号位置との対応関係についても、基本的には、UCSの附属書Sに記載されている統合規則に従って、同一の字体と見做せるものを結びつければいいわけで、この規則に従って、同一の書体とは見做せないものは、エラータとして訂正する必要がある。

今回のレビューは、ISO/IEC JTC1/SC2に対して、いくつかの（と言っても3万以上だけれど）符号位置について、新たな典拠（MJ文字図形名）の追加を日本から提案する前に、間違いがないかどうか、念のためにもう一度確認しておこう、というものだ。まあ、それが国際標準に提案する際のお作法といった塩梅でもある。

で、その準備を少しずつ進めているのだが、協議会の主力メンバーのお一人から、「社員にレビューを手伝ってもらいたいのだけれど、具体的にどうやったらいいか教えてもらいたい」という問いかけをいただいた。

正直なところ、ちょっと足下をすくわれた思いだった。

ぼく自身、もう20年ぐらいは、UCSの漢字パートのレビューをやってきてはいるが、では、具体的にどうすればいいか、マニュアル化しろとか言われると、ちょっと戸惑ってしまう。UCSの標準化に日本として係わっている情報処理学会情報規格調査会SC2専門委員会(JSC2)でも、ISO/IEC JTC1/SC2?WG2の下で実作業を担っているIRGにしても、具体的な方法のガイドラインがあるわけではなく、いわば、見よう見まねで、受け継がれてきた、というのが実情なのだ。

ぼくが、標準化に係わり始めたころ、作業の中核を担われていた、元日立製作所の小池さんなど、新しい符号化提案のリストを見ながら、「定規で一行ずつさささっと追っていけば、UROにあるかないかぐらいすぐに分かるよ」とおっしゃっていたし、元アドビのKen Lundiなど、フォトグラフィックメモリーの特殊能力を持っていて、CJKの漢字のイメージが全部脳に刻み込まれているみたいで、このような人たちには、どう逆立ちしても、勝てっこない。

それに、小池さんの時代は、UROの漢字は、全部併せても2万字に満たなかったのが、今では、9万字以上もある。

とても、ゼロから目視で似ている漢字を探し出すなどという作業が出来るとは思えない。というか、やってはいるが、誤りや見落としをゼロとして、完璧に出来るとは考えがたい。

そこで、何らかな機械的な作業を補助的に使おう、ということになる。

今回は、そんなお話。

 

部首画数順

IRGでは、新しい文字の標準化を提案する際には、典拠資料とともに、いくつかのメタデータを添付することになっている。その一つが、康煕部首と部首内画数。
最初に発行されて以来、CJKパートは伝統的に、まず、康煕部首の順に、次いで部首内画数の順に排列することになっている。何のことはない、一般的な漢字辞典の見出し字の排列順と同じ。
で、IRGのメンバーも、レビューの際には、基本的に、部首画数順に排列された既存の文字と照らし合わせていくことになる。
ところが、ご存じのように、CJK統合漢字は、UROを初めとして、現在の拡張Gまで、拡張に拡張を重ねていて、それぞれのブロックごとに部首画数順に並んでいて、いちいち見ていくなど、面倒で仕方がない。
そこで、Unicode Consortiumのホームページにある、全統合漢字の部首画数順インデックスを使ったりする。
(img)
しかし、厄介なことに、この部首画数順というのがくせ者なのだ。
経験された方も多いと思うが、あれっと思う字があれっという部首に属していたりする。漢字学の泰斗、阿辻哲次さんは、実家が活版印刷屋さんで、門前の小僧で、活字箱に慣れ親しんでいたため、高校生のころ、授業で難解な漢字の部首を言い当てて、先生に褒められ、それがきっかけとなって漢字学の道に進むことになったと、その著書に書いておられる（今、探してみたのだけれど、何という本のどこに書かれていたかが見つけられない）。
世界に名だたる諸橋徹次の大漢和辞典でも、複数の部首に誤って二重に掲載されている漢字が複数ある。
というわけで、CJK統合漢字でも、どの漢字がどの部首に排列されているかには、どうしてもある程度の曖昧さが伴う。というわけで、提案された文字に付いている部首名だけを頼りに、統合されるべき文字を探しても、相手が別の部首に排列されていて見つけられない、などということは、日常茶飯のことなのだ。
そんなこともあって、文字情報基盤のMJ文字情報一覧表では、参考として康煕部首が複数（最大4個）掲げられていたりする。
教訓風に言うと、康煕部首に頼りすぎるのは危険。

UCSの方はと言えば。
規格票には、一応、部首と部首内画数は記載されているが、情報の多くは、Unicode.orgのUnihanDatabaseに記載されている。
いつも、オリジナルのファイルを探すのに苦労するので、覚えのために書き留めておくと。
https://www.unicode.org/Public/UCD/latest/ucd/Unihan.zip
にまとまっている。
ところが、これがまた、見にくい。
全コードポイントの部首と部首内画数、総画数が含まれているのは、
Unihan_IRGSources.txt
で、この中で、二つ目のカラムが”kRSUnicode”となっているのが、康煕部首番号と部首内画数、”kTotalStrokes”となっているのが、総画数。
やれやれ。これを、表計算ソフトやデータベース、何らかのスクリプトで処理しないと、それぞれのコードポイントごとの部首番号、部首内画数、総画数を一覧することは出来ない。
注意点を一つ。UnihanDatabaseには、”Unihan_RadicalStrokeCounts.txt”というファイルがあり、康煕字典の部首画数情報とAdobe Japnan 1の部首画数情報が収められているが、この情報は、符号化されたCJK 統合漢字やCJK互換漢字の全符号位置を網羅しているわけではない。恥ずかしながら、ぼくがこのことに気付いたのは、ごく最近、水平拡張レビューのための、下作業を始めてから。面目ない次第。

部品検索

部首画数順とちょっと似ているのが、漢字を構成する要素を、部首に限定せずに指定して検索する方法。当協議会のサイトでは、要素図形（検索）と呼んでいる。
電子メールはおろか、ファクシミリもなかったころは、現地取材に出た新聞記者が、本社に記事を電話で送っていた。いわゆる電話送稿。同音異義語の間違いを防ぐために、「うしへんにつち」（牡）とか「おんなみっつ」（姦）とかやっていた。共同通信で電子化関係を担当していた知人の話だと、この表現も、新聞社による多少の違いはあれ、かなり統一されていたということだ。
この仕組みはユニコードにも導入されていて、漢字を構成する要素を、どのように並べるかを指定するIdeographic Description Charctersという一群（⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻都合10文字）の文字が規定されている。
この仕組みを用いれば、例えば、⿱ 山奇（嵜）と⿰山奇（崎）といった要素の位置の違いと表現することも出来る。このようなIDCを含み、要素図形の構成で漢字を表す文字列をIdeographic Description Sequence(IDS) と呼んでいる。
しかし、ちょっと考えればお分かりと思うが、ある漢字を表現するIDSは一通りではない。例えば、「淋」という字は、⿰氵⿰木木　とも表現できるし、⿲氵木木とも表現できる。
そんなわけで、IDSを漢字検索に用いるためには、いろいろと厄介な操作が必要となる。
ちなみに、当協議会の要素図形検索は、IDSは用いずに、該当漢字の構成要素と見なすことの出来るMJ文字すべてを列挙するようにしてある。そのため、入力する要素図形によっては、膨大な数の候補文字が出て来たりするが。
IDSで一番整備されているのは、何と言っても、兄弟の守岡さんが作っている、Chiseプロジェクトのもの。これについては、以前、書いたことがある。
https://moji.or.jp/2020/05/07/chise%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AEids/
IDSと文字情報基盤の要素図形情報は、似ているようで、じつのところ、相互参照しながら利用しようと思うと、案外厄介な問題がある。今回の水平拡張レビューを目指した試行錯誤でも、いろいろやってみたが、大まかなフィルタリングには使えるが、細かく絞り込もうと思うと、なかなか連動させるのが難しく、結構苦労した。MJならMJ、大漢和なら大漢和、UCSならUCSという文字セットごとに、IDSならIDS、要素図形検索なら要素図形検索単独で用いるのが無難かな。

さて、いよいよ図形的に似た字についての議論に進みたいのだけれど、今回は、ここで一休み。