長さ制限
[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正規化が安全にできるための前処理で、
正規化の手順そのものに組み込まれていないので、別途明示的に適用しなければなりませんが、
これが実装されているところは見たことがありません。
さすがにどこかに実装事例くらいはあるでしょうが。
その実装を使っているところはもっと見たことがありません。
[12] アプリケーションの独自の処理ならこの方法を使いたいと開発者が考えれば使えますが、
プロトコルに 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 が失敗します。
[17] >>15 >>16 どちらも .repeat は時間がかかってから失敗するので、
固定の上限ではなく環境によって違う可能性があります。