sublime text右下角显示当前识别编码，但可能误判；应通过“reopen with encoding”尝试常见编码验证，配合设置fallback_encoding为gbk等提升准确率。
怎么在 Sublime Text 里一眼看出当前文件的编码？
Sublime Text 默认会在窗口右下角显示当前文件的编码，比如 UTF-8、GBK 或 Western (ISO 8859-1)。但这个区域有时被忽略，或者被插件遮挡；更关键的是——它只显示「Sublime 当前认为的编码」，不一定是文件真实编码，尤其当文件没带 BOM、又混用了中文时，容易误判。
- 鼠标移到右下角编码名称上，会短暂弹出提示：“Reopen with Encoding” 和 “Save with Encoding”，这是判断依据之一
- 如果显示
UTF-8但中文是乱码，大概率实际是GBK或GB2312；反之显示GBK却乱码，可能是UTF-8 with BOM被错误识别 - 不要依赖状态栏文字就直接编辑——先用「Reopen with Encoding」尝试几种常见编码看效果
乱码了，怎么快速切编码重载文件？
不是改设置，是临时用另一种编码重新读取当前文件内容。这步能立刻验证猜测，比猜半天靠谱得多。
- 快捷键：
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），打开命令面板 - 输入
Reopen with Encoding，回车后会出现编码列表，常用项有：UTF-8、UTF-8 with BOM、GBK、GB2312、ISO 8859-1 - 选一个试试，如果中文立刻变正常，说明原始编码就是它；如果更乱，换下一个
- 注意：
Reopen with Encoding不改变文件本身，只是“用这个编码再读一遍”，安全可逆
为什么有时候改了编码还是乱码？
因为 Sublime 的编码检测逻辑有局限：它优先看文件开头是否有 BOM，其次查前几百字节的字节模式，最后 fallback 到系统默认或上次记录值。没有 BOM 的 UTF-8 和 GBK 文件，在纯英文段落里字节表现几乎一样，极易混淆。
- 真实场景中，.txt、.log、从 Windows 记事本保存的文件，大概率是
GBK；从 VS Code、Mac 自带编辑器来的，大概率是UTF-8 -
UTF-8 with BOM是个特例：Windows 记事本默认加 BOM，Sublime 会识别为UTF-8 with BOM，但很多工具（如 Pythonopen()）不认 BOM，导致后续处理出错 - 如果切换编码后仍局部乱码（比如只有某几行乱），说明文件本身编码就不统一——可能复制粘贴进来了不同来源的内容，这种没法靠单次切换解决
想一劳永逸避免乱码，该设什么配置？
不能一劳永逸，但可以大幅降低概率。关键是把「新建文件默认编码」和「自动检测失败时 fallback 编码」分开控制。
- 打开
Preferences → Settings，在右侧用户设置里加这两行：
"fallback_encoding": "GBK", "default_encoding": "UTF-8"
default_encoding 只影响新建空白文件；fallback_encoding 才是关键——当 Sublime 无法确定编码时（比如无 BOM + 检测失败），就用它来尝试解码fallback_encoding 设成 GBK 比 UTF-8 更实用；但若团队跨平台协作，建议统一要求源文件存为 UTF-8 without BOM，并用 ESLint / pre-commit 检查真正麻烦的从来不是找不到编码选项，而是文件本身就没用一致编码保存过。看到乱码第一反应不该是“换哪个编码”，而是先问：这文件从哪来？有没有可能已经被转码过两次？
