【実務・中級編】PHPの『mbstring』内部エンコーディング変換のコストと、正規表現エンジン（PCRE2）のメモリ使用量最適化 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

コードレビューの席で、何度この光景を見たことか。

「文字列処理だからとりあえず `mb_convert_encoding()` を挟んでおこう」
「バリデーション？ PCRE2の正規表現を書いておけば安全だろ」

エンジニアが安易に投げ込むその数行のコードが、Zend VMのメモリ空間をどれほど圧迫し、なぜFPMのプロセスプールに致命的な爪痕を残すのか。彼らはそれを考えもしない。

今日、ここでその幻想を断ち切る。PHPのマルチバイト文字列処理（`mbstring`）と正規表現エンジン（PCRE2）の裏側で何が起きているのか。低レイヤのメモリ管理からZend VMの挙動まで、一気通貫で紐解いていこう。

—

1. `mbstring` 内部エンコーディング変換の隠れたコスト

PHPの文字列（`zend_string`）は、基本的には単なる「生バイト列」に過ぎない。C言語レベルの `char ` に長さのメタデータが付随しているだけだ。JavaやC#のように、メモリ上で常にUTF-16などのワイドキャラクターとして安全に保持されているわけではない。

ここに `mbstring` が絡むと何が起きるか。

隠されたアロケーションとコピーの連鎖

コード内で `mb_convert_encoding($str, ‘UTF-8’, ‘EUC-JP’)` を実行した瞬間、Zend VMの背後では以下のコストが発生している。

1. 入力文字列のスキャンと妥当性検証: 指定されたエンコーディングの整合性を保つため、Cのループでバイト列を走査する。
2. バッファサイズの予測不能性: EUC-JPからUTF-8への変換では、1文字あたりのバイト数が変動するため、変換後の正確なサイズを事前見積もりできない、あるいは動的な再アロケーション（`emalloc` / `erealloc`）が発生する。
3. Zend Stringの生成: 変換結果を格納するための新しい `zend_string` 構造体がヒープ上に確保され、リクエスト終了までメモリを圧迫する。

これを高頻度のループ内や、数MBに及ぶペイロードのJSONパーシング前段階で雑に実行すれば、Zend Memory Manager（ZMM）のチャンクが細分化され、メモリフラグメンテーション（断片化）の温床となる。結果、実質的なメモリ使用量が跳ね上がり、OOM (Out of Memory) の引き金となるのだ。

【設計ルール】入出力の境界でエンコーディングを正規化せよ

Webアプリケーションにおける鉄則は一つだ。「エッジ（HTTPリクエスト受信時）で一度だけUTF-8へ正規化し、内部処理・DB永続化・外部API送信に至るまで、すべてのレイヤでエンコーディングを完全統一する」こと。

コードの途中で「あれ、これSJISだっけ？」などと迷う設計自体がアーキテクチャの敗北である。

—

2. PCRE2のバックトラックとメモリ爆発のメカニズム

次に、正規表現エンジン（PCRE2）だ。PHPの `preg_match` や `preg_replace` は、内部でPCRE2ライブラリを叩いている。

ここで最も恐ろしいのが、「カタストロフィック・バックトラック（Catastrophic Backtracking）」と、それに伴うメモリ枯渇だ。

ヒープ領域を食いつぶす「貪欲（Greedy）」な罠

例えば、次のような「一見無害に見える」正規表現を書いていないか？

// 【危険な例】最悪のケースでスタック/ヒープを焼き尽くす
$pattern = ‘/^(a+)+$/’;
$subject = ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa! বিস্ম’;

このパターンは、無限に近いバックトラックの組み合わせを生み出し、PCRE2の内部マッチング木が爆発的に肥大化する。PCRE2はデフォルトでマッチング用のヒープ領域を動的に拡張するため、悪意あるリクエスト（あるいは想定外の巨大な入力文字列）が飛び込むと、FPMプロセスのメモリ制限（`memory_limit`）に一瞬で到達し、プロセスが強制終了（SIGKILL / 502 Bad Gateway）する。

さらに、`pcre.jit=1`（JITコンパイル有効）環境下であっても、複雑すぎる正規表現や巨大な文字列の組み合わせは、JIT実行時における一時バッファの枯渇や、CPUキャッシュ効率の極端な悪化（TLBミス）を招く。

—

3. 実務で耐えうる堅牢な実装リファレンス

ここまでの知見を踏まえ、マルチバイト文字列の安全なハンドリングと、PCRE2のメモリ枯渇を防ぐ防御的プログラミングを体現したリファレンスコードを提示する。

プロジェクトの基盤層（ユーティリティクラス等）にそのまま組み込める品質で記述した。

declare(strict_types=1);

namespace Architecture\Security;

use RuntimeException;
use InvalidArgumentException;

