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') 才能准确定位。

• 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，否则存进去就已截断或转成 ?。