目次


Unicodeの知らざる世界

Comments

少し前のことですが、Unicodeのメーリング・リストに、Unicodeの利点のリストを作成する手伝いをしてほしいというリクエストが現れました。このリクエストは、興味深い対話を巻き起こしました。それがさらに面白さを増したのは、「弱点についてはどうですか」という、当然の反問が出されたときでした。Unicodeの歴史的な経緯や修正の提案とともに、さまざまな意見が沸き起こりました。(この議論へのリンクについては、参考文献を参照してください。)

この記事は問題含みの分野を要約したものです。

不満の種としては文字セットの制限もありますが、Unicode自体の問題ではなく、実は実装上の課題といえるものもあります。

興味深いことに、ユーザーが常用する用字(ラテン文字、カタカナ、漢字などの文字の種類)のタイプに基づいて、不満の表し方に基本的な違いがあるようです。CJKV (中国語/日本語/韓国語/ベトナム語) の用字に関する不満は一般的で大まかな傾向があり、変更を行うことに焦点が向けられる傾向はありません。対照的に、英字用字に関する不満は具体的なものになる傾向があり、変更を行うことに関心が向かうことが多いようです (たとえば、文字を追加したり規則を変更したりすることを要求します)。

現在のUnicodeへの多くの不満の声は、既存の規格との互換性を保つ必要性から生じたものです。Unicodeと他の文字セットとの間で変換が可能であることは、不可欠な条件でした。Unicodeの発展の過程で、Unicodeが他の文字セットとうまく協調できるようにするためには、多くの設計上の妥協が必要となりました。

しかし、言い訳はこれくらいにして、各項目に目を向けましょう。

東アジアでの問題点

日本や中国でのユーザーの多さ、および東アジアの文字セットの複雑さを考えると、CJKVに関する不満の声が多いことは驚くに値しません。真実をありのままに言えば、日本と中国のユーザーはUnicodeを信頼していません。新しいすべてのオペレーティング・システム、開発ツール、およびテクノロジーがデフォルト文字セットとしてUnicodeを使用するようになっている現況から考えれば、信じがたいことではありますが、日本では依然として (特に、マルチリンガル・ソフトウェアの研究にかかわっている人の間で) 抵抗が強いと言わざるをえません。コンソーシアムのメンバーに多くの日本人や他の東アジアの人々が含まれているという事実があるにもかかわらず、日本語に関する問題の判断が、日本語に生まれつき親しんではいない人々によって下されてしまったという点についてのこだわりもあります。

このセクションでは、CJKV文字および言語に関する最大の関心領域について取り上げます。

漢字の統一(Han Unification: 漢字の字形包摂)

中国語、日本語、韓国語、およびベトナム語をサポートするためには、数千という表意文字のエンコードを用意しなければなりません。これらすべての表意文字のサブセットが、これら4つの表記システムで使用されています。その文字の集合は、漢王朝時代に中国で誕生したことから、漢字と呼ばれています。漢字の統一は、漢字に単一コード・ポイントを割り当てるプロセスです。その結果コード化された表意文字の集合はUniHanと呼ばれます。

漢字の統一の問題は、おそらく、CJKV文字サポートに関して最も頻繁に漏らされる不満です。しかし、漢字が同じであるとしたら、なぜこれほど不満が寄せられるのでしょうか?

問題の根は、Unicodeが、文字の視覚的表現である「グリフ」(文字イメージ)ではなく、文字をエンコードするという事実にあります。東アジアの字形には、中国語 (繁体字)、中国語 (簡体字)、日本語、韓国語の、4つの基本的な伝統があります。漢字の元になる文字は、CJK言語で同じであるようですが、同じ文字について一般に使用されるグリフは、同じではないことがあります。

たとえば、中国語 (繁体字) で「草」を表すのに使用されるグリフでは、草を表す部首の草冠が4画ですが、中国語 (簡体字)、日本語、および韓国語のグリフでは3画です。しかし、書記体系とは無関係に、「草」の字に対応するUnicodeポイントは1つ (U+8349) しかありません。また別の例としては、"1" を表す漢字は、中国語、日本語、および韓国語で異なっています。多くの人々は、3つのバージョンを異なるようにエンコードすべきであると考えています。

