根本原因是substr()按字节截取而UTF-8中文占3字节，导致字符边界被硬切；应统一全链路UTF-8编码，并用mb_substr()+mb_strlen()按字符处理。
PHP截取中文出现乱码，根本原因在于字节与字符的错位截断。
英文字符在 UTF-8 中占 1 字节，而一个中文字符在 UTF-8 编码下占 3 字节（GBK 下为 2 字节）。substr() 是按字节操作的函数，它不识别字符边界。当你用 substr($str, 0, 5) 截取时，它只是从第 0 字节开始拿连续 5 个字节——很可能把某个中文字符的 3 字节拆开（比如只取了前 2 字节或后 1 字节），导致后续所有字节解析错位，浏览器无法还原原字符，就显示成 或一堆乱码。
举个例子：
字符串 "你好世界" 在 UTF-8 中实际是：你 → e4 bd\xa0（3 字节）好 → e5xa5xbd（3 字节）世 → e4 b8 96（3 字节）界 → e7 95 8c（3 字节）
若用 substr($str, 0, 5)，取前 5 字节：e4 bd\xa0 e5 xa ——e4 bd\xa0 是完整的“你”，但 e5 xa 只是“好”的前 2 字节，不构成合法 UTF-8 序列，解码失败，后面全崩。
关键问题不只是截取，还涉及编码环境
- PHP 文件本身保存为 GBK，但代码里设了
header('charset=utf-8')→ 源码和声明不一致 - 数据库返回的是
utf8mb4，但没执行mysqli_set_charset($conn, 'utf8mb4')→ 传输途中被转义 - HTML 页面没写
，或 PHP 输出前已有空格/BOM → header 发送失败 - 服务器默认字符集不是 UTF-8，Apache/Nginx 未配置
AddDefaultCharset UTF-8或charset utf-8
为什么 mb_substr 能避免乱码
mb_substr() 是多字节安全函数，它：
- 内部识别 UTF-8 字符边界（如检测
0xe4开头的字节流是否为 3 字节汉字） - 按“字符数”而非“字节数”计算起始和长度
- 必须显式传入编码参数（如
'utf-8'），否则可能按默认编码误判
其他常见诱因
- 使用
strlen()判断中文字符串长度 → 返回字节数（如"你好"返回 6），误当字符数用作截取长度 -
substr()配合负数偏移（如substr($str, -2)）→ 更难预估字节位置，风险加倍 - 编辑器保存 PHP 文件带 BOM 头 →
header()提前输出，导致后续 header 失效，浏览器用错误编码解析内容
本质上，乱码不是“PHP 不支持中文”，而是开发者混淆了字节操作与字符操作，且未统一全链路编码。只要数据源、脚本文件、数据库连接、HTTP 响应、HTML 声明全部锁定 UTF-8，并改用 mb_* 系列函数处理字符串，乱码就不再发生。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
