文字数カウンター

人が「文字数制限」に期待するのは、見える単位に従うことです。アクセント付き文字や結合された絵文字がバラバラにされては困ります。Unicodeはここで使う実用的な境界を拡張書記素クラスタと呼びます。これはユーザーが知覚する文字の近似であり、すべてのフォント・言語・編集作業がすべての列を同じに扱う保証ではありません。

コードポイントはU+0065やU+1F600のように表記されるUnicode符号空間の値です。ECMAScript文字列は3つ目の層として16ビットコードユニットの列を露出します。U+FFFFを超えるコードポイントはサロゲートペアを占有するため、"😀".lengthは2になります。ファイルやネットワークペイロードは、文字列がUTF-8バイトにエンコードされると4つ目の層を加えます。

このカウンターが4層すべてを報告するのは、上限が契約だからです。バイト単位のデータベース列、UTF-16ユニット単位のJavaScript API、見える書記素単位の製品フィールドは、同じテキストを異なる量だけ受け入れます。単位と正規化ポリシーが名指しされるまで「500文字」という表示は不完全です。

書記素の合計は書記素単位のIntl.Segmenterを使用します。このAPIはロケールネゴシエーションと実装のUnicode境界データに従います。Unicode Standard Annex #29は結合記号、絵文字モディファイア、地域インジケーター、ゼロ幅接合子列の挙動を含む既定の拡張書記素クラスタ規則を定義し、ECMA-402はJavaScriptの分割インターフェースを定義します。

境界の挙動はブラウザーから独立して凍結されているわけではありません。新しいエンジンは更新されたUnicodeプロパティやロケール調整を反映でき、専門エディターは既定アルゴリズムにドメイン固有の規則を重ねる場合があります。上限の判断を正確に監査する必要があるなら、元のテキストを保存し実行環境を記録してください。

書記素数はカーソル移動とユーザー向け上限のためのものですが、視覚的な幅は測りません。1つのクラスタは狭くも広くも不可視にもなり得て、欠落グリフの箱として描画されたり、隣接文字と結合されたりします。レイアウト上限には文字列分割に加えてフォント・レンダリングの測定が必要です。

テキストエリアの値にNFC、NFD、NFKC、NFKDの変換は適用されません。テキストエリアのHTML動作がすでにCRLFとCRをLFに変換しているため、ソースとバイト単位で比較する際はこの変換を織り込む必要があります。Unicode正規化は、受け手のプロトコルが名指しの形式を要求する場合にのみ行ってください。署名、ハッシュ、データベースキー、バイト契約はそれぞれの規則に従います。

通常通り入力されたほとんどのテキストはUnicodeスカラー値から成りますが、JavaScriptの文字列は単独の上位・下位サロゲートを含めます。ECMAScriptのString型はwell-formed UTF-16ではない16ビット値の列を許します。単独サロゲートにはUTF-16コードユニット数はありますが、Unicodeスカラー値としての直接的なUTF-8エンコードはありません。

ウェブのWHATWG TextEncoderはUSVStringを受け入れ、UTF-8エンコードの前に単独サロゲートをU+FFFDに変換します。この置換は相互運用に有用ですが、その3バイトは元のコードユニットを保存するエンコードではありません。そのためこのカウンターはUTF-8バイト長を利用不可として扱い、置換ベースの合計を黙って使う代わりに不正な入力を報告します。