フォントはグリフを表示するための伝達メカニズムです。つまりこのことは、漢字は統一されているとしても、フォントは統一できないことを意味します。異なる書記体系への要求を満たすために必要なグリフの異字体を用意するには、フォントは、使用される書記体系に固有なものでなければなりません。1つのフォントだけを使用するようにすると、いくつかの文字については、すべての人に対して正しく表示されないことになってしまいます。

漢字の統一に対する不満の一部は文化に根ざしているものです。単に文字だけでなく、言語自体が意に反して混ざり合わされているというように理解されているのです。これまで使用していた文字セットとエンコード方式が言語固有のものであることを考慮すれば、こうした誤解は理解できます。古い文字セットが組み合わされてUnicodeに統一された場合には、言語まで統一されたような気になります。東アジアの文化は独特で多様であるため、少しでも言語を併合しようとする試みが行われた場合には、根拠がある不満が生じるでしょう。この場合がそうであるというわけではありませんが、統一の行い方について、なんらかの混乱があることは確かです。

表意文字の数

日本、中国、および韓国のユーザーが日常的に使用する必要のある文字は、実際に存在する表意文字の巨大な集合に比べると、比較的少数です。その一方で、言語学者、歴史学者、政府関連の記録保管係、および古文書研究者などの専門的なユーザーは、必要とする表意文字に簡単にアクセスできない可能性があります。

大きな問題点は、新しい表意文字を必要に応じてその場で作成するのは難しいということです。1つの対応策として、新規文字を図形で表現する方法があります。すなわち、図形文字を既存のコード化された表意文字または図形記述を生成するための他の記述コンポーネントと結合させることにより、Ideographic Description Sequence (表意文字記述シーケンス; IDS) が作成されます。ユーザーはこれにより、記述を見たり、意図した結果の視覚化を試みたりすることができます。このレンダリング・エンジンは、IDSから実際のグリフを作成するわけではありません。これは、「ウムラウト付きのu」という記述を読み取って文字 "a" を視覚化しようと試みるのに似たところがあります。明らかにこれは、最適な解決策ではありません。

この話題については「新規文字の追加の難しさ」というセクションでさらに触れます。

部首の取り扱い

部首 とは、索引付けに使用される漢字の構成コンポーネントのことです。辞書および索引は部首の順に配列されています。理論的には、漢字は表意文字全体ではなく部首ごとにエンコードすることが可能です。そうすれば、文字のソートと組み立てがその場で行えるようになります。部首をエンコードすると、コード・ポイントの数は、現在CJKVのサポートに必要とされている数万の表意文字に相当する数ではなく、数百で済むはずです。

この方法の問題点は、現在のところ、部首から表意文字を組み立てるのに十分な機能を持つレンダリング方式が存在しないということです。Unicodeは、一般的に使用されている部首と位置決め文字を追加しましたが、部首を用いて文字をその場で作成できるようになるまでには、まだ長い道のりを必要とします。

日本の人名文字

外字 とは、コンピューター・システムに頻繁に入力する必要があるにもかかわらず、Unicodeセットに含まれていない、日本の珍しい人名文字のことです。現行のサポート・メカニズムでは、個々の実装担当者がUnicodeのPrivate Use Area (私用域) に外字を追加できるようになっています。(私用という概念は、既存のCJKV文字セットにも存在します。)この方式によってサポートは提供されますが、Private Use Areaに入力された文字は、公式のコード・ポイントには割り当てられません。システム間で連絡が取れるようにするためには、どのような項目がPrivate Use Areaに追加されて、それらがどのように割り当てられているのかを、すべての当事者が理解していなければなりません。これは、一般的に広い範囲で使用するためには、明らかな制限となります。

この話題については「新規文字の追加の難しさ」というセクションでさらに触れます。

タイ語の配列

タイ語サポートに関する主要な不満は、文字が論理的な (話された) 順序で保管されないということです。これによって、Unicodeの照合アルゴリズムの使用が面倒になります。このような配列が行われるのは、Unicodeがタイの工業規格を継承したためです。これは、結合用の記号(virama)を使用しないで表示の際に順序が変わる(reordrant)母音記号の視覚的な配置を採用した、タイプライターを基にしたものです。この欠点はすでに認識されていて、論理的に配列された母音記号の小さなセットがタイ語ブロックに追加されました。残念ながら、UnicodeがISO 10646と共同歩調を取ったときに妥協が図られ、古い規格に合わせるために、これらの論理的に配列されたタイ語の母音が除去されてしまいました。

