Sublime Text 状态栏不显示编码格式是因为状态栏被关闭、文件未保存或编码未刷新；可通过菜单栏查看和修改编码，UTF-8与GBK互解会导致乱码，需通过设置fallback_encoding强制默认UTF-8。
Sublime Text 状态栏不显示编码格式？先确认是否启用
默认情况下 Sublime Text 的状态栏确实会显示当前文件编码（如 UTF-8、GBK），但前提是「状态栏」本身没有被关闭，且文件不是处于「未保存的临时缓冲区」状态。如果打开一个已有文件却看不到编码标识，大概率是以下原因之一：
- 状态栏被手动隐藏：菜单栏 → View → 勾选
Show Status Bar - 文件刚新建、尚未保存：此时 Sublime 无法确定该用什么编码读取，状态栏只显示
Plain Text或空白，不会显示编码 - 编码被强制覆盖但未刷新：比如通过
File → Reopen with Encoding切换后，状态栏可能延迟更新，可尝试切换 Tab 再切回来
如何手动查看和修改当前文件编码
状态栏只是快捷入口，真正决定编码的是 Sublime 的底层读写行为。查看和修改需通过菜单操作，而非配置文件或设置项：
- 查看当前编码：状态栏左下角文字即为当前生效编码（如
UTF-8），若显示Western (Windows 1252)或ISO 8859-1，说明文件很可能含乱码 - 重新以指定编码打开：菜单 →
File → Reopen with Encoding → [选择编码]（例如GB2312、GBK、UTF-8 with BOM） - 以指定编码保存：菜单 →
File → Save with Encoding → [选择编码]（注意：这会真正转换字节并覆写文件）
⚠️ 关键区别：Reopen with Encoding 只影响当前视图解码方式，不改文件内容；Save with Encoding 会重写文件字节流，慎用于生产文件。
为什么用 UTF-8 打开 GBK 文件会乱码，反之亦然
这不是 Sublime 的 bug，而是编码映射本质决定的。GBK 和 UTF-8 对中文的字节表示完全不同：
例如汉字“你”： GBK 编码是 0xC4, 0xE3 UTF-8 编码是 0xE4, 0xBD, 0xA0 如果用 UTF-8 解释 GBK 字节 0xC4 0xE3，会得到两个非法 Unicode 码位，Sublime 显示为 或乱码
常见现象：
本地项目发布到GitHub的完整工作流助手。自动执行：安全检查（.gitignore、排除敏感.env/凭据文件）、补齐开源文件（LICENSE、.gitignore）、git init/commit/branch、创建远程仓库、首次推送、可选打tag。支持git filter-repo历史敏感信息重写、force push、tag管理。Windows下走Credential Manager自动认证。触发词："发布到GitHub"、"上传到github"、"
- 中文注释/字符串变成方块、问号或一堆拉丁字母（如
ä½ å¥½）→ 实际是 UTF-8 字节被当 GBK 解码 - 文件开头出现
→ UTF-8 with BOM 被当 ANSI/GBK 打开 - 保存后文件变大、Git 提示大量修改 → 误用
Save with Encoding强制转码，导致不可逆变更
想让 Sublime 默认用 UTF-8 且禁用自动猜测？改 settings-user
Sublime 默认对无 BOM 的文件会尝试检测编码（包括 GBK），有时不准。可通过用户设置禁用启发式检测，强制 fallback 为 UTF-8：
{
"fallback_encoding": "UTF-8",
"detect_indentation": false,
"default_encoding": "UTF-8"
}
说明：
-
fallback_encoding：当无法确定编码时，统一按此解码（推荐设为UTF-8） -
default_encoding：新文件保存时默认使用的编码（不影响打开） -
detect_indentation关闭可避免某些文件因缩进特征被误判为其他编码（极少数情况）
注意：fallback_encoding 不会影响已明确声明编码的文件（如带 BOM 的 UTF-8），也不会阻止你手动用 Reopen with Encoding 切换。
最常被忽略的一点：Sublime 的编码判断完全依赖文件字节和 BOM，它不会读取文件名、路径或系统区域设置。所以同一份文件，在 Windows 上用记事本存成 GBK，传到 macOS 上用 Sublime 打开，依然会乱码——除非你主动选对编码。
