Unicode の部首を一意にする

@marmooo/kanji の部首データを Unicode 全漢字に対応させました。 @marmooo/kanji では画数データは一意になるように設計しているのですが、 Unihan Database の部首は Unicode 15.1 では 183 件の重複登録があり、この解決に苦労が伴ったのでメモを残しておきます。 ちなみに Unihan Database では画数の管理で int を諦めて string を使っているのですが、 情報が不確かな漢字のために int を放棄するのは嫌なので int にしています。 具体的なコードはこちらを参照してください。

ちなみに画数も重複データがあるのですが、3件だけなので画数の対処は簡単です。 より正確に言うと kRSUnicode には大量の重複データがあるはずなのですが、kTotalStrokes には重複が 3件だけです。 ただこれも問題のある話で、たとえば「滋」を kRSUnicode で見ると部首以外の画数が 9画と 10画の両方があると登録されていますが、 それなら kTotalStrokes もデータが 2つないとおかしいんですよねえ。 同じような問題は草冠でたくさん見つかるので、真面目にやるなら 漢字データベースプロジェクトのようなチェック が必要になるのでしょうね。 将来的にはやってみるかも知れませんが、IDS も更新しないといけないので時間が掛かります。

部首データの 183件の重複のうち、大半はなぜ複数あるのかよくわからないものが多いです。 康煕字典に記載があるものはなるべくそちらに沿った部首を利用するのが筋だと思います。 康煕字典に記載がないものが問題で、例えば「习」の解決には苦労しました。 「习」は Unihan Database では「冫部」または「乙部」と登録されています。 しかし「习」は 1956年の漢字簡化方案で「習」を簡略化して作った漢字なので、「冫部」または「乙部」の字義は存在せず、その登録でいいの？となります。 ただ漢字簡化方案の元情報が見つからないので、どうしようもない。 本当は部首情報があったのかも知れませんし、元々なくて字体から推測しただけかも知れません。

同じように中国では簡体字を作ったときのことをよく考えないといけない漢字が多々あります。 たとえば日本だと「卧」はそのままの字形で理解されていて Unihan Database では「卜部」です。 ただ中国だと「臥」が元字で、簡化によって「卧」になったので、康煕字典に合わせた部首は「臣部」なんですよね。 康煕字典に記載があるからといって、合わせすぎるのも難しそうです。新しい漢字と古い漢字は分けて考えないといけません。

他には「凬」も難しいですね。字義としては康熙字典の「風部」ですが、Unihan Database だと「⼏部」、文字情報基盤は両方登録されています。 日本だと風が由来でも「⼏部」になることが多いようなので、まあ「⼏部」でいいのかな。 でも中国や台湾でどうかと聞かれると、なかなか難しいところですね。

「厼」のように康熙字典網にも文字情報基盤にも登録されていない漢字も、データがどこから来たのかよくわからないで困ります。 ネットで調べてもほぼ情報がなく、なぜか一番詳しいのが 日本語の Wiktionary みたいなケースがチラホラあります。 当然ながら部首がわかるはずもないので、Unicode に従うしか方法はないでしょう。 ちなみに「厼」の本字は「彌」のようで、そこから様々な異体字と新字体が生まれているようです。 異体字はどれも部首がバラバラでちょっと笑えます。文字を簡単にしようとすると部首が崩壊するんだなあ。 つまり本字以外の部首は深く考えたら負けで、特徴的なパーツを選び、Unicode 配列に従っておけば良さそうです。 また本字以外は部首より、異体字をたどったり、IDS で検索するほうが良さそう。

分類の難しい漢字は、可能な限り理由付けやチェックをしていますが、基本的には使いやすさを考えて Unicode 配列に合わせていますし、それで特に問題ないと思っています。 今のところ Unicode 配列から明確にずれた状態で登録しているのは BMP なら「丬」の「⽙部」だけですね。 SIP では U+20064 の「⼞部」、U+2B820 の「⼷部」、U+2B8D9 の「⽊部」、U+2B8DA の「⽊部」です。 BMP はともかく SIP は部首をどれにするか難しいものがいくつかありますねえ。 日本なら上記以外のものは Uicode 配列に従って良いと思います。 中国だと先に述べたような漢字がちょっとわかりにくい気がしますね。 台湾でも同じような問題があるかも知れません。 ただ Unicode 配列だからこれでいいのだと言い張れば、まあいいかという気持ちになれるのは大きいかな。

追記: Unicode® Standard Annex #38 の画数の説明 を読んでいると、一意にしようとはしているみたいですね。 あまり手を出さないようにしつつなるべく一意にする今の実装方針で良いんじゃないかなという気がします。