sql中ascii和char函数可定位不可见字符，但需配合trim、replace及逐字节检查（如substring+ascii）才能准确识别并清理char(0)、char(9)、char(10)、char(13)、char(160)等；仅用trim无效，须显式替换，且生产环境须先select验证再分批update。
SQL中ASCII和CHAR函数能定位并清理不可见字符，但必须配合TRIM、REPLACE和逐字节检查，否则容易漏掉或误删。
查出字段里藏着哪些不可见字符
不可见字符（如CHAR(0)、CHAR(9)、CHAR(10)、CHAR(13)、CHAR(160)）不会在SELECT结果里显示，直接SELECT col FROM t看不出异常。得用ASCII()逐字符扫描：
SELECT col, SUBSTRING(col, 1, 1) AS first_char, ASCII(SUBSTRING(col, 1, 1)) AS first_ascii, SUBSTRING(col, LEN(col), 1) AS last_char, ASCII(SUBSTRING(col, LEN(col), 1)) AS last_ascii FROM t WHERE LEN(col) > 0;
常见陷阱：
-
ASCII()对空字符串返回NULL，不是0；对多字节字符（如中文）只取首字节，结果不可靠 - 某些数据库（如MySQL）的
ASCII()不支持Unicode，CHAR(160)（非断空格）可能被当成普通空格漏掉 - 别只查首尾——中间也可能插着
CHAR(0)，需用循环或递归CTE逐位提取（SQL Server可用master..spt_values辅助）
用CHAR()生成特定不可见字符做测试或替换
要验证某字符是否存在，或批量替换，得先用CHAR()构造它：
-- SQL Server 示例：把所有 CHAR(160)（不间断空格）换成普通空格 UPDATE t SET col = REPLACE(col, CHAR(160), ' ') WHERE col LIKE '%' + CHAR(160) + '%'; <p>-- PostgreSQL 要用 chr()，不是 char()，且参数是整数：chr(160)</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/ai/3716" title="腾讯会议AI小助手"><img src="https://img.php.cn/upload/ai_manual/001/246/273/178599567126945.png" alt="腾讯会议AI小助手" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/ai/3716" title="腾讯会议AI小助手" class="overflowclass">腾讯会议AI小助手</a> <p class="overflowclass">腾讯会议AI小助手是一款AI办公效率工具，腾讯会议推出的AI会议内容助理。</p> </div> <a rel="nofollow" href="/ai/3716" title="腾讯会议AI小助手" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
关键区别：
- SQL Server 和 MySQL 支持
CHAR(n)，n 是 0–255 的整数；PostgreSQL 用chr(n)，且 n 可超 255（支持 Unicode 码点） -
CHAR(0)在多数数据库中是字符串终止符，REPLACE(col, CHAR(0), '')可能失败或截断——得改用STUFF()（SQL Server）或正则（PostgreSQLREGEXP_REPLACE） -
CHAR(9)（制表符）、CHAR(10)（换行）、CHAR(13)（回车）常一起出现，建议合并处理：REPLACE(REPLACE(REPLACE(col, CHAR(13), ''), CHAR(10), ''), CHAR(9), ' ')
批量清理时为什么不能只依赖LTRIM/RTRIM
TRIM()（或LTRIM()/RTRIM()）默认只处理空格（CHAR(32)），对CHAR(160)、CHAR(9)完全无效：
-- 这样写没用：
SELECT LTRIM(RTRIM(' hello ')) -- 左右是 CHAR(160)，结果仍是 ' hello '
<p>-- 必须显式指定：
SELECT TRIM(CHAR(160) FROM ' hello ') -- SQL Server 2017+</p>
兼容性注意点：
- SQL Server 2016 及以前不支持
TRIM(char FROM str)语法，只能嵌套REPLACE - MySQL 的
TRIM()不支持多字符，TRIM(CHAR(160) FROM x)会报错，必须用REPLACE(x, CHAR(160), '') - 真正安全的清理往往要组合三步：先
REPLACE掉已知控制字符，再TRIM空格类，最后用DATALENGTH()（SQL Server）或OCTET_LENGTH()（PostgreSQL）核对字节长度是否变化
生产环境清理前必须验证的三件事
直接UPDATE可能破坏业务逻辑（比如某些系统用CHAR(1)作分隔符）：
- 先用
SELECT TOP 100抽样，对每个目标字段跑SELECT col, DATALENGTH(col), LEN(col)——若两者不等，说明含多字节字符或CHAR(0) - 在WHERE条件里加
col LIKE '%' + CHAR(0) + '%'这类判断时，记得测试执行计划：有些数据库无法走索引，全表扫描代价高 - 涉及JSON或XML字段时，
CHAR(10)/CHAR(13)可能是合法换行，删掉会导致解析失败——得用JSON_VALUE()或TRY_PARSE_JSON()预检结构
最麻烦的是混合编码：同一个字段里既有CHAR(160)又有CHAR(32)还有CHAR(8203)（零宽空格），这种得靠正则或应用层处理，SQL函数能力有限。