競合する文字セット

東アジアの言語のサポートに関連するすべての問題への対応として、いくつかの代替マルチリンガル文字セットが、主として日本で開発されました。これらの文字セットについては以下で説明しますが、どれもUnicode規格のまともなライバルとは言えません。Unicodeはほとんどのソフトウェア製品によって使用されていますので、これらの文字セットは、それに比べるとはなはだ小さな存在です。(たとえば、Unicodeは現行のMicrosoft Office製品群に使用されています。)

TRON
TRONの売り物は、漢字を統一していないということです。逆に、すべてのグリフの異字体を区別しようとしています。超漢字3という商用実装版は、171,500文字をサポートしていることをうたっています。TRONは日本でもUnicodeほど広くは使用されていませんが、アンチUnicode派の技術コミュニティーの間では人気があります。

UTF-2000
UTF-2000文字セット運動の目的は、柔軟な抽象文字データ・タイプを提供することです。ユーザーが定義したグリフを使用して文字を表示できるようなフレームワークを提供しようというアイデアです。(注: 英語圏の人々にとって、UTF-2000について学ぶことは困難です。オンラインで使用可能な情報のほとんどが日本語で書かれているためです。参考文献)

Giga Character Set (ギガ文字セット; GCS)
GCSは、Coventive Technologiesによって作成された表示コード体系であり、Unicodeにおける周知のCJKVの欠点を克服することをうたっています。GCSは、バイナリー・コードを文字に割り当てるのではありません。これは、自然言語の文字とコンピューター・ビットとの間の変換に使用される、暗号化アルゴリズムのセット (言語ごとに1つずつ) です。GCSは、文字を検索するのではなく、演繹するため、Unicodeよりも高速で、必要なメモリーも少ないと主張しています。

他の用字に関する問題

双方向テキストの振舞いは、アラビア語、ヘブライ語、その他の用字にとって課題となっています。これらの言語では、ほとんどのテキストが右から左に向かって書かれるのに対し、一部のテキスト (数字、西洋人の名前など) は左から右に書かれます。多くの用字の場合、位置による形式がユーザーの悩みを増加させます。新しい文字が入力されるごとに画面上でテキストが「踊る」(フォームが変化する) からです。

下記に述べるユーザー入力の問題があるため、多くのユーザーは、新しいWYSIWYGアプリケーションよりも、ビジュアル・マークアップ言語を使用する古いワード・プロセッサーに頼っています。ユーザーは、古いシステムを使用するとテキストをうまく制御できると感じているのです。

双方向の結合したテキストの問題に対処するためには、テキスト入力方式をより洗練されたものにする必要があります。方向情報を「状態」情報とともにテキストに組み込んで保管し、ユーザーの操作をより気の利いたやり方で処理できるようにしようという解決策が提案されています。

こうしたさまざまな障害があるため、双方向用字の問題は、基本的には、実際のUnicodeの制限事項というよりも実装方法の課題であるといえます。

文字の挿入

双方向用字を扱うときには、センテンスの途中まで戻ってテキストを挿入することが困難な場合があります。ユーザーは、画面を見てカーソルを位置付けることができますが、入力したテキストは、論理位置に基づいて、別の位置に表示されることがあります。その結果、ユーザーは、希望する個所にテキストを挿入する前に、何回か試さなければならないことがあります。これは、視覚的な配列ではなく論理的な配列が使用されているためです。実装担当者は、論理的なバッファーおよびカーソルを使用して、位置変換テーブルによって視覚的な位置から論理的な位置へのマッピングを行います。この変換テーブルが論理位置へのジャンプの原因となります。

位置による文字の踊り

多くの書記体系では、センテンスにおける文字の位置、およびその前後に他の文字があるかどうかによって、その文字がどのような形になるのかが決まります。このような、文字の状態の変化は、位置による形式(positional form)と呼ばれます。現行のUnicode実装版では、ユーザーは、新しい文字を追加するたびに画面上の文字が踊るという現象に直面します。位置による文字の性質の変化を理解するためにデモを眺めている、われわれのような人間にとっては、この変化は面白いものですが、簡単なセンテンスを入力する必要のある人にとっては、気が散ってしかたがないでしょう。

