ASCII文字列の各エンコーディングでの長さ
プレーンなASCIIテキストが文字数、コードポイント数、書記素クラスター数、およびUTF-8、UTF-16、UTF-32エンコーディングでのバイトサイズでどのように測定されるかを理解します。
Basic Counting
詳細な説明
ASCII：最もシンプルなケース
純粋なASCII文字列（U+0000からU+007Fの文字）では、すべての長さ測定が一貫した予測可能な結果を返します。これがASCIIを文字列長の理解の出発点として最適にしています。
例の文字列
Hello, World!
長さの測定結果
| メトリック | 値 |
|---|---|
JavaScript .length |
13 |
| コードポイント数 | 13 |
| 書記素クラスター数 | 13 |
| UTF-8バイト数 | 13 |
| UTF-16バイト数 | 26 |
| UTF-32バイト数 | 52 |
なぜ（ほぼ）一致するのか
すべてのASCII文字はU+0080未満の単一のUnicodeコードポイントにマッピングされます。UTF-8ではこれらのコードポイントはそれぞれちょうど1バイトを必要とします。これはUTF-8がASCIIと後方互換性を持つように設計されたためです。つまり、純粋なASCIIではUTF-8バイト数=文字数です。
UTF-16では各文字が1つの16ビットコードユニットに収まりますが、各コードユニットは2バイトです。そのためUTF-16バイト数はASCIIでは常に2 × 文字数です。UTF-32はコードポイントあたり固定4バイトを使用するため、常に4 × コードポイント数です。
実用的な意味
アプリケーションがASCIIテキストのみを扱う場合、JavaScriptの.lengthをUTF-8ストレージのバイト数として安全に使用できます。ただし、アクセント付き文字、CJKテキスト、または絵文字を含むユーザー入力を許可した瞬間、この前提は完全に崩れます。
ユースケース
ASCII専用文字に制限された入力フィールド（ユーザー名、スラッグ、マシン識別子など）を検証する際、.lengthとUTF-8バイト数を安全に同一視できます。これはURLスラッグ、ファイル命名、プロトコルレベルの識別子で一般的です。