本書では、アイヌ語について所々で触れています。JIS X 0213に触れる以上当然かなというぐらいで読んでいたのですが、著者が札幌出身ということもあるんでしょうね。
確かにそういう面はあるのかもしれません。が、そればかりではもちろんない。
拙著で私はなぜアイヌ語を取り上げなければならなかったか。それを説明するのに、どういう状況ならば取り上げる必要がなかったかを挙げてみましょう。
- アイヌ語を書くための片仮名がJIS X 0208に含まれていて既に広く実装されていたら、敢えて取り上げる必要はなかった。
- JIS X 0213の符号化方式が広く実装されていて当たり前のものになっていれば、敢えて取り上げる必要はなかった。
- Unicodeで結合文字の処理なしにアイヌ語用の文字が処理できれば、敢えて取り上げる必要はなかった。
端的にいえば、日本国内の言語、それも消滅の危機にある言語にもかかわらず、アイヌ語情報処理環境が悲惨な状況にあるからにほかなりません。規格上のサポートは2000年に至るまで存在しなかったし、実装面ではJIS2000以降も実に惨憺たる状況でしかなかったのです。(ただ、最近のMac OS Xのようにアイヌ語のローマ字仮名入力方式やShift_JIS-2004を実装する製品があるなど、例外もあることは付け加えておきます)
ではこの悲惨な現状を少しでも良くするにはどうすればいいか。考えるに、手っ取り早いのは、JIS X 0213の符号化方式、つまりShift_JIS-2004やEUC-JIS-2004を実装することでしょう。
なぜかというに、Shift_JIS-2004やEUC-JIS-2004を実装すれば、いやでもアイヌ語用の片仮名が含まれてくるからです。もしShift_JIS-2004やEUC-JIS-2004を謳うにもかかわらずそれらの文字を正しく扱えないなら、それは単にバグだといえます。
一方、Unicodeだとそうはいかない。「UTF-8に対応しています」といったところで、結合文字を含んだテキストをきちんと扱えるかどうかは分からない。アイヌ語に頻出する「ㇷ゚」のような文字が正しく処理できるかどうかは、UTF-8という表明からは伺い知ることができないのです。Unicode対応のソフトウェアなのに結合文字を使ったテキストの表示が壊れている例は拙著第3章の終わりの方でも取り上げました。
アイヌ語テキストの処理をしたいという要求が少数派のものであることは確かでしょう。しかし少数派だから切り捨てていいかというと、もちろんそんなことはない。多数派が便利になるように設計することは当然のように思われるかもしれないけど、やや大げさにいえば、多数派というのは実はどうでもいい。多数派はその定義上、マンパワーが大量にあるのだから、不便なままほっておいても誰かが解決策を作ってしまう。でも少数派はそうでないのだから、少数派に不便を強いることは、単に不便なだけでなくそれを解決する人もいないという、いわば不便の2乗になってしまう。多数派に便宜を図って少数派に不便を強いることは、少数派をますます少数派にしてしまうことになるのです。
日本の文字コードがアイヌ語の表記に必要な文字を含むことは、当然の義務とさえ言えるでしょう。規格上は既にできているのだから、あとは実装です。
コメントする