在SQL查询中怎样快速定位含有不可见字符的文本-SQL-PHP中文网

HEX()和encode()可暴露不可见字符，如CHAR(0)、制表符、不间断空格等，避免LENGTH()与CHAR_LENGTH()不一致导致的隐性问题，是排查数据污染最可靠手段。

在sql查询中怎样快速定位含有不可见字符的文本

SELECT 出来的字符串看着“干净”，不代表真干净。不可见字符（如 CHAR(0)、CHAR(9)、CHAR(160)）在结果集里不显示，但会悄悄拉长 LENGTH()、破坏唯一性、导致 WHERE = 失效。

直接查十六进制最可靠：

MySQL：SELECT col, HEX(col) FROM t WHERE col LIKE '%abc%'; —— 查到 '00' 就是 CHAR(0)，'09' 是制表符，'A0' 是不间断空格
PostgreSQL：SELECT col, encode(col::bytea, 'hex') FROM t; —— 同样看 00、09、a0 等字节序列
SQL Server 不支持 HEX()，改用：SELECT col, CAST(col AS VARBINARY(MAX)) FROM t;

注意：HEX() 和 encode() 返回的是字节级表示，一个中文字符可能占 3 字节（UTF-8），别把多字节当多个控制符误判。

如果 LENGTH(col) > CHAR_LENGTH(col)，说明字段里混入了多字节字符——可能是 emoji、CJK 扩展字，也可能是隐藏控制符（尤其 CHAR(0) 在某些驱动下会被截断，造成长度错乱）。

这个对比特别适合批量筛问题列：

MySQL/PostgreSQL：SELECT * FROM t WHERE LENGTH(col) != CHAR_LENGTH(col);
SQL Server：LEN() 等价于 CHAR_LENGTH()，不能用；得换 DATALENGTH(col)（返回字节数）和 LEN(col)（返回字符数）对比：WHERE DATALENGTH(col) > LEN(col) * 2（对 nvarchar，单个字符最多 4 字节，但通常 2 字节起步）

这个方法快，但不精准：它抓出所有“字节≠字符”的情况，得配合 HEX() 进一步确认是不是真有不可见字符。

想直接捞出含不可见字符的行？别手写一堆 LIKE '%'+CHAR(9)+'%'，用正则更省事：

MySQL 8.0+：SELECT * FROM t WHERE col REGEXP '[[:cntrl:]]|[u3000u00A0u200B]'; —— [[:cntrl:]] 覆盖 CHAR(0)–CHAR(31)，后面补上常见 Unicode 空格
PostgreSQL：SELECT * FROM t WHERE col ~ E'[\x00-\x1f\u3000\u00a0\u200b]'; —— 注意 E'' 启用 Unicode 转义，\x00-\x1f 匹配 ASCII 控制符
SQL Server 没原生正则，只能靠循环或 CLR，不推荐线上扫表；退而求其次用 CHARINDEX() 查单个字符：WHERE CHARINDEX(CHAR(0), col) > 0 OR CHARINDEX(CHAR(9), col) > 0

⚠️ 注意：CHAR(0) 在 SQL Server 的 CHARINDEX() 中被视作未定义字符，可能返回 0 即使存在——必须搭配 DATALENGTH() + SUBSTRING() + ASCII() 逐字节验证。

很多人只检查 SUBSTRING(col, 1, 1) 和 SUBSTRING(col, LEN(col), 1)，但 CHAR(0) 完全可能卡在第 5 位、第 12 位……一查就漏。

安全做法是用递归 CTE（SQL Server）或生成数字序列（MySQL 8.0+ numbers_table）逐位扫描：

SQL Server 示例（查前 100 位）：WITH pos(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM pos WHERE n
MySQL 8.0+ 可用 ROW_NUMBER() 配合 JSON_TABLE 模拟，但更简单是导出后用脚本处理——毕竟线上扫全表性能差，且 ASCII() 对多字节字符只取首字节，结果不可靠

真正要命的不是首尾空格，是中间那个看不见的 CHAR(0)：它会让客户端解析 JSON 失败、ORM 映射截断、甚至触发某些数据库驱动的静默 bug。定位时，宁可慢一点，也要扫到位。