是。strlen() 统计字节数，会将\0、\t、\n、BOM、零宽空格等所有占字节的不可见字符计入长度，导致看似为空的字符串返回非零值。
strlen() 会把不可见字符算进长度吗
会。PHP 的 strlen() 统计的是字节数，不是“可视字符数”。像 \0（空字符）、\t、\n、\r、UTF-8 BOM（\xEF\xBB\xBF）、零宽空格（\xE2\x80\x8B）这些，只要占字节，strlen() 就会计入。
常见误判场景：表单提交后看似空的字符串，strlen() 却返回非 0；JSON 解析失败但看不出输入异常；数据库写入后字段莫名截断。
- 用
bindec(dechex(ord($char)))或unpack('H*', $str)查看原始字节，确认是否混入不可见字符 - 对用户输入做清洗前，先用
strlen()和mb_strlen($str, 'UTF-8')对比——若不等，大概率含多字节不可见符（如 BOM 或零宽） - 注意：
mb_strlen()同样会统计 UTF-8 编码下的不可见字符（如 U+200B），它只按字符计数，不区分“是否可见”
过滤常见不可见字符的实用方法
不能靠简单 trim —— trim() 默认只处理空白符（空格、\t、\n、\r、\0、\x0B），对 BOM、零宽空格、软连字符（U+00AD）等完全无效。
推荐组合过滤：
立即学习“PHP免费学习笔记（深入）”；
- 先用
preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]/', '', $str)清除 ASCII 控制字符（不含 \t\n\r） - 再用
preg_replace('/[\xE2\x80\x80-\xE2\x80\x8B\xE2\x81\x9F\xE2\x81\xA0]/u', '', $str)去掉常见 Unicode 格式字符（包括零宽空格、窄空格、换行符等） - 对可能含 BOM 的输入（如文件读取、前端粘贴内容），开头用
ltrim($str, "\xEF\xBB\xBF")显式剥离 UTF-8 BOM
示例：
$clean = ltrim($input, "\xEF\xBB\xBF");
$clean = preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]/', '', $clean);
$clean = preg_replace('/[\xE2\x80\x80-\xE2\x80\x8B\xE2\x81\x9F\xE2\x81\xA0]/u', '', $clean);
判断是否“真正为空”要避开哪些坑
直接 empty($str) 或 !$str 不可靠：含空格或不可见字符时返回 false，但业务上可能期望它为“空”。
更安全的“语义为空”判断逻辑：
- 先过滤不可见字符（如上一步），再
trim()，最后判断=== '' - 避免用
mb_ereg_replace('^\\s+$', '', $str) === ''——\s在 PCRE 中默认不匹配零宽类字符，会造成漏判 - 如果需兼容 JSON 输入，注意
json_decode($str, true)失败时可能因开头 BOM 导致，应先清理再解码
从源头减少不可见字符混入
前端粘贴、富文本编辑器、Excel 复制、某些 CMS 导出 CSV 是主要污染源。后端不能只靠兜底清洗。
- 表单提交前 JS 可做轻量预处理：
value.replace(/[\u200B-\u200F\u202A-\u202E\uFEFF]/g, '') - 接收 POST 数据后，立即对关键字段（如用户名、搜索关键词）执行不可见字符过滤，不要等到入库或显示时才处理
- 读取文件（尤其是
file_get_contents()）前，用fopen()+fgets()检查首几个字节是否为 BOM，或统一用mb_convert_encoding($content, 'UTF-8', 'UTF-8')强制重编码（会自动丢弃非法字节）
不可见字符的问题往往在调试时才暴露，且难以复现。最稳妥的做法是：所有外部输入，在进入业务逻辑前，都走一遍最小化清洗 —— 宁可多删，不可留隐患。
