sublime中“非法中文字符”指utf-8文件内混入的gbk汉字、全角空格\u3000、零宽字符\u200b、替代符\ufffd或bom残留等非标准字节，需用正则[^\x00-\x7f\u4e00-\u9fff\u3000-\u303f\uff00-\uffef]主动检测并人工甄别。
非法中文字符 ≠ 普通汉字，得先定义“非法”
“非法中文字符”在 Sublime 里没有统一标准——它取决于你的使用场景：UTF-8 文件里混入 GBK 编码的汉字（如从旧版记事本复制粘贴），或文件里藏了不可见的全角空格 \u3000、零宽字符 \u200b、替代字符 \ufffd（），甚至 BOM 头后多出的乱码字节。这些不是语法错误，但会导致 Python 解析失败、JSON 校验报错、Git 提交异常或构建时莫名中断。
关键点：Sublime 不会主动标记它们，也不会在构建输出里告诉你“第 12 行有非法字节”，它只管按当前编码读取并显示。所以检测必须靠你主动触发，且要区分“显示乱码”和“实际非法字节”。
用正则查 Unicode 范围外的字符最直接
打开 Find 面板（Ctrl+F / Cmd+F），勾选 Regular Expression，输入以下任一模式：
-
[^\x00-\x7F\u4e00-\u9fff\u3000-\u303f\uff00-\uffef]—— 匹配所有非 ASCII、非汉字、非中文标点的字符（含全角字母、日文平假名等） -
[\u2000-\u206f\u2028\u2029\u202a-\u202e]—— 专门抓零宽空格、行分隔符、双向控制符等“隐形破坏者” -
\ufffd—— 直接搜替换失败后留下的豆腐块（），说明某处解码失败
注意：Find All 后检查每处匹配是否合理。比如 （全角空格）在中文排版中合法，但在代码变量名里就是非法；（ 和 ( 混用也可能引发语法问题。
构建报错时定位非法字符的实操路径
Python 报错如 SyntaxError: Non-UTF-8 code starting with '\xe5' in file 或 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa3，本质是文件里存在 UTF-8 无法解析的字节。此时别急着改代码，先确认问题源头：
- 右下角状态栏看当前编码，如果不是
UTF-8，立刻Reopen with Encoding → UTF-8重载 - 若重载后仍报错，说明文件里真有非法字节：用上面正则查
[^\x00-\x7F]，再逐个删掉可疑位置（尤其注释、字符串开头/结尾、空行） - 构建命令里加
-u参数强制输出 UTF-8（如"cmd": ["python", "-u", "$file"]），避免终端编码污染 - 如果用 Anaconda 插件，确保
env里设了"PYTHONIOENCODING": "utf8"，否则print()输出可能被截断或转义
插件能自动化，但别依赖自动修复
像 ConvertToUTF8 或 CodePage Encoding 这类插件，确实能在打开时自动尝试 GBK→UTF-8 转换，但它们不告诉你转换是否出错——有些字根本无法映射，会变成 \ufffd 留在文件里。更危险的是，它们可能静默覆盖原文件编码信息，导致后续协作出问题。
真正可靠的流程是：
- 先用
File → Reopen with Encoding尝试GBK、GB2312看能否正常显示 - 能显示 → 全选复制 → 新建文件 →
Save with Encoding → UTF-8（不带 BOM） - 不能显示 → 用十六进制插件（如
HexViewer）打开，直接看异常字节序列（如a3 c7），再对应查码表
编译报错排查中最容易被忽略的，不是哪一行写错了，而是哪一行根本没被正确读进去——那个看不见的 \u200b，可能就卡在 if 关键字后面，让整个条件判断失效。
