サロゲートペアという名の爆弾：`String.prototype.codePointAt()` で文字列処理の解像度を極限まで高める方法
こんにちは。日々、数百万行規模のフロントエンド・アーキテクチャの最適化と、ブラウザの限界性能を引き出すことに執念を燃やしているチーフアーキテクトの私だ。
JavaScriptの文字列（String）操作について、君たちは普段どう向き合っているだろうか？ `length`を取って、`slice`で切り出して、`includes`で部分一致を見る。そんな日常的なコードに潜む「見えない地雷」に気づいているエンジニアは、実はそう多くない。
特に、絵文字（Emoji）や異体字セレクタ（IVS）、歴史的文字を扱う現代のWebアプリケーションにおいて、UTF-16のサロゲートペア構造を無視した文字列操作は、データ破損、XSSのバイパス、セキュリティ脆弱性、さらにはUIのレンダリング崩壊という致命的な不具合の温床となる。
今回は、JavaScriptの文字列の深淵に潜む、サロゲートペアと `String.prototype.codePointAt()` の真の活用法について、ブラウザエンジンの内部挙動を交えながら徹底的に解説しよう。
—
1. なぜ `charCodeAt()` では不十分なのか？（UTF-16の歴史的呪縛）
JavaScriptの文字列は、内部的にUTF-16エンコーディングで表現されている。これはJavaScriptの歴史的経緯（Brendan Eichが10日間で言語を設計した代償とも言える）であり、初期のUCS-2仕様の名残を強く引きずっている。
BMP（Basic Multilingual Plane: 基本多言語面）に収まる文字（U+0000 から U+FFFF）であれば、1文字は16ビット（2バイト）のコードユニット1つで表現される。ここで使われるのが、お馴染みの `String.prototype.charCodeAt(index)` だ。
しかし、Unicodeが拡張され、U+10000 を超えるコードポイント（補助文字面 / Supplementary Planes）を表現する必要が生じたとき、設計者たちは「16ビットのコードユニットを2つ使って1つの文字を表現する」という苦肉の策を採用した。これがサロゲートペアである。
上位サロゲート（High Surrogate: `0xD800` 〜 `0xDBFF`）と、下位サロゲート（Low Surrogate: `0xDC00` 〜 `0xDFFF`）のペアだ。
ここに `charCodeAt()` を使うとどうなるか。
// 消防車の絵文字 🚒 (U+1F692) はサロゲートペアで構成されている
const fireEngine = ‘🚒’;
console.log(fireEngine.length); // 2 （文字数は1文字なのに、コードユニットの長さは「2」を返す！）
console.log(fireEngine.charCodeAt(0)); // 55357 (0xD83D : 上位サロゲート)
console.log(fireEngine.charCodeAt(1)); // 56466 (0xDE92 : 下位サロゲート)
見ろ、これが現実だ。人間が「1文字の絵文字」として認識しているものを、`charCodeAt()` は「無機質な2つの数値の断片」として切り分けてしまう。
この状態で安易に文字列を `slice(0, 1)` などと叩けば、上位サロゲートだけが単独で切り出され、ブラウザは「不正なサロゲートペア（Broken Surrogate）」としてレンダリングエラーを起こすか、セキュリティバリデーションをすり抜ける原因になる。
—
2. `String.prototype.codePointAt()` による完全なコードポイントの取得
ここで登場するのが、ES2015（ES6）で導入された救世主、`String.prototype.codePointAt(pos)` だ。
このメソッドは、指定されたインデックス `pos` から始まるコードユニットを読み取り、それがサロゲートペアの一部であれば、結合された完全なUnicodeコードポイント（整数値）を返す。
const fireEngine = ‘🚒’;
// インデックス 0 からのコードポイントを取得
console.log(fireEngine.codePointAt(0).toString(16)); // “1f692” （正しい完全なUnicode値！）
// では、インデックス 1（下位サロゲートの位置）を指定するとどうなるか？
console.log(fireEngine.codePointAt(1).toString(16)); // “de92” （下位サロゲート単体の値も取得可能）
`codePointAt(0)` は、インデックス0が上位サロゲートであることを検知すると、直後のインデックス1のデータも参照して合成し、`0x1F692` という本来のコードポイントを算出して返す。
この挙動こそが、堅牢な文字列パーサーやバリデーターを作る上で極めて重要な鍵となる。
—
3. 実務での活用：サロゲートペアを安全にイテレートするアーキテクチャ
実務において、入力フォームの文字数制限（MaxLength）や、リッチテキストエディタのカーソル位置計算、ハッシュ化前の文字列サニタイズを行う際、`String.prototype.length` や `for…of` ループ、スプレッド構文（`[…str]`）がよく使われる。
実は、現代のJS（ES2015以降）では、イテレータレベルでサロゲートペアが考慮されているため、`for…of` を使えば文字単位での安全な走査が可能だ。
// for…of は内部でサロゲートペアを正しく処理する
for (const char of ‘👨💻エンジニア’) {
console.log(char, ‘codePoint:’, char.codePointAt(0).toString(16));
}
しかし、「インデックス（位置）を指定してランダムアクセスする必要がある場合」や、「低レイヤーで文字列のパースやトークナイズを行うカスタムパーサー」を書く場合には、依然として `codePointAt()` を直接叩く必要がある。
以下に、メモリ効率と実行速度を極限まで高めつつ、サロゲートペアの崩壊を防ぐ安全な文字列イテレータのユーティリティコードを示す。
/
- 文字列を安全にコードポイント単位で走査し、インデックスとコードポイントを同時に扱うためのジェネレータ
- @param {string} str
/
function iterateCodePoints(str) {
const len = str.length;
for (let i = 0; i < len; i++) {
const codePoint = str.codePointAt(i);
// サロゲートペア（2コードユニット消費）の場合はインデックスを1つ進める
const charSize = codePoint > 0xFFFF ? 2 : 1;
yield {
index: i,
codePoint: codePoint,
char: str.slice(i, i + charSize)
};
if (charSize === 2) {
i++; // 下位サロゲート分をスキップ
}
}
}
// 実行例
const target = ‘A🔥B’;
for (const item of iterateCodePoints(target)) {
console.log(`Index: ${item.index}, Char: ${item.char}, CodePoint: U+${item.codePoint.toString(16).toUpperCase()}`);
}
/
出力:
Index: 0, Char: A, CodePoint: U+41
Index: 1, Char: 🔥, CodePoint: U+1F525
Index: 3, Char: B, CodePoint: U+42
/
この実装であれば、V8などのJavaScriptエンジン内部における文字列のメモリレイアウト（Flat String / Cons String）の特性を壊さず、O(N)の計算量で正確なコードポイントのインデックスマッピングを維持できる。
—
4. パフォーマンスとメモリ効率に関するチーフアーキテクトからの提言
最後に、パフォーマンスの観点について言及しておこう。
1. 安易な配列化（`Array.from(str)` や `[…str]`）の濫用に注意せよ
巨大なテキストデータ（例えば数メガバイトのMarkdownやJSONログなど）に対して、安易に `[…str]` や `str.split(”)` を実行すると、メモリ上に一時的な配列と文字オブジェクトが大量に生成され、Garbage Collection（GC）の圧力が一気に跳ね上がる。メインスレッドがブロックされ、UIのフレームレート（Jank）が低下する主原因となる。
2. 必要な箇所だけ遅延評価（Lazy Evaluation）を使え
文字数制限のバリデーションやリアルタイム検索であれば、全文字列を一度に配列化するのではなく、前述のジェネレータ関数のように「必要な分だけ `codePointAt` でオンデマンドに読み取る」設計にすべきだ。メモリフットプリントを最小限に抑え、ブラウザのメモリ上限（OOM）エラーを防ぐことができる。
3. セキュリティ境界での文字正規化（Normalization）との併用
サロゲートペアだけでなく、ゼロ幅接合子（ZWJ: U+200D）や異体字セレクタを含む複雑な絵文字（例：家族の絵文字 `👨👩👧👦` は複数のコードポイントとZWJの結合体だ）を扱う場合、`codePointAt()` だけでなく `String.prototype.normalize(‘NFC’)` による正規化をパイプラインの初期段階で必ず通すこと。これを怠ると、バックエンドのデータベース（MySQLの `utf8mb4` の設定ミスなど）との間で文字化けや挿入エラーの温床となる。
—
まとめ
文字列操作は、フロントエンド開発において最もプリミティブでありながら、最も軽視されがちな領域だ。
しかし、グローバルなユーザーベースを持つモダンなWebアプリケーションにおいて、文字化けやサロゲートペア起因のバグは、プロダクトの信頼性を一瞬で失墜させる。
`String.prototype.codePointAt()` は、ただのニッチなメソッドではない。UTF-16という歴史的呪縛から解放され、Unicodeの深淵を安全にわたるための数少ない羅針盤である。
この知見を武器に、君たちのコードベースをより堅牢で、エレガントなものに昇華させてほしい。次回のアーキテクチャ解説でお会いしよう。
コメント