モンゴル文字は、主にモンゴル語表記のための文字*1である。縦書き専用の文字であり、日本語の場合とは反対に左から右へと行を進める。また、アラビア文字のように続け書きされ、文字が語のどの位置に来るかによって形が変わる。
モンゴル文字は現在も中国の内モンゴル自治区でモンゴル語の表記に現役で使用されている。他方モンゴル国ではソ連の影響下でモンゴル語の表記をキリル文字に切り替えたので、モンゴル文字は学校で習いはするものの一般にあまり使われない。
Unicode 3.0からモンゴル文字がシベ文字・トド文字・満州文字と統合されて収録されているため、コンピュータでこの文字を入力するにあたっては、独自の符号化方式を作成するのでなければUnicodeを利用しようとするのが当然に思える。しかし、現状のUnicodeモンゴル文字は致命的な欠陥を抱えている。
このエントリでは、2017年ころからUnicode Technical Committee (UTC)で盛んに議論されているUnicodeモンゴル文字ブロックの問題点と、その改善に向けた動きを、現代モンゴル語の表記を基本として見ていく。
Unicodeのサイトに、モンゴル文字に関するUTC文書がまとめられている。この記事はその最近の文書の内容を元にしている。
致命的な欠陥: 相互運用性がない
Unicodeモンゴル文字の最大で致命的な問題点は、エンコーディングのレベルで相互運用性(interoperability)がないことである。平たく言い替えると、機種依存文字状態になっている。
喩えを用いるのは不適当かもしれないが、ラテン文字の符号化で考えると、
- 大文字小文字は統合し同一コードポイントとする
- 大文字小文字の区別のためのvariant selectorを用意し、文字に後置するかしないかによって大文字小文字を区別する
- 一方、variant selectorを付けた場合と付けない場合のどちらが大文字でどちらが小文字かが未定義なため、両方式のフォントが共存していて、互いに互換性がない
といった状況である。
現状のエンコーディングでは、モンゴル文字の表示はフォント依存である。これは、Unicode公式で明文化されている規則だけではフォントを実装するには情報が足りず(underspecified)、各々のフォントベンダがそれぞれの解釈で実装を進めた結果、ベンダ間で実装が非互換となっている。あるフォントでは正しく表示されるUnicode文字列が、別のフォントでは正しく表示されないということが普通に起こっている。
一例として、「良い」という意味の単語(キリル文字表記はсайн)を挙げる。次図は、L2/17-334 On migration issues of the graphetic modelのAppendixからの引用である。
縦は3種類のコードポイントの並びを、横は8つのフォントベンダの実装を示す。黒い単語は正しく表示されているものを、グレーは単語が正しく表示されていないものを表す。フォントベンダは、左からMenksoft (中国)、Delehi (Almasとも, 中国)、IMUCS (中国)、Founder (中国)、Huaguang (中国)、Bolorsoft (モンゴル国)、Microsoft (米国)、Google (米国)である。
どのコードポイントの並びをとっても、全てのフォントで正しく表示できるものは存在しないことが分かる。
ここで挙げられている三種類のコードポイントの組み合わせについて、一体どれが正しいのかというと、Unicodeでは規定されていない。つまり、誰も「何をどう表示すれば正しく実装できたといえるのか」が分かっていないという状態である。
どうしてこうなった: 音声情報の符号化
モンゴル文字が元々複雑だからというのが一つの原因ではあるが、もう一つの原因は現状のUnicodeモンゴル文字が音声情報ベースの符号化であることである。
X3L2/96-054 Joint proposal draft on encoding Mongolian Character Setは1996年にモンゴル国と中国が共同で作成したモンゴル文字符号化の草案であるが、その中で、符号化の方針として次のような記述がある。
● To guarantee the information integrity(not to lose the information) , different characters of the same glyph are coded separately.
The main principle to abide by is “No Information loss”.
(略)
② The sound information of Mongolian is very important especially in data indexing and searching. In many cases, a letter is of different pronunciation and different meaning accordingly. It is rather necessary to encode them all . This will contribute greatly to the information processing of Mongolian script.
http://www.unicode.org/L2/L1996/96054-n1368-mongolian.pdf
という訳で、形が同じだが別の音を表すものであるなら別々の文字としてコード化すべき*2だと言い、音声情報を符号化することを強く推している。
その後の議論については読んでないので分からないが、現状のUnicodeモンゴル文字ブロックも基本的にこの方針でエンコードされている。
この音声情報を符号化することが混乱を引き起こしている。
音声情報ベースで符号化を行うと、ソートが簡単になる、また異音同綴語を区別できるなどの利点はあるが、レンダリングが複雑になり、文字の入力や照合に混乱をもたらすなどの欠点がある。
音声情報を符号化するというのは、モンゴル文字のラテン文字転写とだいたい一対一の対応がとれるということでもある。モンゴル文語の文法書においてはラテン文字転写で説明されていることも多い。
転写とは文字の音声的な特徴を写し取ったもので、形の情報を区別しないことがある。そのため、転写は、一部の文字についてはモンゴル文字で書き分けない文字を書き分けるし、別の文字についてはモンゴル文字で書き分ける文字を書き分けられないという特徴がある。これが転写ひいては符号化されたコードポイントとモンゴル文字の字形との間の対応のずれとなり、どうにか対応付けをするために複雑な仕組みを必要としている。
音声情報を符号化したために、モンゴル文字の形状の複雑さはシステムやフォント側が引き受けることとなった。
モンゴル文字がどのように複雑だったり、混乱を招いているのかを見ていく。
モンゴル文字は、語の中のどの位置にくるかによって、また母音調和等によって形が変化する。
モンゴル語における母音調和とは、男性母音(a, o, u)と女性母音(e, ö, ü)の2つの母音系列が、原則一語中で混ぜて使われないというものである。他に、どちらの系列とも共存できる中性母音(i)がある。
母音が男性母音または中性母音からなる単語を男性語、女性母音または中性母音からなる単語を女性語という。中性母音のみからなる単語は女性語となる。
子音によっては、男性語と女性語で別の形を使うものがあり、例えば、U+182D MONGOLIAN LETTER GAは、次のように7種類以上の字形に変化する(赤部分。実際には母音等の文字とリガチャになっているものもありフォントグリフとは一致していないので注意)。
このように同じコードポイントの文字を、システムとフォントによって適切な形で表示する必要があるのだが、その規則は明示されてない部分も多いため、手探りで実装することになる。
二重母音のi
母音のiは次のような形を取り得る。
語中のiは基本的に「すね」(左下に突き出る斜め線のこと; шилбэ 脛)が1本でかかれる。
一方で、本記事の冒頭で掲げた「良い」という意味の単語(キリル文字でсайн)は、「子音s + 二重母音ai + 子音n」という構成になっているのであるが、語中の二重母音の二番目のiは「すね」が2本となり、これを“i”で転写する方式と“yi”と転写する方式とがある*3。それぞれに従うと「良い」сайнの転写は順に“sain”, “sayin”となる。
他方、二重母音の2番目にくるiはすべて「すね」2本なのかというとそうではなく、数字の8(キリル文字でнайм)とその派生語については例外的にiは「すね」1本でかくため、「良い」сайнを“sain”とする場合、同じ“i”でも「すね」が1本のときと2本が存在することになる。
また、本来の文字yは基本的に「すね」の先が上に跳ね上がった形でかかれる。そのため、二重母音の「すね」2本のiを“yi”で転写するポッペ式における“sayiqan”という転写は、
- сайхан「素晴らしい」(yはまっすぐな「すね」)
- саяхан「つい先ほど」(yは曲がった「すね」)
のどちらの語をも表しうる*4。
このように、同じ文字が単語ごとに正書法によって複数の形に書き分けられるため、文字の形を変更するvariation sequenceという仕組みが存在している。これは、形を変更したい文字にvariation selectorという専用の符号を後置することで、文字を望んだ形に変更するという仕組みである。しかし、どれを本則として、どれをバリエーションとするかについて定義が不十分であるため、混乱がある*5。
まとめると、冒頭で掲げた「良い」(сайн)という単語は、
- 語頭・語中の二重母音aiを転写するのに“ai”と“ayi”のどちらを使うか*6。両方採用することも可能。
- “ayi”を採用する場合、「基本はyをまっすぐな『すね』で表示して、曲がった形にするためにvariation sequenceという仕組みを用いる」か、あるいはその逆か
という2つの分類で説明できる。
繰り返すがこれについてはどれが正しいかというものは規定されていないため、どの方式にも理があるが、互換性はない。
書き分けない文字に別々のコードポイントを当てる
他にも、同じ見た目の文字でも音が異なるならば別々にコード化するという方針により、語中のどの位置でも書き分けのないo, uに別々のコードポイントが与えられている。ö, üについても同様である。他にも書き分けのない文字はあるが省略する。
モンゴル語を理解する人は発音が分かるので、どちらを使えばいいか分かるのではないかという考えもあるかもしれない。しかし、モンゴル文字表記が作られてから時間が経っているため、綴りと発音が乖離しており、発音からo, uのどちらだとわかるとは限らない。また、モンゴル語ではアクセントの関係で、第一音節にある母音ははっきりと発音されるが、第二音節以降の短母音は弱化して曖昧に発音される。そのため、転写方法においても、モンゴル文字で形の区別のないo, uについて、oとuをすべて区別して書き分ける方法と、第一音節のみo, uを書き分け、第二音節以降はuで統一するという方式が併存している*7。転写方法も一様でないし、その転写とほぼ一対一で対応する音声情報ベースのエンコードにおいても表現が一様にならないのは当然という気もする。
結果として同じ見た目になるコードポイント列がたくさん存在し、入力する人にとっても優しくないし、検索を行うにしても、形が同じなのに引っかからないという事態が発生することになる*8。
さらに、キーボードのキートップからは同じ形の文字の区別がよくわからないため、「正しい綴り」というものがもし存在したとしても、それを入力するのは難しい。結果的に人にも機械にとっても厳しい仕組みとなっているのが現状である。
現状の問題点まとめ
現状のエンコーディングモデルについて、L2/17-328 Script Ad Hoc Group Recommendations on Mongolian Text Modelでは次のような欠点が挙げられている。
- モデルが非常に複雑であり、仕様が十分に定義されていない(undespecified)。結果としてテキスト表現が曖昧である(ambiguous)
- フォントやレンダリングエンジンに非常に複雑な文脈依存ルール(contextual rule)を必要とするが、明確な仕様がない
- そのルールでは求める表示にならない文字を直すために、大量のvariation sequencesを必要とする
- フォントの実装や提供を行うことが非常に困難
- 結果、異なる実装やフォントで事実上相互運用性がない
- 相互運用性を“修正”するために、不安定な根拠の不安定なパッチ群を必要とする
- 国際ドメイン名でサポートされることはない(同じ見た目を示す複数のコードポイント列が存在するため、セキュリティ上困難)
- 標準的なユーザにとって、検索が非常に困難になる可能性がある(入力テキストが曖昧性をもつため)
- 顕著なセキュリティ上の懸念がある
- テキスト表現に含まれる音声情報はtext-to-speechにも言語分析にも実際効果的ではない
散々な言われようである。
改善の動き
さすがにこの現状ではまずいだろうと、Unicodeモンゴル文字改善のためのScript Ad Hoc Groupが作られ、改善に向けた動きが活発になっている。
L2/17-243 Script Ad Hoc report and recommendations on Mongolianにおいて、2種類の改善案が出されている。それぞれの特徴を挙げる。
1. 字形アプローチ(Graphetic approach)
- 文字の形と振舞いを基準に、音でなく形をベースとして文字を特定する
- あいまいさがなくなり、同じ見た目の語であればコード列が一通りに定まる。見たとおりに入力すればいい
- 現状のモデルの根本的な再構成であり、非互換
- 15程度の文字を新規に追加し、混乱の生じない文字については再利用する。既存の文字には変更を加えず、現状のモデルとの共存が可能
- アラビア文字のようなcursive-joining modelでシンプルに実装できる
- 現代モンゴル語の表記(Hudumという)にはvariation sequencesを必要としない(歴史的な文書や表記ミスを再現するためにvariation sequencesは必要ではある)
- 音声情報を持たないため、適切な順番にソートすることが難しく、同綴異義語の区別ができない
各国の反応
さて、Script Ad Hoc Groupは字形アプローチを強く推しているのであるが、中国やモンゴル国はどのように思っているのだろうか。
2017年9月23-25日に中国のフフホトで開催されたWG2 ad hoc meeting on MongolianのレポートがL2/17-347 Mongolian Ad Hoc Report (Hohhot, Inner Mongolia)である。
この文書によると、The Mongolian Working Group (おそらく中国か?)はthe Phonetic modelを支持し、モンゴル国の代表たちもthe Phonetic modelを支持しているとのことである。Unicode Technical Committeeの代表たちはどちらのモデルがよいとは言わなかったが、モンゴル文字テキスト処理の現状を懸念していることを表明した。
どちらにせよ、現状のモデルには多数の問題があり、改善策としてどちらの方式がとられたとしても、長期目標としてはモンゴル文字テキストを交換可能かつ将来にわたってアクセス可能にすること(interchangeable and accessible for future generations)であると会議の出席者は合意している。また、この問題の解決に向けて情報(や知識)を共有したり、協働することに同意したとのことである。
中国・モンゴル国の両国ともに現状と地続きの音声アプローチの方を支持しているようであるが、最終的にどの方式が選ばれるにしろ、相互運用性が確保されることは期待できそうである。
標準化の会議が年一回なので、公式の規格となるのは早くても2019年のUnicode 12.0以降となる。動向に注目したい。
ここをキャンプ地とする