JavaScript における文字コードと「文字数」の数え方

UTF-32

単純に考えれば、この Code Point をバイナリデータとしてそのまま送れば良いだろう。

Code Point はおおよそ 4byte あれば収まるので、32bit のデータとして送ることができる。

[0x00, 0x01, 0xF6, 0x2D] // 😭
// 0x1F62D を二進数にし 32 bit になるまで先頭に 0 を追加してから 8 bit づつ区切った配列

受け取った側は、データを 32bit づつ Code Point とみなして文字に置き換えていけば良いし、受け取ったバイト数を 4 で割れば文字の数もわかる。

このように 1 Code Point を 32bit データとして表すという発想が、UTF-32 と呼ばれる方式の中核である。

UTF-16

UTF-32 なら Code Point がそのまま入ってるので非常にシンプルだが、よく使う文字はそこまで大きな Code Point が振られてないため、ほとんどが 0 になる。

先の文字列では「野」や「で」という文字は Code Point が 0x91CE、0x3067 なので、32 bit だと先頭 2byte が 0 になる。

[0x00, 0x00, 0x91, 0xCE] // 野
[0x00, 0x00, 0x30, 0x67] // で

そこで、Code Point を 32bit ではなく、半分の 16bit で表せば、半分のサイズで送ることができる。

[0x91, 0xCE] // 野
[0x30, 0x67] // で

このように 1 Code Point を 16bit データとして表すという発想が、UTF-16 と呼ばれる方式の中核である。

ところが、𠮷 (0x20BB7), 𩸽 (0x29E3D), 𠮟 (0x20B9F), 😭 (0x1F62D) の 4 文字は 2byte では収まらない。

そこで、UTF-16 では、こうした 2byte では収まらない文字について、倍の 32bit で表す。

この 16bit x2 で表される文字を サロゲートペア と呼ぶ。

[0xD8, 0x67, 0xDE, 0x3D] // 𠮷
[0xD8, 0x42, 0xDF, 0xB7] // 𩸽
[0xD8, 0x42, 0xDF, 0x9F] // 𠮟
[0xD8, 0x3D, 0xDE, 0x2D] // 😭

逆を言えば、サロゲートペアになるのは Code Point が大きい、Unicode に後から追加された文字が多い。

𩸽 は後から追加された文字であり、𠮷 は 吉 の、𠮟 は 𠮟 の 異体字 と呼ばれるものだ。絵文字も最近追加されたため Code Point が大きい。

こうして、サロゲートペアが導入されたことにより、UTF-16 のデータは可変長、つまり、文字数がバイト列の長さだけではわからなくなってしまったのである。

もし、幸運にも文字列の中にサロゲートペアが 1 つも入っていなければ、バイト列を単純に 2 で割れば文字数が出る。しかし 1 つでもサロゲートペアがあると、単純な割り算では本来よりも多くの文字数があるように見えてしまうのだ。

UTF-8

英数字(a-zA-Z0-9) など、いわゆるアスキー文字と呼ばれるものは、Code Point の中でも小さい値が割り当てられている。

これら Code Point は 8bit の範囲に収まっているので、16 bit で表すと無駄が出てくる。

[0x00, 0x61] // a

そこで、8bit で表せる Code Point は 8bit で、足らないものは 16bit で、さらに足らないものは 24bit で、、と「小さい Code Point はより小さく」表せば、英語のみのテキストなどはさらに小さく表すことができる。

[0x61]                   // a
[0xC2, 0xA9]             // ©
[0xE3, 0x81, 0x82]       // あ
[0xF0, 0xA0, 0xAE, 0xB7] // 𠮷

この 8bit を最小とし、それ以外を必要に応じて 2, 3, 4...byte と可変長で表す発想が UTF-8 と呼ばれる方式の中核だ。

for of

例えば ES2015 で追加された for of は Iterator に対応しているため、Code Point 単位の繰り返し処理が可能だ。

