クメール文字を徹底的に解説する
クメール文字
ルール1
子音 https://gyazo.com/e58d9973b03a3ab3ad710249930ebdb4 に母音https://gyazo.com/f10ce64b1d08c5214c37cde9847c49ab
を組み合わせることで、
一文字 https://gyazo.com/ec448875969efd623e4ae47bf493d9ff
を作る
丸い点線に注目
https://gyazo.com/3b4e37d4e14d23eddaac7c49cfe4a9db
丸い点線で囲まれた中に前の文字（子音）の形がはいる
丸い点線がある母音を子音の後に入力する（逆では文字にならない）
前後左右どこにくっつかは母音の形と丸い点線の位置関係に注目すればわかる
ルール2
母音以外にも、前の文字にくっついて修飾する記号がいくつか存在する
https://gyazo.com/6fe3ebaf5142889e8440405d315cde65 など
ベースとなる文字には、母音も含めて複数の修飾記号がくっつきうる
ルール3
https://gyazo.com/f96b07b54b84313f063748fd4bf8fb5c は特殊な文字で、後ろに続く子音も、合成できる
いわばワイルドカードの最強の結合材
ស + ្ + ដ= https://gyazo.com/7239ceb395083d019c53c4731f6ad8fb
ユニコード表をみると、この記号だけ、四角い点線で囲まれているので、わかる
https://gyazo.com/5f55095f32273cae8a60e8d951bb65e3
ハングルが分かる人なら、ハングルとほぼ同じだと思うとよさそう。
ハングルはもっともっと簡単なような... 増井俊之.icon
分類上は、アブギダ文字に分類され、世界の文字のうち約半分はアブギダらしい（ハングルはアブギダではない）
東南アジアではメジャーのようだ。またサンスクリット文字もアブギダ
ブラーフミー系文字とも言われる
利点
rakusai.iconの感想だが、母音と子音を組み合わせるのは合理的である
覚える形が少なくて済む
例えば、子音10、母音5で10x5=50音の表現するにのに、15形状覚えれば足りる
https://gyazo.com/2299629f1a36509ca1d7a8061a61052f
じっさい、キーボードも簡単そう
https://gyazo.com/aa6487117d1044e071fff006a59f9266
おさらい
https://gyazo.com/ef590c9834dd1e250819595d316c1ac9
は
https://gyazo.com/eae70dbc70014b793a1644dcc8c63981
になる
実装
MacOSの入力フォームでは完璧に動作している
適当なエディタでは、្以外は、ただしく動作している
文字列を書記素クラスタに分割するで紹介されている https://github.com/orling/grapheme-splitter は្が考慮されないのでダメ
正規表現には \p{M}というマッチングがあって、修飾記号にマッチできるが、これも実装は、まちまちのようだ
Ruby製のものは、微妙だった
ちなみに、下の正規表現は、完璧に動作する
最新のUnicode表 (Unicode 6.0)に基づき、かつクメール文字の解説を読み込んだあとに作ったので間違いないはず
code:khmer.js
// spec: https://www.unicode.org/charts/PDF/U1780.pdf
export const khmer = (() => {
const letter = '\\u1780-\\u17FF' // ベースとなる文字
const trailingLetter = '\\u17B6-\\u17D1\\u17D3\\u17DD' // 主に母音となるヘンの部分になる文字
const control = '\\u17D2' // 子音を合成する特殊な結合用の記号 ្
const pattern = ${letter}(${control}${letter}|${trailingLetter})*
return pattern
})()
// sample = 'ច្រើនឡើងៗ'
// sample.match(new RegExp(khmer(), 'g'))
split-graphemesとしてnpmを公開
なお、サロゲートペアではない
他の文字との比較
タイ文字、ミャンマー文字、ラーオ文字などは似ている。兄弟と言ってよい存在
が、្があるものとないものがある
クメール文字は、្があるぶん難しいと言えるが、これに対応できれば横展開は容易である
全部一気には対応できない
しかたないようだ。
すごいnpmを探したがちょっと見当たらない
言語は変化するのでUnicodeの更新に対応する必要があるが、その手間が半端じゃない
プログラミング言語のハイライト機能のように要望に応じてちょっとづつやっていく？
考察
なんでこの方式を採用したのだろう？
ユニコード以前から、この方式だったようである
1 byteにすべて収めることができたので、これを採用したのだろう
組み合わせた文字の数だけ、codeを割り当てる方式（漢字風）を採用していた場合は、shift-JISのように、1byteと2byteの文字が発生するため避けたのでは
ユニコード後はどっちでもよいのでは？
ユニコードではcode数はほぼ無制限になったのでどっちの方式でもよさそう