Sublime Text中真正修改文件编码的操作只有Reopen with Encoding（重解释字节）和Save with Encoding（转码写入），其余操作均不改动磁盘内容；乱码修复必须先用Reopen with Encoding选对原始编码（如Chinese (GBK)）使内容正常显示，再执行Save with Encoding → UTF-8完成可信转码。
Sublime Text 本身不提供“文本数据备份”功能，所谓备份，实际是文件复制、另存为、Git 提交前快照，或插件导出行为——所有这些操作都直接受当前文件编码状态影响。如果原始文件是 GBK 编码但被 Sublime 错误识别为 Windows-1252，你 Ctrl+C 复制粘贴到新文件里，再保存，新文件大概率仍是乱码字节；Git commit 前没确认编码，备份仓库就已固化错误字节。真正的兼容处理，不是在“备份时做点什么”，而是在“打开→编辑→保存”全链路守住编码一致性。
为什么直接复制粘贴不能算安全备份
Sublime Text 的剪贴板操作（Ctrl+C / Cmd+C）只传递 Unicode 字符串，不携带原始字节编码信息。一旦文件因识别错误导致内存中已是乱码（比如把 GBK 的 0xC4\E3 当作 Windows-1252 解成 “Äã”），复制出来的就是错的 Unicode，再粘贴保存为 UTF-8，只是把错误结果固化成 UTF-8 字节——看似“备份成功”，实则数据已损毁。
- 典型现象：原 GBK 文件中文正常，用 Sublime 打开后显示“涓枃”，复制粘贴到新文件并保存为 UTF-8，新文件打开仍显示“涓枃”，而非“中文”
- 根本原因：状态栏显示的编码名（如
Western (Windows 1252)）只是 Sublime 的当前解码假设，不是文件真实编码；Reopen with Encoding才是真正重解析字节的操作 - 风险点：团队协作中，有人直接复制“看起来正常”的内容发给同事，对方用 Notepad++ 打开发现全是问号——因为那根本不是 UTF-8 字节
Save with Encoding 不等于转码完成
Save with Encoding → UTF-8 这个菜单项常被误解为“把当前乱码转成 UTF-8”，其实它只做一件事：把内存里现有的 Unicode 字符串，用 UTF-8 编码写入磁盘。如果内存里已经是错的（比如“涓枃”），保存后就是错的 UTF-8 字节，无法还原。
- 必须前置步骤：
Reopen with Encoding → Chinese (GBK)（或GB2312、GBK 2010），让 Sublime 重新用正确编码解析原始字节，此时中文才真正变成正确的 Unicode - 验证是否成功：右下角状态栏应显示
GBK或Chinese (GBK)，且中文清晰可读；若仍模糊或部分乱码，换GB18030再试 - 之后再执行
Save with Encoding → UTF-8，才是把正确 Unicode 转为标准 UTF-8 字节，此时备份才可信
ConvertToUTF8 插件不是万能，但能降低误操作概率
ConvertToUTF8 的价值不在“全自动转换”，而在它把“识别→解码→保存回写”这个流程封装进一次 Ctrl+S，避免用户漏掉 Reopen with Encoding 这关键一步。但它依赖 chardet 的置信度判断，对短文本、纯 ASCII 混合中文、或 BOM 污染文件仍可能误判。
- 启用后，状态栏会动态显示检测到的原始编码（如
GBK (98%)），这是比默认 fallback 更可靠的提示 - 配置中必须设
"convert_on_save": true，否则仅解码显示，不自动保存为 UTF-8 - 慎用
"convert_on_load": true：若项目混有 UTF-8-BOM 和 GBK 文件，开启后可能把 UTF-8 文件误当 GBK 重解析，导致“中文变方块” - 真正批量备份前，建议先用
iconv -f GBK -t UTF-8 //path//*.txt（Linux/macOS）或 PowerShell 的Get-Content -Encoding Default | Set-Content -Encoding UTF8（Windows）做离线批量校验，再导入 Sublime
备份前最易忽略的三个硬性检查点
很多“备份后乱码”的问题，根源不在工具，而在没确认这三个事实：
- 确认文件是否有 BOM：
xxd -l 6 filename.txt查看开头是否为ef bb bf（UTF-8 BOM）。有 BOM 的 UTF-8 文件，Sublime 通常能正确识别；无 BOM 的 GBK 文件，ST4 几乎必然误判为Windows-1252 - 确认 Sublime 当前实际编码状态：右下角点击编码名，看弹出菜单顶部是否显示
Current: GBK或Current: UTF-8—— 这个Current:才是真实状态，状态栏文字可能滞后或误导 - 确认 Git 仓库的
.gitattributes是否设置了* text=auto eol=lf：若未设置，Windows 下提交的 GBK 文件可能被 Git 自动转行尾，进一步破坏编码完整性
