REGEXP_REPLACE在AL32UTF8下可清除ASCII控制符（CHR(1)–CHR(8)、CHR(11)–CHR(12)、CHR(14)–CHR(31)）及启用Unicode支持后的\p{Zs}、\p{Cf}，但CHR(0)必先用REPLACE处理，零宽字符需显式写出且依赖字符集。
REGEXP_REPLACE 在 Oracle 中能清除大部分不可见字符，但对 CHR(0)、零宽空格（\u200B）、BOM（\uFEFF）等必须分情况处理——它不自动跳过截断，而是受制于数据库字符集和正则引擎能力。
哪些不可见字符 REGEXP_REPLACE 真的能干掉
在 AL32UTF8 字符集下，REGEXP_REPLACE 可靠匹配并替换：
- ASCII 控制符（
CHR(1)–CHR(8)、CHR(11)–CHR(12)、CHR(14)–CHR(31)），但CHR(0)会被静默截断（Oracle 字符串以\0结尾） - 常见 Unicode 分隔符，如
\p{Zs}（空白分隔符）、\p{Cf}（格式字符），前提是启用 Unicode 属性类支持（12c+ 且 NLS_CHARACTERSET=AL32UTF8） - 显式写出的零宽字符，例如
REGEXP_REPLACE(col, '\u200B|\u200C|\u200D|\uFEFF', '')—— 这种写法只在 AL32UTF8 下生效
为什么 [^a-zA-Z0-9\s] 会漏掉关键非法字符
这个看似“通用”的正则表达式实际存在三类盲区：
- 它不匹配全角空格（
\u3000）、软连字符（\u00AD）、零宽空格（\u200B）——这些不属于\s，也不在 ASCII 范围内 - 它把中文标点（如
。！？）一并删掉，而业务上往往需要保留 - 若字段含四字节 UTF-8 字符（如某些 emoji），而数据库字符集是
WE8ISO8859P1，REGEXP_REPLACE根本无法解析完整码点，直接跳过或报错
CHR(0) 必须绕开 REGEXP_REPLACE 单独处理
CHR(0) 是 Oracle 的硬伤：任何含 CHR(0) 的字符串传入 REGEXP_REPLACE 都会被截断，函数返回结果从 CHR(0) 开始丢弃后续所有内容。
- 正确做法是用
REPLACE(col, CHR(0), '')先清理一遍，再进正则流程 - 如果字段可能含多个
CHR(0)，需嵌套使用：REPLACE(REPLACE(col, CHR(0), ''), CHR(0), '')（虽然看起来冗余，但 Oracle 的REPLACE不支持全局标志，单次调用只换第一个） - 验证是否存在：
INSTR(col, CHR(0)) > 0，别依赖LENGTH对比，因为CHR(0)不影响长度计算
生产环境推荐的两步清洗组合
不要指望一条正则解决全部问题。入库前或导出前清洗，建议按顺序执行：
- 第一步：用
REPLACE干掉CHR(0)和已知固定字节非法符（如CHR(13)、CHR(10)若需保留换行则跳过） - 第二步：用
REGEXP_REPLACE处理剩余控制符与 Unicode 异常符，例如：REGEXP_REPLACE( REPLACE(col, CHR(0), ''), '[' || CHR(1) || '-' || CHR(8) || CHR(11) || '-' || CHR(12) || CHR(14) || '-' || CHR(31) || '\u200B\uFEFF]', '' )
- 注意：若数据库字符集不是
AL32UTF8，必须删掉\u200B、\uFEFF等 Unicode 转义，改用TRANSLATE+ ASCII 范围组合
最易被忽略的是字符集前提——没确认 NLS_CHARACTERSET 就写 \p{Zs} 或 \u200B，结果既不报错也不生效，数据照旧脏着。
