PHP mb_internal_encoding 和 mb_substr 的 encoding 参数怎么选择

处理中文标题时，mb_internal_encoding() 和 mb_substr() 的 encoding 参数经常被一起修改。最稳妥的选择是：应用启动时用 mb_internal_encoding('UTF-8') 固定统一默认值；普通调用让 mb_substr() 省略或传入 null，只有输入确实来自另一种编码，或接口需要明确声明编码时，才传入单次调用的 encoding。

官方手册：https://www.php.net/mb-internal-encoding　https://www.php.net/mb-substr

一句话判断：同一个应用、同一种 UTF-8 数据，用内部编码统一配置；不同来源、不同编码的数据，用 mb_substr 的第四个参数把边界写清楚。不要为了处理一条异常数据反复修改全局内部编码。

先分清全局默认值和单次调用参数

mb_internal_encoding 的职责是设置或读取 mbstring 的内部字符集。它适合放在应用入口或框架 bootstrap 中，让没有显式传参的多字节函数拥有确定默认值。它不是“把所有字符串转换成 UTF-8”的转换器，也不会替数据库连接或响应头声明编码。

mb_substr 的第四个参数是更窄的调用级选择。它告诉当前函数应该按哪种字符编码计算位置和长度；参数省略或为 null 时，函数才回到内部编码。可以用下面这张关系图记忆两者的边界。

统一 UTF-8 时让 mb_substr 继承默认编码

如果请求、模板、数据库和队列都约定 UTF-8，启动阶段设置一次即可。之后的标题截取不需要到处重复写字符串常量，代码也更容易统一修改。

这里的 24 是字符数上限，不是 UTF-8 字节数。若只在这一处传入 'UTF-8' 也能工作，但会把全局策略重复到业务代码里。更值得保留显式参数的场景，是调用者真的掌握了输入编码，而不是为了“看起来更安全”到处硬编码。

输入编码不统一时，用第四个参数隔离影响

例如导入接口同时接收 UTF-8 和某个遗留单字节编码，最重要的是让函数签名表达这个事实，而不是先调用 mb_internal_encoding($encoding)，截取后再改回 UTF-8。后者在长驻 worker、协程或共享上下文中尤其容易把下一条任务带偏。

前提是字符串确实按照声明的编码产生。如果原始字节已经被错误地当成另一种编码解码，第四个参数只能让截取规则一致，不能挽回丢失的信息。需要转换时，应在输入边界使用 mb_convert_encoding，转换后再统一进入 UTF-8 领域。

参数选择表：看数据边界，不看函数名字

还要注意 PHP 版本差异：PHP 8.0 起，传入无效编码名会抛出 ValueError；更早版本通常表现为警告和失败返回。生产代码应记录输入来源和编码名，不要只捕获一个空字符串结果。

常见问题

mb_substr 不传 encoding 会不会默认使用 UTF-8？

不一定。它使用当前的 mbstring 内部编码，所以应在入口显式设置 UTF-8，或在调用处传入确定的编码。

设置 mb_internal_encoding 后数据库就不会乱码吗？

不会。数据库连接字符集、源文件编码、HTTP 响应头和字符串转换都是独立环节，必须分别核对。

什么时候应该传 null？

当你想明确表达“本次调用继承内部编码”时可以传 null；日常代码省略第四个参数也有同样语义。

可以在每次请求里切换 mb_internal_encoding 吗？

短生命周期请求中也不推荐这样设计。多来源输入应通过显式参数或先转换成统一编码，避免全局可变状态扩散。

实践中可以把规则压缩成一个检查清单：入口固定默认值；输入边界记录真实编码；混合来源时单次调用显式传参；需要统一存储时先转换；最后分别检查数据库和 HTTP 输出声明。这样选择参数时，依据就是数据边界，而不是凭经验重复写 'UTF-8'。