for (let c of "𩸽定食") console.log(c)
// 𩸽
// 定
// 食

Spread Operator

Spread Operator を用いた分割も Iterator で行われる。

[..."𩸽定食"]  // 𩸽 定 食
Array.of(..."𩸽定食")

Destructuring

分割代入時の分割も Iterator で行われる。

[a, b, c] = "𩸽定食"
a // "𩸽"
b // "定"
c // "食"

Array.from

Array.from は Iterator をもとに配列を作る。

Array.from("叱られた😭")
[ "叱", "ら", "れ", "た", "😭" ]

異体字セレクタ

葛 の異体字として 葛󠄀 があり、カツシカ区は前者を、カサイ市は後者を使うらしい。

ところがこの二つは 𠮟 と 𠮟 のように別の文字コードを振るわけではなく、どちらも同じ文字であり、書き方のバリエーションが違うという扱いになっている。

そこで、基本となる文字コードを定義し、そこに対してバリエーションがあるものはその番号を組み合わせるという考え方が 異体字セレクタ だ。

葛 の文字コードは 0x845B であり、異体字の 1 番目である 葛󠄀 には、後ろに 0xE0101 をつける。

str = "葛飾区"
[
  0x845B // 葛
  0x98FE // 飾
  0x533A // 区
]


str = "葛󠄀城市"
[
  0x845B  // 葛
  0xE0100 // (異体字セレクタ)
  0x57CE  // 城
  0x5E02  // 市
]

これは、もし異体字セレクタで選択したフォントが入ってなかった場合、セレクタ抜きのフォントを選ぶというフォールバックが可能となる。

この異体字セレクタは、絵文字でも利用される。

例えば 👍 という絵文字は 👍🏻 👍🏼 👍🏽 👍🏾 👍🏿 のように肌の色を変えることができる。

これは、元となる絵文字に対して、Emoji Modifier Sequence という変更を加えるための異体字セレクタを組みわせている。

肌の色を変える skin tone は 5 種類定義されており、これを直後に置くことで表示上肌の色を変えられるのである。

Array.from("👍🏻👍🏼👍🏽👍🏾👍🏿")
[
  "👍", "🏻", // "0x1F44D", "0x1F3FB"
  "👍", "🏼", // "0x1F44D", "0x1F3FC"
  "👍", "🏽", // "0x1F44D", "0x1F3FD"
  "👍", "🏾", // "0x1F44D", "0x1F3FE"
  "👍", "🏿"  // "0x1F44D", "0x1F3FF"
]

これも、元となる文字に対して、異体字セレクタを付与する方式である。

ともあれ、セレクタ自体に Code Point が割り当てられているため、文字数を数える場合には考える必要がある。

異体字セレクタ自体も、漢字などに使われる IVS 、絵文字などに使われる SVS があるため、そのあたりを踏まえて処理することになるだろう。

結合文字

よく例に上がるのが パ と パ だ。

Array.from("パ") // 0x30d1
["パ"]
Array.from("パ") // 0x30cf, 0x309a
["ハ", "゚"]

このように、見た目上どちらも 1 文字だが、前者は 1 つの CodePoint 、後者は「ハ」と「半濁点」の 2 つの CodePoint から成り立っている。

ウムラウトやマクロンのような記号でも同じことがおこる。以下の文字は 3 つの方法で表すことができる。

Array.from("ǖ") // 0x1d6
["ǖ"]
Array.from("ǖ") // 0xfc, 0x304
["ü", "̄"]
Array.from("ǖ") // 0x75, 0x308, 0x304
["u", "̈", "̄"]

濁点やウムラウトのような、前にある文字(基底文字)に結合される図形文字を結合文字という。

結合して表せる文字そのものに CodePoint が割り当てられているために、複数の表現方法が可能になる。

CodePoint の数が変わるため、文字数も表現方法によって結果がブレてしまう。

