乱码主因是编码不一致或mbstring未真正启用；需验证扩展加载、明确字符串原始编码、显式指定mb_substr编码参数，并区分mb_substr与mb_strcut的字符/字节截取逻辑。

直接结论：乱码大概率不是 mb_substr 本身的问题，而是编码不一致或 mbstring 扩展未生效导致的。

确认 mbstring 扩展是否真正启用

很多人以为在 php.ini 里取消了 ;extension=mbstring 的注释就完事了，但 PHP 实际加载的是哪份配置、有没有重启服务、是否被 CLI 和 Web SAPI 加载不同 ini 文件，都会导致扩展“看似开启实则未加载”。

实操建议：

用 php -m | grep mbstring 检查 CLI 环境是否加载（别只信 phpinfo() 页面）

Web 环境下务必在脚本开头加 var_dump(extension_loaded('mbstring'));，不能只看 phpinfo 页面

如果返回 false，检查 php --ini 输出的配置路径，确认修改的是那个 php.ini

Apache 下改完需 sudo systemctl reload apache2；PHP-FPM 需 sudo systemctl reload php7.1-fpm

验证字符串原始编码是否为 UTF-8

mb_substr($str, 0, 5, 'utf-8') 不会自动转码 —— 它只是按 UTF-8 规则去解析字节流。如果传入的 $str 实际是 GBK 编码，却硬指定 'utf-8'，结果仍是乱码（或空字符串）。

实操建议：

用 mb_detect_encoding($str, ['UTF-8', 'GBK', 'BIG5'], true) 粗略探测原始编码（注意第三个参数 true 表示 strict 模式）

更可靠的方式是明确来源：数据库连接是否设了 charset=utf8mb4？HTTP 请求头是否声明 Content-Type: application/json; charset=utf-8？文件本身是否保存为 UTF-8 without BOM？

临时强制转码：先 $str = mb_convert_encoding($str, 'UTF-8', 'auto') 再截取（仅调试用，生产环境慎用 'auto'）

检查 mbstring 内部编码设置是否干扰

PHP 7.1 默认不设 mb_internal_encoding，但一旦代码中调用了 mb_internal_encoding('GBK')，后续所有 mb_* 函数（包括 mb_substr）若省略 $encoding 参数，就会按 GBK 解析 —— 即使你传的是 UTF-8 字符串。

实操建议：

全局统一入口处显式设置：mb_internal_encoding('UTF-8')，且确保它在任何 mb_substr 调用之前执行

永远显式传入 $encoding 参数，例如写成 mb_substr($str, 0, 10, 'UTF-8')，不要依赖内部编码

用 mb_internal_encoding() 无参调用检查当前值，避免被框架或第三方库悄悄修改

对比 mb_substr 和 mb_strcut 的行为差异

两者都解决中文截取问题，但机制不同：mb_substr 按字符数截，mb_strcut 按字节数截（但保证不切断多字节字符）。如果你期望“最多取 10 个字节”，用后者；如果期望“最多取 10 个汉字”，必须用前者。

常见误用：

把 mb_strcut($str, 0, 10, 'UTF-8') 当作 mb_substr 用，结果发现截出来只有 3 个汉字（因为 UTF-8 中 10 字节 ≈ 3 个中文字符）

在不知道原始编码时混用：比如字符串是 GBK，却用 mb_strcut($str, 0, 10, 'UTF-8')，会导致字节解析错位，输出不可预测

错误地认为 mb_strcut 更“安全”——其实它只避免字节断裂，不解决编码错配问题

最易被忽略的一点：即使 mbstring 扩展开着、编码也对，如果字符串里混有不可见控制字符（如 U+FEFF BOM、U+200B 零宽空格），mb_strlen 和 mb_substr 的计数仍可能出偏差。调试时先 bin2hex($str) 看真实字节流，比猜编码更直接。

Tags: PHP7.1mb_substr PHP截取中文乱码

分享到：