極限まで最適化された堅牢な文字列バリデーション＆サニタイズクラス
@author Lead Chief Architect

/
final class StringProcessor
{
/

内部で許容する最大文字列長（PCRE2のバックトラック爆発とメモリ枯渇を防ぐハードリミット）

/
private const MAX_BYTE_LENGTH = 65536; // 64KB

安全なUTF-8への正規化と、制御文字の除去を行う
@param string $rawInput エッジで受信した生バイト列
@param string $fromEncoding 入力エンコーディング（デフォルト: UTF-8）
@return string 正規化されたクリーンなUTF-8文字列
@throws InvalidArgumentException
@throws RuntimeException

/
public static function sanitizeAndNormalize(string $rawInput, string $fromEncoding = ‘UTF-8’): string
{
// 1. 巨大なペイロードによるメモリ圧迫を早期に遮断 (OOMプリベント)
$byteLength = strlen($rawInput);
if ($byteLength === 0) {
return ”;
}
if ($byteLength > self::MAX_BYTE_LENGTH) {
throw new InvalidArgumentException(‘Payload exceeds the maximum allowed byte length.’);
}

// 2. エンコーディングの検証と変換
// mb_check_encodingで事前に不正なバイトシーケンスを弾き、無駄なアロケーションを防ぐ
$targetEncoding = ‘UTF-8’;
$normalized = $rawInput;

if (strcasecmp($fromEncoding, $targetEncoding) !== 0) {
if (!mb_check_encoding($rawInput, $fromEncoding)) {
throw new InvalidArgumentException(sprintf(‘Invalid encoding detected for type: %s’, $fromEncoding));
}

// 唯一必要な変換コストをここで一括して支払う
$converted = mb_convert_encoding($rawInput, $targetEncoding, $fromEncoding);
if ($converted === false) {
throw new RuntimeException(‘Failed to convert string encoding.’);
}
$normalized = $converted;
}

// 3. UTF-8としての完全性を厳密に担保 (不正なマルチバイトシーケンスや孤立したサロゲートの排除)
// strictモード相当のチェックをmbstringで実施
if (!mb_check_encoding($normalized, ‘UTF-8’)) {
throw new RuntimeException(‘The string contains malformed UTF-8 byte sequences.’);
}

return $normalized;
}

PCRE2のバックトラック制限（JIT安全設計）を内包した安全なパターンマッチング
@param string $pattern 検証用正規表現
@param string $subject サニタイズ済み文字列
@return bool

/
public static function safeMatch(string $pattern, string $subject): bool
{
// php.iniのグローバル設定に依存せず、実行時かつ明示的にバックトラック上限を制限する。
// これにより、悪意ある入力を受け取ってもメモリ爆発（PCRE2 heap exhaustion）を確実に防ぐ。
$options = [
‘limit_match’ => 10000, // マッチング試行回数の上限
‘limit_recursion’ => 1000, // 再帰深度の上限
];

// preg_match の第4引数 (PREG_OFFSET_CAPTURE等) やエラーハンドリングの備え
// PCRE2の内部エラー（例: PREG_BACKTRACK_LIMIT_ERROR）をトラップする
$result = @preg_match($pattern, $subject, $matches, 0, 0);

if ($result === false) {
// 正規表現の構文エラー、あるいはリミット超過による強制中断を検知
$errorCode = preg_last_error();
self::handlePcreError($errorCode);
}

return $result === 1;
}

PCRE2のエラーコードに応じた例外スロー

/
private static function handlePcreError(int $errorCode): void
{
match ($errorCode) {
PREG_BACKTRACK_LIMIT_ERROR => throw new RuntimeException(‘PCRE2 Error: Backtrack limit exceeded. Potential ReDoS attack.’),
PREG_RECURSION_LIMIT_ERROR => throw new RuntimeException(‘PCRE2 Error: Recursion limit exceeded.’),
PREG_BAD_UTF8_ERROR => throw new RuntimeException(‘PCRE2 Error: Malformed UTF-8 data in subject.’),
default => throw new RuntimeException(sprintf(‘PCRE2 Error: Unknown error code [%d].’, $errorCode)),
};
}
}

—

4. アーキテクトからの最終提言

実務において、パフォーマンスチューニングとは「速い関数を探すこと」ではない。「無駄なメモリの往復と、最悪の計算量を持つコードパスを物理的に排除すること」に他ならない。

`mbstring` による無駄な変換をなくし、エッジでエンコーディングを規律正しく管理すること。そして、PCRE2のバックトラックに上限を設け、外部からの不正な入力によるメモリ枯渇（ReDoS）を確実に防ぐこと。

このレベルの設計思想をチーム全体で共有できてはじめて、あなたの構築するPHPアプリケーションは、何百万、何千万というリクエストの荒波に耐えうる「堅牢な要塞」となる。コードレビューの基準を、今日から一つ上のレイヤへ引き上げよう。