* 概要


[2] [[結合文字]]の順序に関する
[[nondistict order]]
規則に立脚しています。

[3] 
[[結合文字]]が
[CODE[ccc]]
に従い[[整列]]されます。

* 長さ制限

[8] 
仕様上は[[結合文字列]]に長さ制限はありません。しかし、
[[結合文字]]が1GB分続いた後の[[結合文字]]を前に持ってくる、
なんてことができる実装方法が現実的とは思えません。


[6] 
[CITE@en-us[UAX #15: Unicode Normalization Forms]], [TIME[2024-08-14T19:11:21.000Z]], [TIME[2025-07-02T03:34:49.968Z]] <https://unicode.org/reports/tr15/#Stream_Safe_Text_Format>

[7] 
>>6 は
[[Stream-Safe Text Format]],
[[Stream-Safe Text Process]]
なる謎概念を導入してます。

[9] 
[DFN[Stream-Safe Text Process]]
は任意の入力から
[[Stream-Safe Text Format]]
を生成する操作です。
そのために
[CC[CGJ]]
が挿入されます。

[10] 
しかしながら、これは [[Unicode正規化]]が安全にできるための[[前処理]]で、
[[正規化]]の手順そのものに組み込まれていないので、別途明示的に適用しなければなりませんが、
これが実装されているところは見たことがありません。
さすがにどこかに実装事例くらいはあるでしょうが。
その実装を使っているところはもっと見たことがありません。

;; [12] [[アプリケーション]]の独自の処理ならこの方法を使いたいと開発者が考えれば使えますが、
[[プロトコル]]に [[Unicode正規化]]が組み込まれている場合は、仕様書にないなら勝手に適用するわけにいきません。

[11] 
現実問題として、実用目的のすべての [[Unicode正規化]]の実装は、
任意の入力に対して安全に処理を完了させる必要があります。
>>8 のような入力が与えられたときは、諦めて完全に [[Unicode正規化]]されていない文字列を返すか、
[[例外]]を[[投げる]]などの方法で失敗を伝えるかといった選択を迫られることになります。

[13] 
[[Web]] ではこの種の実装の制限を[[プラットフォーム制限条項]]として包括的に認めています。
他の[[プラットフォーム]]でも同様の制限を設けることになるでしょう。

[14] 
実際に [[Web]] でどう実装されているかを確かめてみましょう。

>
[PRE[
escape ( ["x", "\u0315".repeat (2**28) , "\u0300"].join("").normalize ("NFC").substring (0, 20) )
]PRE]

[15] [[Chrome]] では >>14 でも仕様通り正しく reordering します。 2**29 にすると不正な長さと
[CODE[.repeat]] が失敗します。
[TIME[2025-07-02T04:19:12.800Z]]

[16] [[Firefox]] では >>14 でも仕様通り正しく reordering します。 2**29 でも成功します。
2**30 だと文字列のメモリー割当に失敗したとなり、
2**31 にすると [CODE[.repeat]] が失敗します。
[TIME[2025-07-02T04:21:14.600Z]]

;; [17] >>15 >>16 どちらも [CODE[.repeat]] は時間がかかってから失敗するので、
固定の上限ではなく環境によって違う可能性があります。


* 破壊性

[4] 
この操作が破壊的である事例:
[[発音区別符付き仮名]]

* 文脈

[1] [[正準再順序付けアルゴリズム]]は[[正規化]]の処理から呼び出されます。


* 関連

[5] 関連: [[Unicode正規化]]

* メモ