そこで、Unicode ではこれらを「なるべく単一の CodePoint で表す」か「なるべく結合で表す」のどちらかに変換する方法が知られている。

これが 正規化 と呼ばれるものであり、前者を NFC 後者を NFD という。

NFC (Normalization Form Canonical Composition)

なるべく単一の CodePoint で表す

NFD (Normalization Form Canonical Decomposition)

なるべく結合で表す

JavaScript では、String.prototype.normalize() を用いるとこれを変換することが可能だ。

Array.from("パ".normalize("NFC"))
["パ"]
Array.from("パ".normalize("NFD"))
["ハ", "゚" ]

NFC, NFD は単純に結合かどうかを変更するが、この派生として NFKC, NFKD もある。

K は Compatibility のことであり、C だと Composition と被るのであえて K で表している。これは「互換等価」であるものへの変換も同時に行うオプションだ。

「互換等価」とは、要するに「意味的に同じ」ということであり、例を見るとわかりやすいだろう。

"Ａ１".normalize("NFKC")
// "A1" (全角英数を半角に)
"ｱ".normalize("NFKC")
// "ア" (半角カナを全角に)
"①".normalize("NFKC")
// "1" (囲み文字を数字に)
"㌶".normalize("NFKC")
// "ヘクタール" (互換用文字をカタカナに)

特に全角半角文字の正規化は、入力文字列のクレンジングなどにも使うことができる。

CodePoint によって文字数を数える観点からは、NFC または文脈によっては NFKC によって最小の CodePoint を数える方が一般的だろう。

しかし、注意点もあり、例えば Ⅲ (ローマ数字 3)は III (I が三つ)になったりなどが、入力者によって意図しない変換である場合もあるため、安易な変換には注意が必要だ。

ZWJ

他にも 👨‍👩‍👧‍👦 も合字を利用している。

Array.from("👨‍👩‍👧‍👦")
["👨", "‍", "👩", "‍", "👧", "‍", "👦"]

この絵文字は "family with mother father son daughter" という名前の文字で、4 つの絵文字が合成されてできている。

家族は多様なので別の組み合わせもある。

いずれにせよ、先ほどの方法で分解すると、個々の顔の間に空の文字が見える。

これは、👨‍👩‍👧‍👦 という絵文字自体が、👨, 👩, 👧, 👦 という 4 つの絵文字とそれを結合する制御文字でできているからである。

この制御文字を ZWJ(ZERO WIDTH JOINER) といい、ZWJ の Code Point は 0x200D だ。

先ほどのように「文字の数を数える == Code Point の数を数える」としてしまえば、👍🏻 は 2 文字で 👨‍👩‍👧‍👦 は 7 文字ということになる。しかし、おそらく多くの人がこれらを 1 文字と捉えるだろう。

Unicode Text Segmentation

1 文字を カーソルが 1 つ移動する分 と捉えているとなると、Code Point の数を数えるだけではなく、合字も 1 文字と捉える必要が出てくる。

この カーソルが 1 つ移動する分 を Grapheme と言い、Code Point の列の中から、書記素クラスタの区切りを判別する方法は Unicode の中に定義されている。

• UAX #29: Unicode Text Segmentation
  • https://unicode.org/reports/tr29/

この処理はそれなりに難しいものであるため、取り入れる際はライブラリを利用する方が良いだろう。

(どのライブラリが枯れているかは知らないため、ここでは紹介しないが、実装自体は探せばいくつかある。)

なお、JavaScript に関しては、TC39 にこれを標準で入れるというプロポーサルが上がっており、執筆時は Stage 3 である。

• tc39/proposal-intl-segmenter: Unicode text segmentation for ECMAScript
  • https://github.com/tc39/proposal-intl-segmenter

これを用いると以下のように実現できる。

const segmenter = new Intl.Segmenter("ja-JP", { granularity: "grapheme" })
const segments = [...segmenter.segment("👪")]
// [{ "segment": "👪", "index": 0, "input": "👪" }]