Sublime Text中文乱码主因是解码与保存编码不匹配，需先用file -i（Linux/macOS）或Notepad++（Windows）确认真实编码，再用Reopen with Encoding临时解码、Save with Encoding转存；用户设置应配对使用"default_encoding": "UTF-8"和"fallback_encoding": "Chinese (GBK)"，并禁用detect_encoding和save_with_bom。
Sublime Text 中文乱码不是字体或系统语言问题，而是解码方式和保存编码不匹配——90% 的“乱码”根本没改对地方，只是在瞎试编码。
怎么确认文件真实编码，而不是靠猜
Sublime 右下角显示的 UTF-8 或 Western (ISO 8859-1) 只是它当前怎么读这个文件，不是文件本来就是这个编码。满屏方块时，它可能正用 UTF-8 解一个 GBK 文件。
- Linux/macOS 下直接运行：
file -i 文件名，看输出里的charset=字段（如charset=gbk） - Windows 用户用
Notepad++打开 → 右下角明确显示GBK或UTF-8-BOM，比 Sublime 更可信 - 别信网上说的“用 Python 脚本检测”——短文本、混合编码、BOM 干扰下，纯字节分析误判率极高
Reopen with Encoding 和 Save with Encoding 到底该点哪个
这是最常点错的两个菜单项，功能完全相反，点错一次就可能把能读的文件“转坏”。
-
Reopen with Encoding：只改当前视图怎么读文件，不写磁盘，安全。适合乱码后立刻试Chinese (GBK)、UTF-8、GB2312，看到中文就停 -
Save with Encoding：真把当前视图内容按新编码重写到磁盘，不可逆。必须在Reopen with Encoding确认显示正常后才用 - 千万别点
Convert to UTF-8（老版本菜单里有）——它会静默重写，且不提示，原始编码信息直接丢失
用户设置里 fallback_encoding 为什么不能写 "UTF-8"
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置，等于没设。Sublime 只认自己内置的编码标识符。
OpenAI Developer Docs
下载
一款AI办公效率工具，主要用于使用CLI（curl/jq）通过OpenAI Docs MCP服务器查询OpenAI官方文档。当任务涉及OpenAI API（Responses、Chat Completions、Realtime等）、SDK、ChatGPT Apps SDK、Codex、MCP集成、端点结构、参数、限制或迁移，且需要最新官方指导时调用，适合需要提升相关任务效率的用户。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"或"Western (ISO 8859-1)" -
default_encoding才支持"UTF-8"，它管新建文件和显式保存时的默认编码 - 推荐配对使用：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)"，兼顾新文件和旧项目乱码文件 - 顺手删掉配置里可能存在的
"detect_encoding": true——这个开关会让 Sublime 主动跳过 UTF-8 去试 GBK，反而把带 BOM 的 UTF-8 文件判成乱码
保存后其他工具报错 Non-UTF-8 code starting with '\xef'
这不是 Sublime 没设对，而是它悄悄加了 UTF-8 BOM（\xef\xbb\xbf），Python、Git、Shell 脚本都把它当非法字符。
- 检查是否生效：
xxd 文件名 | head -n1，输出不含ef bb bf才算干净 - 关掉 BOM：在用户配置里加
"save_with_bom": false - 注意：
Windows记事本生成的 UTF-8 文件默认带 BOM，Sublime 若设了save_with_bom: true，再保存就会“传染”给其他文件
真正麻烦的是混合编码——比如从 Word 复制粘贴进来的文本含隐藏控制字符，或者文件本身开头是 UTF-8 BOM、中间混着 GBK 字节。这种情况下，Reopen with Encoding 可能只修复局部，得先用 UTF-8 打开，再手动清理异常字符。
