notepad++不自动识别修复非法字符，需手动用正则[\x{200b}-\x{200d}\x{feff}\x{2028}\x{2029}\x{00a0}]批量替换清除零宽空格、bom等干扰符，前提是utf-8编码并勾选“正则表达式”和“匹配全部字符”。
Notepad++ 本身不提供“自动识别并修复非法字符”的功能，所谓“清理非法字符”，本质是手动定位、筛选并替换掉那些肉眼不可见但会破坏解析逻辑的 Unicode 控制符——比如 \u200B（零宽空格）、\uFEFF（BOM）、\u2028（行分隔符）等。直接点说：不是 Notepad++ 不够强，而是这些字符本就不该出现在源码或配置文本里。
为什么搜 \u200B 没反应？PCRE 不认 Unicode 转义
你在查找框输入 \u200B 并勾选「正则表达式」，结果完全不匹配——这不是你输错了，是 Notepad++ 底层用的 PCRE 引擎（v7.9+ 才部分支持）默认不解析 \uXXXX 这类写法。它只认字面字符或十六进制格式 \x{200B}，而且必须满足两个前提：
- 文件编码是 UTF-8（右下角状态栏显示「UTF-8」，不是「ANSI」或「GBK」）
- 勾选「匹配全部字符」（否则 \x{} 被当普通文本跳过）
- 不能用「扩展模式」——它会把
\x{200B}当成四个字母处理
最稳的办法：从出问题的文本里 Ctrl+C 一段可疑内容 → 粘贴到记事本再复制一次（有时能保留零宽字符）→ 回 Notepad++ 查找框直接粘贴这个“看不见的字符”，再勾选「匹配全部字符」+「正则表达式」测试是否命中。
批量删常见干扰符：用这个正则一次清干净
单个删 \u200B 效率低，还容易漏掉其他同类型字符。真正实用的是覆盖常用干扰区间的正则表达式：
[\x{200B}-\x{200D}\x{FEFF}\x{2028}\x{2029}\x{00A0}]
填入「替换」对话框（Ctrl+H），「替换为」留空，然后必须：
- 勾选「正则表达式」和「匹配全部字符」
- 确认当前编码是 UTF-8（如果不是，先「以 UTF-8 编码」看是否恢复可读，再「转为 UTF-8」保存）
- 这个范围不会误删普通空格、Tab 或换行符——它们的码位不在其中
它覆盖了 JSON 解析失败、JS 变量名中断、HTML 属性值校验报错的几类高频元凶，包括零宽空格 \u200B、零宽非连接符 \u200C、BOM \uFEFF、不间断空格 \u00A0 等。
删完还报错？重点检查字符串中间和注释里
很多人执行完替换就以为万事大吉，结果代码一运行还是莫名中断。根本原因是：这些字符常被插在变量名中间（如 use\u200BrName）、JSON key 里（{"na\u200Bme": "xxx"}）、或 HTML 属性值中（<div id="id\u200B1">）。肉眼看不出来，但 JS 引擎、XML 解析器、甚至 Python 的 <code>json.loads() 都会把它当真实字符处理。
验证方法：
- 在浏览器 Console 执行
JSON.stringify(yourString)，如果返回里出现"u200b"，就坐实了 - 对疑似段落再次执行「全部高亮显示」+ 上述正则，看是否还有未命中的高亮（可能因中途切换过编码导致匹配失效）
- 特别盯紧从网页复制的 Markdown 表格、第三方 API 响应示例、或自动生成的配置片段——这些是重灾区
真正难的不是怎么删，而是删到哪算完。有些字符（比如某些私有区符号或损坏的 UTF-8 字节序列）Notepad++ 根本无法用正则捕获，这时候得换工具：用 iconv -f UTF-8 -t UTF-8 -c 强制清洗，或用 Python 脚本逐字节过滤。但日常开发中，上面那个正则 + 手动验证，已覆盖 95% 的真实场景。
