汉化本身不会导致复制粘贴乱码，真正原因是剪贴板编码协商失败：Windows 剪贴板以 GBK 提供字节流，而 Sublime 默认用 UTF-8 解码，造成“涓枃”等乱码；Sublime Text 4 已移除 fallback_encoding，粘贴解码逻辑硬编码为先试 UTF-8、再试 GBK（仅 Windows），故需手动 Reopen with Encoding → Chinese (GBK) 恢复显示。
汉化本身不会导致复制粘贴乱码——真正出问题的是剪贴板内容的编码协商失败。Sublime Text 从系统剪贴板读取中文时，若未明确指定解码方式，Windows 默认用 GBK 提供字节流，而 Sublime 默认用 UTF-8 去 decode，结果就是“锟斤拷”或空格块。
复制进 Sublime 后显示“涓枃”或方块？检查剪贴板来源编码
这不是 Sublime 的 bug，而是 Windows 剪贴板不带编码元信息，纯靠双方约定。常见场景：
- 从记事本（ANSI/GBK 模式）复制中文 → 粘贴进 Sublime → 显示“涓枃”
- 从微信/QQ/网页复制含中文的代码段 → 粘贴后部分汉字变问号或乱码
- 在 Sublime 中复制中文 → 粘贴到旧版 Notepad → 又变乱码（反向也成立）
验证方法：用 file -i（Linux/macOS）或 Notepad++ 打开原始来源文件，确认其真实编码是 GBK 还是 UTF-8；如果是网页或聊天软件，一律按 UTF-8 对待。
Sublime Text 4 必须设 default_encoding_on_save，fallback_encoding 已失效
ST4 彻底移除了 fallback_encoding 字段，写进去等于没写。控制“粘贴进来怎么解”和“保存出去用什么编码”的，是两个独立配置：
-
default_encoding_on_save：决定 Ctrl+S 时以什么编码写入磁盘，必须设为"UTF-8" -
default_encoding：已弃用，只影响新建空文件右下角显示，不影响粘贴行为 - 真正影响“粘贴进来怎么解”的，是 Sublime 内部对剪贴板字节流的默认 fallback 解码逻辑——它不走配置项，而是硬编码优先试
UTF-8，失败再试GBK（仅 Windows）
所以你看到“粘贴即乱码”，说明 Sublime 尝试用 UTF-8 解成功了（比如来源是 UTF-8 网页），但实际字节是 GBK ——此时唯一可靠动作是手动执行 Ctrl+Shift+P → 输入 Reopen with Encoding → 选 Chinese (GBK)，看是否恢复。别指望配置自动猜对。
粘贴前先确保当前文件是 UTF-8 无 BOM，否则越粘越乱
如果当前文件右下角显示的是 Chinese (GBK) 或 Western (ISO 8859-1)，直接粘贴 UTF-8 来源的中文，等于让 Sublime 用 GBK 解码器去 parse UTF-8 字节流，必然双乱码。
- 先确认当前文件能正常显示中文：右下角应为
UTF-8，且中文无异常 - 如果不是，执行
File → Reopen with Encoding → UTF-8（不是 Save） - 若仍乱码，说明文件原始就是 GBK，那就先
Reopen with Encoding → Chinese (GBK)，再Save with Encoding → UTF-8 - 保存后务必验证：用
xxd 文件名 | head -n1检查开头无ef bb bf（BOM）
很多用户卡在“明明设置了 UTF-8 却还乱码”，其实只是当前视图没切对编码，粘贴动作本身不触发重解码，它只把字节原样塞进当前解码上下文里。
构建系统输出中文乱码？那是另一条链路，和粘贴无关
如果你在 Build Results 面板里看到“涓枃”，那和剪贴板完全无关。这是 Python 子进程 stdout 字节流被 Sublime 错误 decode 导致的，必须改 .sublime-build 文件：
- 用
"cmd"数组而非"shell_cmd" -
"cmd"里 Python 路径必须绝对，且带-u参数（禁用缓冲） - 顶层加
"encoding": "utf-8"（注意不是放在 cmd 里） - 改完后必须手动切换构建系统，否则不生效
真正的难点从来不在怎么配，而在于区分清楚：你是想修“文件打开乱码”、“粘贴进来乱码”，还是“控制台输出乱码”——三者底层机制完全不同，混在一起调，只会越调越糊。
