问题源于Sublime Text编码猜测错误或文件编码冲突，解决方法是先以正确编码（如GBK）重新打开文件，再保存为UTF-8，并设置"default_encoding": "UTF-8"、"fallback_encoding": "GBK"以预防问题。
Sublime Text文件编码转换失败，这问题说白了，往往就是编辑器对文件原始编码的“猜测”出了偏差，或者你想保存的编码与文件内容本身有些冲突。最直接的解决办法，通常是先手动让Sublime Text以正确的编码重新打开文件，确保内容显示正常，然后再将其统一保存为一种通用、稳定的编码，比如UTF-8。
解决方案
-
识别并重新加载： 打开乱码文件后，先看Sublime Text右下角状态栏显示的编码（如果有的话）。如果显示
UTF-8
但内容是乱码，那多半它不是UTF-8
。这时，点击菜单栏的File
->Reopen with Encoding
，然后从弹出的列表中逐一尝试常见的中文编码，比如GBK
、GB2312
、Big5
，或者UTF-16
。通常，当你选择到正确的编码时，文件内容就会瞬间恢复正常。 -
统一保存为UTF-8： 一旦文件内容显示正常，立即点击
File
->Save with Encoding
，选择UTF-8
并保存。这是目前最推荐的通用编码，兼容性最好。 -
调整Sublime Text默认设置： 为了避免未来再次遇到类似问题，可以修改Sublime Text的默认编码偏好。
- 进入
Preferences
->Settings
。 - 在右侧的用户设置文件（
Preferences.sublime-settings
）中，添加或修改以下几行："default_encoding": "UTF-8", "fallback_encoding": "GBK", // 根据你最常接触的非UTF-8编码来设置，比如GBK "auto_detect_utf8": true, "auto_detect_utf8_sig": true
- 保存设置。
default_encoding
决定了新文件的默认编码，fallback_encoding
则是在自动检测失败时的备用编码。
- 进入
Sublime Text为什么总是出现编码问题？是不是我哪里没设置好？
这个问题其实挺普遍的，不是你一个人会遇到。Sublime Text在编码处理上确实有它的逻辑，但也不是万能的。它默认倾向于UTF-8，这在全球化背景下是好事。但问题在于，很多我们接触到的文件，尤其是在中文语境下，可能来自一些老旧系统、特定软件，或者干脆就是以前用GBK编码保存的。
Sublime Text在打开文件时，会尝试通过文件的字节序列来“猜测”它的编码。如果文件带有BOM（Byte Order Mark，字节顺序标记），比如UTF-8 BOM，那Sublime Text就能很准确地识别。但很多时候，特别是GBK文件，它们就没有BOM。这时候，Sublime Text就得靠一些启发式算法去猜，比如看文件里有没有符合某种编码特征的字节序列。一旦猜测失误，乱码就出现了。
我个人就经常遇到这种情况，比如从一些Windows服务器上下载下来的日志文件，或者同事在没有设置统一编码习惯的IDE里写的文件，它们通常都是GBK。Sublime Text一开，如果不提醒它，就很容易显示为乱码。所以，与其说是你没设置好，不如说是我们所处的文件生态环境太复杂，各种编码混杂，而Sublime Text的自动检测并非百分之百完美。上面提到的
fallback_encoding设置，就是为了在这种“猜测”失败时，给Sublime Text一个明确的备选项，让它知道当UTF-8不行时，可以试试GBK。
遇到文件乱码，除了手动转换，还有什么更高效的预防措施吗？
当然有，预防总是比事后补救要来得省心。我的经验是，从源头和习惯上入手，能大大减少编码问题的发生。
一个非常有效的策略是统一团队的编码标准。如果你们是一个团队在协作，从项目一开始就明确所有代码和文本文件都必须使用UTF-8编码，并且在版本控制系统（比如Git）中进行配置，这能避免很多不必要的麻烦。Git在处理文本文件时，如果发现编码变化，也会有提示，这本身就是一种监督。
其次，可以考虑使用一些Sublime Text插件来增强它的编码处理能力。比如
ConvertToUTF8这个插件，它能更好地识别和转换那些没有BOM的非UTF-8文件，甚至能在你打开文件时自动进行转换，省去了手动
Reopen with Encoding的步骤。安装后，它会尝试在后台帮你处理，很多时候你甚至感觉不到它的存在，文件就正常显示了。
另外，使用.editorconfig
文件也是一个非常好的实践。这是一个跨编辑器、IDE的配置标准。你可以在项目根目录下创建一个
.editorconfig文件，里面明确指定文件的编码，例如：
root = true [*] charset = utf-8 indent_style = space indent_size = 4 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true
这样，只要团队成员的编辑器安装了EditorConfig插件，打开项目文件时就会自动遵循这些编码和格式规范，极大地减少了因个人设置差异导致的编码问题。对我来说，这几乎是所有新项目的标配。
转换后文件内容还是不对劲，或者出现奇怪的字符，这又是怎么回事？
这种情况通常比单纯的乱码更复杂，说明问题可能不只出在简单的编码误判上。
一种可能性是你尝试的源编码本身就是错的。比如，一个文件实际上是GBK编码，你却尝试用Big5去重新打开它，那转换后自然还是不对劲，甚至可能出现新的、更奇怪的字符。这就像你试图用法语字典去翻译一篇德语文章一样，方向错了，结果肯定不对。
更棘手的是字符集不兼容或信息丢失。某些字符可能在原始编码中存在，但在你尝试转换的目标编码（比如UTF-8）中，并没有直接对应的表示。或者，在转换过程中，由于某些算法的限制，导致这些特殊字符的信息丢失了。这种情况在一些非常生僻的字符、特殊符号，或者从一些非标准字符集转换时尤为明显。
还有一种非常头疼的情况是文件内容混合了多种编码。比如，文件的大部分是UTF-8，但某个部分是从一个GBK文档里复制粘贴过来的，没有经过统一转换。这时候，Sublime Text或者任何编辑器都很难一次性正确处理。你可能需要找到那个混合编码的区域，单独进行处理。
最后，虽然不直接是编码问题，但有时显示乱码也可能是字体的原因。如果你的系统或Sublime Text没有安装支持特定字符集的字体，即使编码正确，也可能无法正常显示，而是显示为方框或问号。
面对这种顽固的“不对劲”，我的终极手段是使用十六进制编辑器。通过查看文件的原始字节数据，你可以更清楚地看到每个字符在文件中的真实存储形式。对照一些编码表（比如UTF-8和GBK的字节特征），往往能帮助你判断文件究竟是什么编码，或者问题出在哪个字节序列上。这虽然有点“硬核”，但却是解决深层编码问题的利器。
