应将 default_encoding 设为 “UTF-8” 以确保新建文件默认用 UTF-8 编码，同时设 fallback_encoding 为 “GBK” 以正确打开旧 GBK 文件；状态栏点击编码仅重解析不转码，需先 Reopen with Encoding 再 Save with Encoding 才真正转换。
如何正确设置 sublime Text 新建文件的默认编码为 UTF-8
sublime text 默认不强制新建文件用 UTF-8，尤其在中文 windows 环境下可能继承系统 ANSI（即 GBK）编码，导致新建文件保存后 git 提交或跨平台打开时乱码。关键不是“改个选项就完事”，而是要同时控制 default_encoding 和 fallback_encoding 两个行为。
-
default_encoding决定「新建文件」和「另存为」时的默认编码 —— 必须设为"UTF-8" -
fallback_encoding是打开未知编码文件时的“保底解码方案”——建议设为"GBK"，否则旧项目里的 GBK 文件一打开就是乱码 - 用户设置文件（
Preferences → Settings – User）必须是合法 jsON：末尾不能有多余逗号，键名必须用双引号包裹
{ "default_encoding": "UTF-8", "fallback_encoding": "GBK" }为什么右下角点“UTF-8”不等于真正转码
点击状态栏右下角显示的编码名（如 UTF-8 或 Western (Windows 1252)），只是告诉 Sublime “请用这个编码重新解析当前文件内容”，它不会修改磁盘上的字节。如果你看到乱码，盲目点一下 UTF-8，很可能越点越错。
- 正确流程是：
File → Reopen with Encoding → GBK（先正确读取）→ 确认中文正常 →File → Save with Encoding → UTF-8（真正写入 UTF-8 字节） - 如果原文件是 GBK，却直接
Save with Encoding → UTF-8，Sublime 会把 GBK 字节当 UTF-8 解码后再以 UTF-8 写出，结果是双重乱码，不可逆 - 状态栏显示的编码名，仅反映 Sublime 当前“怎么读”，不是“文件实际是什么编码”
ConvertToUTF8 插件能解决什么，不能解决什么
这是目前最实用的中文编码兼容方案，但它的作用边界很明确：它让 Sublime 在打开 GBK 文件时自动识别并以 UTF-8 方式显示，保存时再自动转回 GBK（可配）或统一存为 UTF-8。它不是万能编码转换器，也不是批量重写工具。
- 安装后，打开 GBK 文件通常自动显示正常，无需手动
Reopen with Encoding - 保存时默认转为 UTF-8（插件配置中
"save_on_focus_lost": true可启用失焦自动保存） - 它不支持反向操作：不能把 UTF-8 文件一键转成 GBK；也不提供“全项目批量转码”功能
- 若需批量处理，仍需外部命令，例如 linux/macOS 下：
for f in *.txt; do iconv -f GBK -t UTF-8 "$f" -o "utf8_$f"; done
验证是否生效：别只看新建文件，要测真实场景
很多人改完设置就以为搞定了，结果打开一个老项目里的 README.md 还是方块。这是因为 default_encoding 只影响新建文件，而打开已有文件的行为由 fallback_encoding 和插件共同决定。
- 测试方法：关闭所有文件 →
Ctrl+N新建空白页 → 输入中文 →Ctrl+S保存为test.txt→ 用记事本或file test.txt命令确认其编码确实是 UTF-8（无 bom） - 再找一个已知是 GBK 的文件（比如 Windows 记事本保存的中文文本），用 Sublime 打开 —— 如果直接显示正常，说明
fallback_encoding或 ConvertToUTF8 生效了 - 右下角状态栏必须显示
UTF-8（非UTF-8 with BOM），否则某些语言解析器（如 python、json）会报错
真正容易被忽略的是：**Sublime 不会告诉你一个文件原本是什么编码**。它没有“编码探测引擎”，所有自动识别都靠插件启发式匹配。所以哪怕装了 ConvertToUTF8，遇到混合编码的老旧项目，仍得靠人眼比对 + 多次 Reopen with Encoding 尝试 —— 这不是设置问题，是文本编码本身的历史遗留现实。