（暫定版）
最近(1996年11月頃）、BeBOXで日本語情報処理や多言語情報処理をする為の検討が、俄かに議論が沸き上がってきている。
そこで、日本語情報処理や多国語情報処理について考えてみることにする。
多国語情報処理で普及しているシステムといえば、GNU ProjectのテキストエディタGNU Emacsをベースにして、日本の通商産業省工業技術院電子技術総合研究所 で開発されたMuleが有名である。
国際的な試みとしては世界中で使われている主要な自然言語を記述する為の文字を単一の符号化集合体に収める努力をしたUNICODEというものもある。
またUNICODEに対して反対意見をっ持っている人たちも居る。
電子計算機は、「真値と偽値の二つの値」つまり「零と一」しか理解できない。
よって、自然言語を情報処理する為には、言語を記述する為の文字を、数単位の長さで符号化したものを用いて処理がしやすいようにするのである。
UNICODEに反対する人が居るといったけど、何がいけないのだろうか。
文字符合の単一符号化は、彼らの言うように日本語などの漢字を使う文化圏に悪影響を与えて
文化の失墜なるのだろうか。
元来、日本語の場合は漢字などを使わずに表記されていたはずである。
文学的価値の高いホツマツタヱのような漢字を使わなくても、わかりやすい文体をしている文献もあるにはある。
漢字を日本語に地域化する為に、「訓読み」や「レ点」および「
送り仮名」といった涙ぐましい先人の努力があって「現代の日本語の元」が出来てきたのである。
さらに現代の日本語は欧州圏の言語の影響でアルファベッドとカナと漢字が入り交じった文体をしている。
つまり、現代日本語は言語文字文化の単一化と日本語への地域化で成り立っているのであり、単一符号化文字集合体は、日本語の
文化失墜の要因になるとは言い難いものがある。
よって、正しい手順で設計された単一符号化文字集合体は、日本語情報処理にとって有利なものと成る筈である。
UNICODEに反対意見をっ持っている人たちは、現在のUNICODEは収録する文字の調査が正しく行われていないと指摘をしている。
また、JISにも誤りがあって、奇妙な字が幾つかある。
漢字で日本語特有な文化といえば、訓読みであり、JIS第一水準漢字に反映されているが、第2水準以降は 画引きとなっている。
日本語を順列化する規則にあいうえお順に並べる習慣があるが、現行で使われているJISの符号化集合体にある
漢字符合を並べ替える事をしても満足な結果が得られない。
これは、実際の日本語と漢字に直行性がないため、たとえあいうえお順に符号化しただけでの符号で、並べ替えは成功しないのである。
一般的に、あいうえお順に並べ替えをするには、かな文字だけで書いた読みを用意して、それを手がかりに並べ替えをする。
かな文字の読みがない場合は、読みかな辞書を参照して、読みを生成する必要がある。
日本語を入力をする時には、ほとんどの場合はかな漢字変換処理によって行なわれて、符号化漢字表から対応する符合を人間が探してくることは、きわめてまれである。
符号化漢字表が必要となる場合は、訓読みで調べる場合よりも画引きで調べることが多い。
このような事情を、考えるとJIS並びを捨て去っても大きな影響はない筈である。
UNICODEのような大規模な文字集合体を、小型携行端末に全ての漢字を支援するのは、搭載するメモリの大きさから制限を受けることになるので、使用文字数を制限したいと考えるもの一理あるかも知れない。
だが、第１水準、第２水準、第３水準、第４水準と制限を設けたところで問題は解決しない。
なぜならば、符号化された文章が流通するからには、規定された全ての符号化文字集合のなかから使われることになるからである。
これは、規定された文字集合の全てを支援しなかった場合は、流通した文章を読むことができないことを意味する。
拡張文字集合が扱えない端末を考慮して、敢えて追加文字を使わないようにするならば、拡張文字集合体の設計をすることにどれだけの意味があるか疑問になってくる。
自然言語が記述してある任意の文字列について考えてみる。
いろんな言語で書かれた一つの書類があるとする。
この書類からどのような言語が使われているかは、知識のある人間なら一目で理解できることであろう。
しかし、人間がとくとする処理の大部分は、電子計算機の苦手な処理である。
ある言語文化圏の文字集合体が一つだけの言語にしか使われないのならば、電子計算機では 単一符号化文字を使う場合には論理積をとる事によって、その符号化された文字がどの言語で使用されているかは、簡単に特定することが出来るので、文字列のどの部分が何某語で書かれているかはすぐに判る筈である。
しかし、実際の言語では、一つの文字集合体は複数の言語圏で使われていることが多いのである。
たとえば、キリル文字は（ソ連時代の影響？）中央アジア付近で多くの言語が使用しているし、漢字は中国、日本、韓国（少し前のカンボジア付近でもつかわれていたらしい）で使われているし、アルファベットだって使われるのは英語だけではない。
複数の言語で書かれた書類が、どのような言語で書いてあるか目印の無い文字列から言語を特定するのは、容易でないことが想像できる。
統合漢字集合体で書かれた文章が、どの言語で書かれたかをどのようにして区別すれば良いか。
東アジア人の言語を判別するアルゴリズムとしてUNICODEのFAQには、漢字のテキストに、かな文字またはハングル文字が含まれているはあいは、日本語か韓国語と判断するとあるが、これは本当に正しいのか。
今の所他国語処理のできるシステムが普及していないので、普通は一つの言語でかかれていることがおおいだろうから、このルールはうまく動くだろう。
しかし、中国語の文章のなかにハングル文字や平仮名が入った文章は、韓国語や日本語なのか。
答えは、そうではない。
たとえば、中国語でかかれた日本語や韓国語の教科書や旅行案内などを考えてみよう。
中国語で、ハングル文字でかかれた言葉やの説明や、かな混じり文章の日本語を説明した文章は、日本語や韓国語ではなくってやはり中国語の文章であろう。
単純に文字集合を統合すると、このような弊害をもたらすだけである。
もし、特定するとしたら計算機科学が不得意な人工知能分野の技術をつかうことになるだろう。
言語を特定することを毎回行っていたら、強力な計算機情報処理が不得意な処理によって望めなくなるであろう。
つまり,国際化時代に沿う多言語情報処理では、文字列の中で何処の部分が何言語で書かれているのかを、 管理することが必要である。
単一集合へ統合することで、言語を識別するという機能実現が難しくなるのでその真価にはかなり疑問がある。
このことは、読み上げソフトや翻訳といった分野のアプリケーションにおいての効率に影響されることが予想される。
JISにUNICODEに間違えがあるのは、調査収集した資料に(康煕字典や転記における間違えなど）誤りがあったことを認めることが出来ずに、信用してしまったことが要因らしい。
( Bit誌1997年10月号参照）
調査対象の資料に誤りがあっては、身も蓋もない。
結局何を求めているか。
といった、ごく当たり前のことが、要求される。
単純にISO国番号を言語コードにしてはいけない。
なぜならば、一つの国に多数の民族と文化が存在するので、一つの国の中には多数の独自に発達した言語が存在する。
たとえば、インドなどがこれにあたり、たくさんの民族と言語が存在して、地域ごと独自に言語が発達している。
JIS符号化文字の見直し検討に関する資料はこちらをクリック。
他国語処理で参考になりそうなホームページのリンク集
TRONの文字図形計画は、すでにある国家規格などの地域規格をそのまま使用することで、統合作業から逃れることができる。
言語調査には、多くの時間と資金が必要であるが、即存の地域規格を信頼する事で、Unicodeに比べて大幅な省エネである。
文字図形実装面を切り替える管理によって、地域化に必要な符号化文字を選択することによって、言語情報が失われることがない。
文字図形符号化計画が変更になった地域があっても、文字図形実装面が異なる（結合強度が低い）のでほかの地域の文字図形符号化計画に干渉する事はない。
難しい話は抜きにしてコード設計の例
日本国内に"Understanding Japanese Information Processing"の付録及び追加情報があるoreillyのミラーサイトがある
著作権1996年1997年1998年 © 大槻昌弥
[EOF]