简体中文
简体中文
在 PHP 中处理多字节字符串时，我们常常依赖 mbstring 扩展来进行更好的 Unicode 兼容操作。特别是 mb_ereg_replace 和 mb_eregi_replace，因为它们号称是对多字节友好的正则替换函数。不少开发者误以为，它们可以像 PCRE 那样识别诸如 \p{Han} 的 Unicode 属性，从而实现对中文字符的精准匹配。
遗憾的是，这种想法错了。
首先要明确一点，mb_ereg_replace 和 mb_eregi_replace 使用的是基于 Oniguruma 的正则引擎，但它所采用的语法模式却不是 Perl 兼容正则表达式（PCRE），而是更为古老、功能有限的 POSIX 变种。虽然 Oniguruma 本身是支持 Unicode 属性匹配的，但前提是得启用合适的模式（比如 PHP 7.3+ 中的 preg_match 支持 \p{Han}）。
来看一个典型的误区代码示例：
$text = '这是 test 内容 123';
$result = mb_eregi_replace('\p{Han}+', '', $text);
echo $result;
你以为这个脚本会移除掉中文字符，保留英文和数字？其实并不会。mb_eregi_replace 会把 \p 当作普通的反斜杠和字母 p，而 {Han} 也完全不会被识别为任何特殊语义。这导致正则表达式根本无效，不会匹配任何中文字符。
要实现对 Unicode 属性的支持，正确的做法是使用 preg_replace 并加上 u 修饰符，这样才能告诉 PHP 使用 Unicode 模式来解释字符串。
来看一个正确示例：
$text = '这是 test 内容 123';
$result = preg_replace('/\p{Han}+/u', '', $text);
echo $result;
输出：
test 123
这才是我们真正想要的效果。
很多开发者在看到 mb_eregi_replace 有“多字节支持”的说明时，自然而然地以为它拥有 Unicode 属性的匹配能力，尤其是很多老教程或中文社区的文章未加澄清。例如你搜索 mb_eregi_replace \p{Han}，可能会找到一些模糊或者过时的解释，让人误以为这是“可以工作的”。
另外，如果你的项目中已经习惯使用 mb_eregi_replace 来处理正则，那么在处理中文或其他 Unicode 字符集时就极有可能踩坑，结果数据过滤不完整或逻辑错误，尤其是在文本清洗、数据抽取等任务中。
说实话，你最好别再用了。但如果出于兼容性需求必须使用，可以考虑对中文字符使用 Unicode 范围编码：
$text = '这是 test 内容 123';
$result = mb_eregi_replace('[一-龥]+', '', $text);
echo $result;
虽然这种做法也不够精准（比如不能匹配所有汉字扩展区），但起码比盲目用 \p{Han} 要靠谱得多。更进一步，你可以手动罗列多个汉字区间来提升精度，但终究是治标不治本。
更好的方案是彻底转向 preg_replace 并确保开启了 mbstring.func_overload 或适当的多字节支持策略，这样可以最大程度利用 PCRE 的强大功能。
别再误用 mb_eregi_replace('\p{Han}', ...) 了，它根本不认识 \p{} 这种语法。如果你需要处理 Unicode 属性，唯一值得信赖的选择是 preg_replace 配合 u 修饰符。多年来这个误区困扰了很多 PHP 开发者，是时候正本清源了。
