ascii() 和 unicode() 仅返回字符串首字符的编码值，无法扫描整串；常见误用是直接用其筛选异常字符，实际只能检测首字符；定位隐藏字符需逐位遍历而非只查首尾。
查单个字符的 ASCII 或 Unicode 值，但别指望它“扫完整串”
ASCII() 和 UNICODE() 都只看输入表达式的**第一个字符**，不管后面还有多少。比如 ASCII(' x') 返回的是空格（32），不是 x（120）；UNICODE(N' abc')（开头是 CHAR(160) 非断空格）返回 160，不是 a 的 97。
常见误用：直接 WHERE ASCII(col) NOT BETWEEN 32 AND 126 —— 这只能筛出「首字符就异常」的行，漏掉绝大多数问题数据。
- 对
VARCHAR列用ASCII()，遇到中文/emoji 通常返回首字节值（如 GBK 下“中”的首字节是 214），不可靠 - 对
NVARCHAR列必须用UNICODE()，ASCII()会隐式截断或报错 -
ASCII('')返回NULL（SQL Server）或0（MySQL），注意空值处理
定位隐藏字符：得逐位取 + 判断，不能只查头尾
不可见字符（如 CHAR(0)、CHAR(9)、CHAR(10)、CHAR(13)、CHAR(160)）常藏在字符串中间，SUBSTRING(col, 1, 1) 和 SUBSTRING(col, LEN(col), 1) 只能抓首尾。
正确做法是循环遍历每一位，例如 SQL Server 中用递归 CTE 或 master..spt_values 辅助生成数字序列：
SELECT col, n AS pos, SUBSTRING(col, n, 1) AS char_at_pos, ASCII(SUBSTRING(col, n, 1)) AS ascii_val FROM t CROSS JOIN (SELECT number AS n FROM master..spt_values WHERE type = 'P' AND number BETWEEN 1 AND 50) nums WHERE n
- 避免硬写
BETWEEN 1 AND LEN(col)在 JOIN 条件里——SQL Server 不支持，需提前限定范围 - MySQL 没有
spt_values，可用递归 CTE（8.0+）或临时数字表替代 - 逐位扫描性能差，生产环境务必加 WHERE 过滤可疑行（如
LEN(col) != DATALENGTH(col)可疑含CHAR(0)）
区分 ASCII 和 Unicode 处理逻辑，否则字符全乱码
同一个字符，在不同函数和类型下结果完全不同：
-
ASCII('a')→ 97，UNICODE(N'a')→ 97（一致） -
ASCII('á')（Latin-1 扩展字符）→ 可能返回 225，但取决于列编码；UNICODE(N'á')→ 稳定返回 225 -
ASCII(N'飞')→ 报错或截断为首个字节（如 233），UNICODE(N'飞')→ 正确返回 39134 -
CHAR(160)生成的是 Latin-1 非断空格，NCHAR(160)在多数系统中仍为普通空格，真正要生成 Unicode 非断空格得用NCHAR(8288)或NCHAR(0x202F)
结论：处理含国际化文本的字段，一律用 NVARCHAR + UNICODE() + NCHAR()，别混用。
清理前必须 SELECT 验证，UPDATE 不能一把梭
用 REPLACE(col, CHAR(160), ' ') 看似简单，但风险极高：
-
CHAR(160)和CHAR(32)在某些前端渲染下视觉无差别，但语义不同（影响搜索、排序、去重） - 直接
REPLACE(col, CHAR(0), '')可能导致 VARCHAR 字段被截断（SQL Server 中CHAR(0)是字符串终止符） - 一次
UPDATE全表替换，若逻辑有误，无法回滚（尤其没备份时）
安全流程只有三步：SELECT 定位 → SELECT 验证替换效果 → 小批量 UPDATE（如 TOP 1000）→ 再查 → 确认无误再扩量。
最易被忽略的一点：CHAR(160) 在某些 COLLATION 下会被 TRIM() 或 = 判断当成普通空格，但 DATALENGTH() 能暴露它 —— 它占 1 字节，而 NCHAR(160) 在 UTF-16 下占 2 字节。这点不验证，清洗就等于没洗。
