mb_strlen不传编码参数易出错，因其回退到mb_internal_encoding()设定的内部编码，若与字符串实际编码（如gbk）不一致，会导致长度计算错误、截取乱码等问题；应始终显式指定编码。
mb_strlen 不传编码参数为什么经常出错
因为 mb_strlen() 在没指定第二个编码参数时，会 fallback 到内部编码（mb_internal_encoding() 的返回值），而这个值未必和你传入的字符串实际编码一致。比如数据库查出来的是 GBK 编码的中文，但内部编码设的是 UTF-8，mb_strlen($str) 就会把每个 GBK 中文当作非法 UTF-8 字节序列处理，可能返回 0 或截断结果。
常见表现：
- 同一段中文，在本地开发环境返回 4，在测试服务器返回 0
-
mb_substr($str, 0, 10)截出乱码或空字符串 - 调用前后没改过字符串，但
mb_strlen()和strlen()差值忽大忽小
实操建议：
- 永远显式传入第三个参数，如
mb_strlen($str, 'UTF-8') - 不要依赖
mb_internal_encoding()的全局设置，它只影响未指定编码的函数调用，且容易被其他模块覆盖 - 对来源明确的字符串（如 POST 数据、JSON 解析结果），优先按 HTTP 请求头或 Content-Type 推断编码；对文件/数据库读取内容，按连接层声明的编码为准
mb_convert_encoding 转换失败的三个典型原因
mb_convert_encoding() 报错或静默失败，往往不是函数本身有问题，而是输入数据或目标编码不匹配。
常见错误现象：
- 返回原字符串没变化（例如从 UTF-8 转 GBK，结果还是 UTF-8 字节）
- 返回空字符串或
false - 转换后出现 符号（U+FFFD 替换字符）
根本原因和对策：
- 源编码识别错误：比如把实际是 GBK 的字符串当成 UTF-8 传入，应先用
mb_detect_encoding($str, ['UTF-8', 'GBK', 'BIG5'], true)做探测（注意第三个参数true表示 strict 模式） - 目标编码不支持某些字符：如把含 emoji 的 UTF-8 字符串转成 GBK，emoji 无法表示，会被替换成 ；此时应确认目标环境是否真需要 GBK，否则保留 UTF-8 更稳妥
- 字符串含 BOM 或不可见控制字符：BOM 可能干扰编码检测，可用
ltrim($str, "\xEF\xBB\xBF")去除 UTF-8 BOM 后再转换
mb_substr 截断中文时仍乱码？检查这三点
mb_substr() 本身不会乱码，但乱码一定发生在它之前或之后——最常被忽略的是输入字符串的原始编码、截取长度单位、以及输出上下文的编码声明。
典型场景：
- 页面显示“你好世”，但
mb_substr("你好世界", 0, 3, 'UTF-8')看起来逻辑正确 - API 返回 JSON 中中文变成 \uXXXX 序列，但前端解析后显示为方块
排查重点：
- 确认输入字符串确实是 UTF-8 编码：用
bin2hex($str)看前几个字节是不是efbbbf（BOM）或e4bda0（“你”的 UTF-8 编码），而不是c4e3（GBK） - 检查第四个参数是否写错：比如写成
mb_substr($str, 0, 3, 'gbk')却传入 UTF-8 字符串，会导致位置计算错位 - 验证输出通道是否支持：HTML 页面没加
header('Content-Type: text/html; charset=utf-8')，或 MySQL 连接没执行SET NAMES utf8mb4，截得再准也白搭
Unicode 规范化不是 mbstring 的事
mbstring 扩展不提供 Unicode 规范化（Normalization）功能，比如把 “café”（带组合字符 é）和 “café”（预组字符）统一成同一种形式。PHP 原生没有内置函数做这件事，Normalizer::normalize() 是 intl 扩展提供的，不是 mbstring 的一部分。
这意味着：
- 用
mb_strlen()算 “café” 的长度，两种写法结果可能不同（组合字符算 2 个码点，预组字符算 1 个） - 用
mb_stripos()做大小写模糊搜索，遇到带重音符号的字符可能匹配失败 - 数据库唯一索引、缓存 key 计算、用户昵称去重等场景，若不提前规范化，会出现逻辑漏洞
实操建议：
- 确认服务器启用了
intl扩展：extension_loaded('intl') - 关键业务字段入库前做 NFC 规范化：
Normalizer::normalize($str, Normalizer::FORM_C) - 不要试图用
mb_convert_encoding()或正则模拟规范化——它不解决组合字符问题
真正容易被忽略的，是把“能显示中文”等同于“编码处理完整”。从字节流到屏幕，中间要过 HTTP 头、数据库连接、模板渲染、JS 字符串、甚至浏览器字体支持，任一环节掉链子，前面所有 mb_ 函数都白调。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
