ラテン拡張文字とマルチバイトUTF-8
アクセント付きラテン文字（é、ü、ñなど）がUTF-8やその他のエンコーディングでの文字列長にどのように影響するかを学びます。
Basic Counting
詳細な説明
ASCII以上：ラテン拡張文字
é、ü、ñ、ç、åなどの文字はヨーロッパの言語で一般的です。見た目は単一の文字ですが、エンコーディングの詳細はASCIIとの重要な違いを明らかにします。
例の文字列
café naïve résumé
長さの測定結果
| メトリック | 値 |
|---|---|
JavaScript .length |
17 |
| コードポイント数 | 17 |
| 書記素クラスター数 | 17 |
| UTF-8バイト数 | 21 |
| UTF-16バイト数 | 34 |
| UTF-32バイト数 | 68 |
UTF-8バイト数が異なる理由
Latin-1 Supplement範囲（U+0080からU+00FF）の文字はUTF-8で1バイトではなく2バイトを必要とします。文字列"café naïve résumé"には4つのアクセント付き文字（é、ï、é、é）があり、それぞれ2バイトのUTF-8コストがかかります。残りの13のASCII文字は各1バイトです。合計：13 + (4 × 2) = 21バイト。
合成済み形式 vs 分解済み形式
文字éは2つの方法で保存できます：
- 合成済み（NFC）： U+00E9（単一のコードポイント、
é） - 分解済み（NFD）： U+0065 + U+0301（2つのコードポイント、
e+ 結合アキュートアクセント）
両方とも同じように表示されますが、.lengthとバイト数が異なります。分解済み形式はより多くのコードポイントとバイトを持ちます。これが文字列の比較や測定前にUnicode正規化が重要な理由です。
データベースへの影響
データベースのカラムが文字数で測定されるVARCHAR(255)の場合、両形式とも収まります。しかしバイトで測定される場合（古いMySQLの設定など）、分解済み形式はより多くのストレージを使用します。DBが文字数かバイト数のどちらをカウントするか必ず確認してください。
ユースケース
ヨーロッパ市場（フランス語、ドイツ語、スペイン語、ポルトガル語）向けのアプリケーションを構築する際、アクセント付き文字がUTF-8で2バイト使用することを理解することは、正確なストレージ推定とVARCHAR制限計算に不可欠です。