[2] 結合文字の順序に関する nondistict order 規則に立脚しています。
[8] 仕様上は結合文字列に長さ制限はありません。しかし、 結合文字が1GB分続いた後の結合文字を前に持ってくる、 なんてことができる実装方法が現実的とは思えません。
[6] UAX #15: Unicode Normalization Forms, , https://unicode.org/reports/tr15/#Stream_Safe_Text_Format
[7] >>6 は Stream-Safe Text Format, Stream-Safe Text Process なる謎概念を導入してます。
[9]
Stream-Safe Text Process
は任意の入力から
Stream-Safe Text Format
を生成する操作です。
そのために
CGJ
が挿入されます。
[10] しかしながら、これは Unicode正規化が安全にできるための前処理で、 正規化の手順そのものに組み込まれていないので、別途明示的に適用しなければなりませんが、 これが実装されているところは見たことがありません。 さすがにどこかに実装事例くらいはあるでしょうが。 その実装を使っているところはもっと見たことがありません。
[11] 現実問題として、実用目的のすべての Unicode正規化の実装は、 任意の入力に対して安全に処理を完了させる必要があります。 >>8 のような入力が与えられたときは、諦めて完全に Unicode正規化されていない文字列を返すか、 例外を投げるなどの方法で失敗を伝えるかといった選択を迫られることになります。
[13] Web ではこの種の実装の制限をプラットフォーム制限条項として包括的に認めています。 他のプラットフォームでも同様の制限を設けることになるでしょう。
[14] 実際に Web でどう実装されているかを確かめてみましょう。
escape ( ["x", "\u0315".repeat (2**28) , "\u0300"].join("").normalize ("NFC").substring (0, 20) )[15] Chrome では >>14 でも仕様通り正しく reordering します。 2**29 にすると不正な長さと
.repeat が失敗します。
[16] Firefox では >>14 でも仕様通り正しく reordering します。 2**29 でも成功します。
2**30 だと文字列のメモリー割当に失敗したとなり、
2**31 にすると .repeat が失敗します。
[1] 正準再順序付けアルゴリズムは正規化の処理から呼び出されます。
[5] 関連: Unicode正規化