PHP mbstring 怎样按字符截取多字节字符串

我在做标题、摘要和列表卡片的长度控制时，最先遇到的不是 mb_substr() 不会用，而是把“字符数”和“字节数”混在了一起。中文、日文、Emoji 等多字节文本如果直接交给 substr()，截断点可能落在一个字符的中间。PHP 的 mbstring 扩展提供了面向多字节文本的函数，按字符截取时，优先写成 mb_substr($text, 0, $limit, 'UTF-8')，把编码也显式传进去。

官方地址：https://www.php.net/manual/en/function.mb-substr.php

按字符截取多字节字符串的核心是：启用 mbstring，统一输入编码，并在 mb_substr() 中显式传入 UTF-8；长度计算也使用 mb_strlen()，不要用 strlen() 代替。

先把“保护对象”说清楚：我要保护的是字符边界

我通常把这件事看成一次小型的输入边界保护：原始文本是资产，编码是它的解释规则，截取参数则是边界控制。只要其中一个环节含糊，最终展示出来的摘要就可能出现乱码、少字，甚至在数据库里保存了不完整的 UTF-8 序列。

mbstring 不是 PHP 默认必然启用的扩展。先在入口或部署检查中确认函数存在，能把“环境缺扩展”和“参数写错”区分开。业务代码不必到处重复判断，但至少要让部署问题尽早暴露。

最容易踩坑的路径：字节函数和默认编码

我第一次排查乱码时，问题往往出在两个看似合理的替换：把 mb_substr() 换成了 substr()，或者把第四个参数省略了。前者按字节偏移，后者会退回到 mbstring 的内部字符编码；在团队协作或多套 PHP 配置并存时，隐式依赖很难审计。

mb_substr() 的 start 从 0 开始，length 表示最多取多少个字符；不传长度时会取到字符串末尾。负数 start 可以从末尾定位，但它表达的是字符位置，不是字节位置。需要“最多 N 个字符”的摘要时，固定传入 0、上限和 UTF-8 会更容易复查。

把风险降下来：显式编码和参数边界一起处理

对我来说，最稳妥的做法不是在每次调用前修改全局内部编码，而是在边界清晰的地方显式传 UTF-8。mb_internal_encoding() 适合统一应用约定，但它改变的是 mbstring 函数默认使用的编码，不会替代对外部输入的编码确认。来自 HTTP、文件或数据库的文本，仍应在进入摘要逻辑前确定编码契约。

几个边界值得单独留下记录：

• $limit ：先决定业务要返回空串还是拒绝参数，不要让负数直接流入截取函数。
• 文本长度未超过上限：直接返回原文，避免无意义地追加省略号。
• 文本超过上限：如果要追加 …，应先为它预留一个字符位。
• 起点为负数：只在确实需要从尾部取字符时使用，并把它和“从末尾取 N 个字符”的业务语义写清楚。
• 编码名称无效：在 PHP 8 及以上版本，mbstring 函数对无效编码可能抛出 ValueError，不要用静默返回值掩盖配置错误。

审计清单：这段截取逻辑适合谁

代码合并前，我会按“输入来源、编码、长度单位、截断标记、异常处理”五项快速扫一遍。只要出现 strlen() 配合中文长度、substr() 截取用户可见文本，或者调用中省略编码但项目没有统一约定，就值得回到边界重新确认。

这套写法适合标题摘要、列表预览、短信前的字符上限控制等“按字符计数”的场景。它不等于完整的用户感知字符分割：一个视觉上的字形可能由多个 Unicode 码点组成，若业务要求严格按 grapheme cluster 处理 Emoji 或组合字符，还应评估 grapheme_*() 系列函数。也就是说，mb_substr() 解决的是多字节安全和字符位置问题，不是所有语言学分词问题。

相关问题

为什么 strlen() 统计中文比预期大？

因为它按字节计数；面向字符长度时使用 mb_strlen($text, 'UTF-8')，并保持输入编码契约一致。

只写 mb_substr($text, 0, 10) 可以吗？

可以依赖内部编码，但在多环境项目里可读性和可控性较差。摘要、接口和存储边界建议显式写出 UTF-8。