ゼロ幅文字

用字によっては、特定の機能を行うためにゼロ幅文字が必要になることがありますが、ユーザーにとってはこれが混乱の種になります。ゼロ幅文字 (ペルシア語のZWNJなど) がセンテンス内にあると、ユーザーがその上でカーソルを移動させようとしたときに、カーソルが移動したように見えないことがあります。さらに困ったことに、削除を行う場合、ゼロ幅文字の存在によってカーソル位置が正確に表示されないために、ユーザーが誤った文字を削除してしまうことがあります。

双方向文字の実装上の問題

双方向文字の実装により照合アルゴリズムと数値処理を扱うためには、ロケール情報が必要です。たとえば、西洋数字は、ヘブライ語では通常の数字として扱われますが、ペルシア語では外国の数字として扱われます。

特にWebオーサリング・ツールでは、洗練された双方向文字の取り扱いが要求されます。こうしたアプリケーションは、正しい方向を示すタグ (これは、< と > で囲む必要があります) を効率よく扱うための、適切な方法を備えている必要があります。

言語間の問題

Unicodeに対する批判の中には、特定の用字のタイプへの適用ではなく、一般的な事柄に関するものもあります。そうした一般的な問題について以下に述べます。

規格、規格、規格

規格は、物事を行いやすくするものであると思われていますが、そうなのでしょうか。信じられないかもしれませんが、Unicodeの主要な問題は既存の規格なのです。Unicodeは、既存の規格に満ちあふれた世界で開発されたものであるため、コンソーシアムは、それらとの整合性が保てるような設計上の妥協を強いられました。既存のコード・ページやその他の規格との互換性は、規格を複雑にしてしまいました。

限られた数のコード・ポイント

批判者の中には、Unicodeが、いつかコード・ポイントを使い尽くしてしまうのではないかと心配する人もいます。TRONなどの競合文字セットは、「無制限に拡張可能」であることを売り物にしています。GCSはUnicodeの主要な弱点として文字制限を引き合いに出し、コード・ポイントではなく暗号化アルゴリズムを使用してそれに対処しています。

こうした心配が現実的であるかどうかについては、議論の余地があります。Unicodeがコード・ポイントを使い尽くして新規文字を受け入れられなくなるころには、テクノロジーが進化し、Unicodeの有効寿命が尽きてしまっている可能性が高いからです。

処理の不整合

Unicodeに関するもう1つの不満として、用字ごとに処理上の不整合が多く存在するということがあります。1つの問題には、複数の解決策があります。多くの不整合は、既存の文字セットとの互換性を保つための努力の結果なのです。不整合に関する最大の問題は、複数の用字をサポートするシステムの開発が困難になることです。単一の用字の実装を行う場合、不整合が問題になることはあまりありません。

いくつかの例を示します。

位置による形式の取り扱い
Unicodeの不整合の1つは、位置による形式の取り扱い方法に関するものです。アラビア語、シリア語、およびモンゴル語の場合、それぞれの文字の位置による形式は、同じコード・ポイントによってエンコードされ、レンダリング・エンジンが正しい形式を選択するようになっています。ギリシャ語とヘブライ語では、最終形式と非最終形式に、それぞれ固有のコード・ポイントが割り当てられています。

付加文字
インド、チベット、および東南アジアで使用されている、ブラフミー文字を起源とするいくつかの用字では、連続した子音のクラスターを形成するために、付加文字が使用されます。インドの用字に関して、Unicodeでは、付加文字をviramaと子音の連続によってエンコードします。その他の、チベット語などの用字では、付加文字を固有の文字として直接エンコードしています。

論理的な配列と視覚的な配列
用字によって、論理的な配列を使用するもの (たとえば、インドの用字) と、視覚的な配列を使用するもの (タイ語やラオ語など) があります。

ASCIIの取り扱い
ASCIIは、Unicode文字セットの最初の256文字となっています。この規格のうちの他の部分はブロック単位で編成されていますが、ASCIIのコード割り当ては、それとは異なり、基本的にランダムです。

新規文字の追加の難しさ

