strlen() 返回字节数而非字符数，café在UTF-8下为5字节，故返回5；应改用mb_strlen($str, 'UTF-8')并确保全栈UTF-8编码（含数据库utf8mb4）。
PHP 中 strlen() 为什么对带变音符的拉丁文返回错误长度？
strlen() 统计的是字节数，不是字符数。像 café（é 是 U+00E9）在 UTF-8 编码下，é 占 2 个字节，strlen('café') 返回 5，而非直观的 4。这不是 bug，是它本意如此——它不关心字符语义，只数 byte。
常见错误现象：
– 表单校验提示“标题超 20 字”，用户明明只打了 18 个字母加变音符却报错
– substr() 截断后出现乱码（如把 ñ 的两个字节切开）
- 必须确认脚本文件、数据库连接、HTTP 响应头均为 UTF-8 编码（
mb_internal_encoding('UTF-8')最好在入口处调用） - 避免混用
strlen()/substr()和mb_strlen()/mb_substr() - 若无法改全站编码，至少对含用户输入的字段强制用 mb 系列函数
用 mb_strlen() 替代 strlen() 的三个关键点
mb_strlen() 是唯一可靠统计 Unicode 字符数的方式，但它默认依赖内部编码，不显式指定易出问题。
- 始终显式传入
'UTF-8'第二参数：mb_strlen($str, 'UTF-8')，避免受mb_internal_encoding()影响 - 注意服务器可能未启用
mbstring扩展：运行php -m | grep mbstring确认，否则会报Fatal error: Uncaught Error: Call to undefined function mb_strlen() - 性能上略慢于
strlen()，但对普通 Web 请求可忽略；高频字符串处理（如日志分析）才需权衡
变音符字符串截取和比较必须用 mb 函数族
除长度外，所有涉及“字符位置”的操作都得用 mb 版本，否则必然出错。比如 mb_substr($str, 0, 10, 'UTF-8') 才能安全取前 10 个字符；mb_strpos($str, 'café', 0, 'UTF-8') 才能准确定位。
立即学习“PHP免费学习笔记（深入）”；
-
mb_strtolower()/mb_strtoupper()处理带变音符的大小写转换（strtolower('Beyoncé')→beyoncé，但mb_strtolower('Beyoncé', 'UTF-8')→beyoncé，后者才符合预期） -
mb_stripos()比stripos()更可靠，尤其在德语ß、土耳其语İ等特殊映射场景 - 正则匹配必须用
mb_ereg()（已废弃）或preg_match()加u修饰符：preg_match('/^[\p{L} ]+$/u', $str)，否则\p{L}不生效
从 MySQL 读取含变音符数据时的编码链路检查
即使 PHP 侧用了 mb_*()，如果数据库连接层没设 UTF-8，拿到的仍是乱码字节，mb_strlen() 会按错误字节流解析，结果仍错。
- 连接时指定 charset：
new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', $u, $p)（注意是utf8mb4，非utf8） - 建表时字段用
utf8mb4_unicode_ci或utf8mb4_0900_as_cs排序规则（支持完整 Unicode，包括 emoji 和扩展拉丁变音符） - 执行
SET NAMES utf8mb4（PDO 可设PDO::MYSQL_ATTR_INIT_COMMAND自动执行）
真正容易被忽略的是：MySQL 的 utf8 实际只支持 BMP 平面字符（即最多 3 字节），而现代 Latin Extended-A/B/C/D/E/F/G 等区块里的许多变音符（如 ș、ț、ʒ）需要 4 字节 —— 必须用 utf8mb4，否则存进去就已截断或转成 ?。
