汉化不会导致SQL文件乱码，真正原因是Sublime Text用UTF-8解码GBK/GB2312字节流；应先Reopen with Encoding→Chinese (GBK)使中文可读，再Save with Encoding→UTF-8转存，ST4需设default_encoding_on_save为"UTF-8"。
汉化本身不会导致 SQL 文件乱码，真正的问题是：Sublime Text 用 UTF-8 解了一个实际为 GBK（或 GB2312）的 SQL 文件字节流——“汉化”只是让你更早注意到这个错，而不是它引起的。
File → Reopen with Encoding → Chinese (GBK) 是唯一救急动作
打开乱码 SQL 文件后，右下角显示的 “UTF-8” 或 “Western (ISO 8859-1)” 只是当前解码方式，不是文件真实编码。盲目点状态栏切换、改 default_encoding 都无效。
- 立刻点击右下角编码名 → Reopen with Encoding → 选
Chinese (GBK)（有时也叫CP936） - 如果仍乱码，再试
Chinese (GB2312)；别试Western (Windows 1252)，它不含中文字符集 - 只要中文一出来、右下角变成
Chinese (GBK)，就说明原始编码识别对了 - 千万别点
Convert to UTF-8（老版本菜单里有）——它会静默重写文件且不提示，原始编码信息直接丢失
Save with Encoding → UTF-8 才是真正转码动作
前面所有操作只影响显示，内存里是正确 Unicode，磁盘文件一字未动。只有这一步才改磁盘内容。
- 必须在中文显示完全正常后，再执行 File → Save with Encoding → UTF-8（注意：不是
UTF-8 with BOM） - 保存后关闭再重开，右下角应显示
UTF-8，且中文依然正常 - 如果别人用记事本打开还是乱码，说明上一步没做对——文件根本没被正确识别为 GBK
- 验证是否真去除了 BOM：
xxd 文件名 | head -n1，输出不含ef bb bf才算干净
用户设置里 fallback_encoding 必须设为 "Chinese (GBK)"
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置。Sublime 只认自己内置的编码标识符。
- 正确写法：
"fallback_encoding": "Chinese (GBK)"（括号、空格、大小写全敏感） -
default_encoding已被官方标记为“已弃用”，它只影响新建空文件右下角显示，不控制保存行为 - 推荐配对使用：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)" - 务必删掉配置里的
detect_encoding: true——它会让 Sublime 主动跳过 BOM 去试 GBK，把带 BOM 的 UTF-8 文件判成乱码
Sublime Text 4 用户注意：fallback_encoding 已失效
ST4 彻底移除了 fallback_encoding，所谓“全局兜底编码”不复存在。你加 "fallback_encoding": "Chinese (GBK)" 到设置里，完全无效。
- 真正控制保存行为的是
default_encoding_on_save：设为"UTF-8"（注意大小写和短横），就能强制所有Ctrl+S静默以 UTF-8 写入磁盘 - ST4 中
ConvertToUTF8插件容易和原生探测逻辑冲突，导致状态栏编码显示错乱，慎用 - 混合编码项目（比如同一目录下既有 UTF-8 SQL 脚本又有 GBK 配置）必须靠右下角手动切编码，或用
.sublime-project绑定规则
最麻烦的不是单个文件，而是项目里 SQL 文件编码不统一——这种情况下，靠全局配置根本不管用，得提前在项目级绑定编码规则，否则等 Git 提交失败或同事打不开才反应过来。
