ThinkPHP多字节字符转换函数正确调用姿势-php教程-PHP中文网

thinkphp依赖php原生mb_*函数处理多字节字符，需在控制器入口统一转换非utf-8输入（如gbk），验证和截取必须用mb_strlen()、mb_substr()，禁止对已知utf-8数据重复转码。

thinkphp多字节字符转换函数正确调用姿势

ThinkPHP 本身不提供独立的多字节字符转换函数，它依赖 PHP 原生的 mb_* 系列函数（如 mb_convert_encoding、mb_strlen），但框架在初始化阶段会自动调用 mb_internal_encoding("UTF-8")（TP6 默认启用，TP5 需手动确认）。所以“正确调用姿势”的核心不是 ThinkPHP 自己的函数，而是如何在 ThinkPHP 项目中安全、一致地使用 PHP 的 mb_* 函数。

为什么不能直接用 `strlen()` 和 `substr()`

ThinkPHP 接收的请求数据（$_GET、$_POST、Input::get() 等）和数据库返回内容，一旦含中文、日文等多字节字符，原生函数就会出错：

strlen("你好") 返回 6（UTF-8 下每个汉字占 3 字节），但你需要的是字符数 2
substr("你好世界", 0, 3) 可能截出 "你" —— 因为从第 3 字节处硬切，破坏了 UTF-8 编码边界
表单提交的 GBK 编码页面若未转码，直接进 Db::insert() 就写入乱码

`mb_convert_encoding()` 在 ThinkPHP 中怎么用才不翻车

这不是“要不要用”，而是“在哪用、怎么传参”。关键原则：只对明确知道源编码的数据做转换，且优先用 mb_detect_encoding() 辅助判断。

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

不要对已知是 UTF-8 的数据反复转：mb_convert_encoding($str, 'UTF-8', 'UTF-8') 是冗余操作，还可能因检测失败导致空字符串

处理用户提交的旧系统表单（GBK 页面）时，应在控制器入口统一转换：

$raw = input('title'); // 可能是 GBK
$utf8_title = mb_convert_encoding($raw, 'UTF-8', ['GBK', 'GB2312', 'BIG5']);

避免只传两个参数：mb_convert_encoding($str, 'UTF-8') 会用内部编码当源编码，而内部编码未必可靠（尤其跨模块时）
数据库读取后需输出到非 UTF-8 环境（如老式邮件模板）才转出，日常 Web 响应保持 UTF-8 即可

ThinkPHP 模型/验证层必须配的 `mb_*` 场景

这些地方最容易漏掉多字节支持，导致验证通过但入库异常或前端显示错位：

验证规则中限制长度，必须用 mb_strlen() 而非 strlen()：

['title' => 'require|length:2,20', 'rule' => ['length' => function($value) {
    return mb_strlen($value, 'UTF-8') >= 2 && mb_strlen($value, 'UTF-8')

模型自动完成（auto）里截取摘要：mb_substr($content, 0, 100, 'UTF-8')，不是 substr($content, 0, 100)
JSON 输出前，确保所有字段已为 UTF-8：json_encode() 对非 UTF-8 字符串返回 null，可用 mb_check_encoding($str, 'UTF-8') 预检

最常被忽略的兼容性细节

ThinkPHP 运行环境是否真支持 mbstring，比“会不会写”更关键：

TP6 默认检查 mbstring 扩展，但 TP5.1+ 若禁用该扩展，mb_* 函数会 fatal error —— 必须在部署脚本中加 extension=mbstring 并重启 PHP-FPM
mb_detect_encoding() 不可靠：它只返回第一个匹配的编码，遇到混合编码（如 UTF-8 + ASCII 混排）可能误判；生产环境建议显式约定输入编码（如全部走 UTF-8 表单 + accept-charset="utf-8"）
CLI 模式下 mb_internal_encoding() 可能未生效，需在命令类 __construct() 中手动设置：mb_internal_encoding('UTF-8')