sublime text无法通过where框直接搜索“未按标准编码的文件”，但可反向定位：where填src/**/*.js,src/**/*.ts等目标路径，find框用正则\[\u4e00-\u9fff\u3400-\u4dbf\uf900-\ufaff\]匹配汉字码点，配合右下角显示western/iso-8859-1时搜不到中文来识别误判文件。
Where框填什么才能让搜索只命中未按标准编码的文件
Sublime Text 本身不提供“按编码合规性搜索”的原生能力。所谓“不符合编码标准的源文件”，实际是指：文件内容是 UTF-8 编码，但 Sublime 没识别出来，仍以 Western / ISO-8859-1 等方式解码——此时中文显示为乱码，Ctrl+F 搜中文也完全无响应。
你不能靠 Where 框直接过滤“编码不合规”，但可以反向锁定这类文件：
- 先确保项目已加载（
File → Open Folder…），且Where填.（单个点）搜整个项目 - 在
Find框输入一个典型中文词（如用户），不勾选Regular Expression，但务必确认右下角状态栏显示的是Western或ISO-8859-1 - 如果搜不到，而你知道该词确实存在于某些 .js/.ts/.py 文件里，那这些文件大概率就是“被误判编码”的目标
用正则绕过编码识别失败，直接扫字节级中文
当 File → Reopen with Encoding → UTF-8 还没来得及手动执行时，可用正则跳过解码层，直击 Unicode 码点：
- 启用
Regular Expression模式（点.*图标） -
Find框填[\u4e00-\u9fff\u3400-\u4dbf\uf900-\ufaff]—— 覆盖常用汉字、扩展 A/B 区、兼容汉字 -
Where填src/**/*.js,src/**/*.ts（限定范围，避免扫日志或二进制） - 匹配结果里，凡是显示为方块、问号或乱码的，就是 Sublime 当前以错误编码打开的文件
注意：\u4e00-\u9fff 单独用会漏掉《》【】、emoji 和生僻字；[\u4e00-\u9fff\u3400-\u4dbf\uf900-\ufaff] 是更稳妥的覆盖集。
为什么搜到了却改不了？Save All 不生效的隐藏原因
你用正则定位到乱码文件、手动 Reopen with Encoding → UTF-8 后编辑，再 Replace All in Files，结果保存后还是乱码——问题不在搜索，而在 Sublime 的编码写入逻辑：
- 替换操作发生在当前解码视图下，但保存时默认按“当前视图编码”写回磁盘（即仍是 Western）
- 必须在替换前，先对每个目标文件执行
File → Save with Encoding → UTF-8，再做替换 - 或者统一改掉全局行为：Preferences → Settings – User 中加
"default_encoding": "UTF-8"（仅影响新建文件）+ 手动对存量文件批量重编码 -
Save All不会改变单个文件的写入编码，它只保存当前视图所用编码下的内容
别依赖 auto-detect，真正的编码检查得靠命令行
Sublime 的自动编码检测对无 BOM 的 UTF-8 中文文件基本不可靠，尤其短文本、纯中文段落或混合标点时。验证真实编码不能只看右下角：
- Linux/macOS 终端运行：
file -i your_file.js，输出含charset=utf-8才可信 - Windows 可用 VS Code 打开同一文件，看底部状态栏显示的编码（VS Code 的检测更鲁棒）
- 如果
file -i显示charset=iso-8859-1但文件里全是中文，说明文件本身已损坏或被错误转码过
真正要批量筛查“疑似编码异常”的源文件，得结合 shell 脚本 + file -i + grep -v 'utf-8'，Sublime 只适合后续人工复核和修复。
