PHP 中文正則匹配與替換陷阱：多位元組字元導致亂碼的根因與解決方案

前言

開發關鍵字高亮功能時，本地測試正常，上線卻出現大量亂碼甚至死迴圈。經排查，根因在於 PHP 早期版本（PHP 5.6 以前）核心採用單位元組字串處理，不支援 Unicode，導致中文在正則運算時被拆解為多個位元組，產生預期外的匹配結果。本文深度剖析問題本質，提供多種相容性解決方案。

問題重現

場景一：字符類別 [] 內含中文

$pattern = '/[漢字]+/ism';
$subject = '我是漢字，看你把我怎麼著！';
preg_match_all($pattern, $subject, $matches);
// 結果：大量亂碼、甚至死迴圈

原因：[漢字] 在單位元組模式下，會將「漢」（3-4 bytes）與「字」（3-4 bytes）拆解為 6-8 個獨立位元組，字符類別實際匹配的是這些位元組的任意組合，完全偏離原意。

場景二：替換函數誤傷相似位元組

eregi_replace('性', '沒有', '有責任感');
// 預期：無「性」字，回傳原字串
// 實際：'用揮敘任感' —— 「責」字第二位元組與「性」第一位元組相同，被錯誤替換

核心原理：PHP 字串與正則的位元組本質

• PHP 字串本質是 位元組序列，不攜帶編碼資訊。
• 中文編碼（GBK/Big5/UTF-8）皆為多位元組：UTF-8 中文佔 3 bytes，GBK/Big5 佔 2 bytes。
• PCRE 正則引擎在 /u 模式前，逐位元組匹配，不知曉字元邊界。
• ereg/eregi 系列更是純位元組操作，完全不支援多位元組。

解決方案對比

最佳實踐：關鍵字高亮完整範例

<?php
function highlight_keywords($text, $keywords, $tag = 'mark') {
    if (empty($keywords) || empty($text)) return $text;
    
    // 確保關鍵字為陣列
    $keywords = is_array($keywords) ? $keywords : explode(' ', $keywords);
    
    // 過濾空值、排序（長優先，避免部分替換干擾）
    $keywords = array_filter($keywords);
    usort($keywords, function($a, $b) { return strlen($b) - strlen($a); });
    
    // 建構模式：使用 /u 修飾符，預期輸入為 UTF-8
    $pattern = '/(' . implode('|', array_map('preg_quote', $keywords)) . ')/u';
    
    // 替換
    return preg_replace($pattern, "<$tag>$0", $text);
}

// 測試
$text = 'PHP 中文正則匹配與替換陷阱：多位元組字元導致亂碼';
$keywords = ['正則', '中文', '位元組', '亂碼'];
echo highlight_keywords($text, $keywords);
// 輸出：PHP 中文正則匹配與替換陷阱：多位元組字元導致亂碼
?>

避坑清單

1. 檔案編碼 = 輸出編碼 = 資料庫連線編碼 = 正則預期編碼，統一 UTF-8。
2. 資料庫連線執行 SET NAMES utf8mb4（而非 utf8）。
3. HTML 頁面宣告 <meta charset="UTF-8">。
4. PHP 檔案儲存為 UTF-8 without BOM。
5. 正則模式務必加 /u 修飾符。
6. 棄用 ereg/eregi/split 等已移除函數，全面改用 preg_* 或 mb_*。
7. 使用 mb_substr()、mb_strlen() 等多位元組安全函數處理中文截取/長度。

總結

PHP 早期單位元組架構導致中文正則匹配頻發亂碼、誤替換、死迴圈。核心解法是啟用 PCRE 的 /u 修飾符，配合全鏈路 UTF-8 編碼一致性。現代 PHP 7/8 已從核心層面解決此問題，新專案請直接升級；維護舊專案則需嚴守「加 /u、用 preg_*、統一 UTF-8」三原則。