文字コード、異体字、データベース利用者

日本語学会シンポジウムのメモ。おなじみHNGや、透明テキスト付き画像が簡単に作れるツールを知ったという点で大変興奮した拓本文字データベースに関わるご発表など、面白かった一方で課題も浮き彫りだったなあと感じた。

漢字データベースの構築は、文字コード内の異体字の取り扱いが壁となって、利用者にとっては必ずしも使いやすいものになるとは限らない、という話。というかそこまで具体的に言及されることはなかったのだけど、僕も漢字に関わるデータベースを作ってきたので、こと共同作業になるとこの難しさが大きい問題となることがよくわかる（個人作業でも揺れを防ぐのは一苦労）。異体字がどう位置づけされることとは別に、作業上の方針としてこの異体字はこの字とおんなじ、みたいな包摂基準を作ることはあっても、包摂基準を設定するだけで多分一つのテーマになっちゃうくらいだろうから、そこのところは薄目をあけるくらいに目をつぶって作業を進めるのがよくある話なのだと思う。

何が問題かというと、データベースを利用する側はいったいどの文字で検索すればいいのか、ということ。包摂基準がきちんとしていないと、利用者はヒットしそうな文字をかたっぱしからトライしてみなきゃいけないし、そもそも包摂基準を推測するだけの文字知識を備えていなければならない。それが分かっていたって、データセットの全貌が見えていないと「トライ漏れ」が出てくるわけで、やっぱり大変。

コンピュータでjis漢字（第何水準かはさておくとしても）しか表示されない時代は、まだ問題は牧歌的だったろうと思う。いまやユニコードで表示される文字数が増えてしまったから、コード内に異体字と正体字の関係、異体字同士の関係に迷うものも増えてしまった。

話は変わるけれど、今昔文字鏡が現れたとき、これでどの字を代表形とするか迷わずに済む、とおっしゃった先輩のことを思い出す。古い文献を見ていると、どの字で入力して良いか悩むことが多い。漢和辞典首っ引きになって、どの字はどれのこと、とか解釈して行かなければならなかったのを、今昔文字鏡が持っている字数が16万字という触れ込みなものだから、古い文献に出てくるような「変な」字であっても表示されてしまったりする。我々は規範的な字はこれだ、などということをイチイチ考えずに見た目まんまの字を入力すれば良い時代になった、と。それがたとえば和語の表記の問題などであれば、和語が検索キーになるから問題はなかった。でも、さて漢字そのものが関わる（たとえば字体）データベースとなると話は別。字そのものが検索キーとなってしまうから。

というわけで、入力選択の自由を得た代わりに、検索の不自由を得てしまった、コンピュータにおける漢字環境。漢字には理論的にはあるだけコード番号を与えることはできるのだろうけれど、使うのは人間だからさあ困った。いっそ、picasaの顔認識システムみたいに、文献画像を直接読み込んで、類似の漢字を画像としてヒットさせる仕組みとかはできないものか。コードをすっ飛ばして画像として処理してしまえば、とは思うけれど、でもどの字をどの字の仲間とみなすかという問題は人間依存なのだから、結局だめなのだな。音声は機械でもわかるけれど、音韻レベルでは結局人間がパラメータを与えなければならないのと同じか。