言語は進化し続けます。このことは、新しい文字が追加され続け、古い文字が変化し続けることを意味します。Unicodeに新規文字を含めることは、すぐにできることでも、簡単なことでもありません。(Private Use Areaを使用して) 新規文字を定義したり、(Ideograph Description Sequencesを使用して) 表意文字を記述したりするためのメカニズムは存在していますが、これらのいずれの方法も、実際に文字を文字セットに追加するわけではありません。

さらに、Private Use Areaは、いくつかの相反する方法で使用されています。各当事者が同じ使い方をするように合意していないと、文字が不要情報になってしまいます。現在のところ、動的に文字を定義したり、その文字をエンコード、デコード、または変換するための方法をブロードキャストして、一般に知らせたりするための、標準メカニズムは存在しません。

等価文字の混乱

Unicodeは特定の文字を生成するためのさまざまな方法を用意しています。つまりこのことは、読者が画面である文字を見たときに、その作成に使用された方法が分からない、ということを意味します。たとえば、ü はu+00fcと表現することも、それと等価なu+0075 + U+0308と表現することもできます。これらの対等の文字は等価文字 と呼ばれます。等価には、互換 と正規 の2つのタイプがあります。等価性は、検索ルーチンの実装を困難にし、一般に混乱の原因となります。

事前形成された形式と分解された形式

複合文字は、事前形成された文字と分解された文字の、2つの方法で表現することができます。事前形成された文字は、それ以外の1つの文字の連続、または複数の文字の連続と等価です。分解された形式は、文字の基本構成単位に分けられています。分解された文字は、柔軟性が非常に高く、規格に追加するために必要となる作業が少なくて済みます。場合によっては、処理要件の関係で分解された形式以外に選択肢がないこともあります。

Webプロトコルでは、事前形成された表記が好ましい方法と見なされ、既存のソフトウェアではこのほうが多くサポートされています。

その結果、基本的には事前形成された表記であって、事前形成された形式が利用不能な場合には分解された表記が挿入されるという、混合形式が生じます。ソフトウェア実装担当者は、正しい実装を行うためには、両方の形式をサポートする必要があります。残念なことに、実装にあたってはいずれか一方だけがサポートされ、両方はサポートされないことが多いようです。

Unicodeは国際化対応と同じではない

どういうわけか、Unicodeすなわち 国際化対応であるという考え方が形成されています。ソフトウェアを「Unicodeバージョン」と名づければ、それが世界中のどこにでも出荷可能であることを意味するようになりました。実際には、Unicodeは、国際化対応を容易にする文字セットなのです。ある賢明な国際化対応エキスパートがかつて言ったように、Unicodeは国際化対応に関する問題を解消するものではなく、そうした問題をより面白くするものにすぎないのです。

結論

こうした批判がどれほど重要なものであるのかは、個人的な視点によって大きく左右されます。ある問題が重要で別の問題が些細であると言うことは困難です。なぜなら、ある問題が、あなたの製品の完成に影響するのであれば、その問題があなたにとって重要なのです。たとえば、日本語の姓を入力できるようなシステムを実装しようとしている場合、外字サポートの問題は重要です。しかし、双方向テキスト入力という課題は、まったく重要ではありません。逆に、ヘブライ語のワード・プロセッシング・パッケージを作成しようとしている場合には、外字がエンコードされるかどうかということには、あまり神経を使うことがないと思われます。しかし、ゼロ幅文字の取り扱いについては、胃が痛くなる思いをするかもしれません。

Unicodeは、世界中のあらゆる文字を取り扱うという課題に対する完全な解決策ではないとしても、私たちが広範囲な言語を扱えるシステムを作成できるようになるために、大いに貢献しています。Unicodeの進化の過程で、実世界の要求を満たすために当初の設計目標が進化させられたり、ある場合には取り下げられたりする必要が生じています。

どのテクノロジーについても言えることですが、Unicodeも、より優れた機能を持つものに取って代わられることは間違いありません。

いつかは必ず。

しかし、それがすぐに起こる可能性はなさそうです。Unicodeは現時点では、世界のマルチリンガル・コンピューティングの要件を満たす、長く待ち望まれた定評のある解決策なのです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology
ArticleID=232919
ArticleTitle=Unicodeの知らざる世界
publish-date=05012001