弹窗乱码主因是系统级字体缺失或font_face未生效,与汉化包无关;Windows需确认Microsoft YaHei启用并配置"font_face":"Microsoft YaHei"及"directwrite";macOS/Linux须验证locale为UTF-8且中文字体已安装并刷新缓存。

汉化后弹窗(如保存提示、编码选择框、命令面板输入框)出现乱码,基本可判定为系统级字体缺失或 Sublime 渲染链路未正确注入中文字体上下文——和汉化包是否生效无关,90% 以上是 font_face 配置未生效或字体本身不支持 Unicode 范围。
弹窗乱码 ≠ 汉化失败,而是字体回退失败
Sublime 的弹窗(包括右下角编码菜单、Ctrl+Shift+P 命令面板、保存确认框)走的是系统原生 UI 渲染路径,不读取语言包里的文本资源,只依赖操作系统字体 + font_face 设置。即使菜单汉化成功,弹窗仍可能显示方块或“□”,因为:
- Windows 下未安装或未启用
Microsoft YaHei(微软雅黑),或该字体被禁用/损坏 - macOS 下
PingFang SC或Hiragino Sans GB缺失,或系统locale不是 UTF-8 - Linux 下未安装
fonts-wqy-microhei或noto-cjk,且fontconfig缓存未刷新 -
Preferences → Settings–User中未显式设置"font_face",或拼写错误(如写成Microsoft YaHei UI)
Windows 用户必须检查的三件事
弹窗乱码在 Windows 上最常见,核心堵点是字体注册与 DirectWrite 渲染开关:
- 打开控制面板 → 字体 → 搜索
Microsoft YaHei,确认存在且状态为“已启用”;若无,从 Windows 安装镜像或官方渠道补装 - 在
Preferences → Settings–User中确保含以下最小配置:{ "font_face": "Microsoft YaHei", "font_options": ["directwrite"] } - PowerShell 执行
[System.Text.Encoding]::UTF8.WebName,输出必须是utf-8;若为unicode-1-1-utf-8等非常规值,需重置系统区域设置(控制面板 → 区域 → 管理 → 更改系统区域设置 → 勾选“Beta 版:使用 Unicode UTF-8 提供全球语言支持”)
macOS/Linux 用户验证 locale 和字体路径
macOS 弹窗乱码常因 Core Text 无法加载中文字体族,Linux 则多因 fontconfig 缓存未更新:
- 终端执行
locale | grep -E "(LANG|LC_ALL)",输出必须含UTF-8(如LANG=zh_CN.UTF-8);若为en_US.ISO8859-1,需修改/etc/locale.conf或用户 shell profile - macOS 检查字体册(Font Book)中
PingFang SC是否启用;若无,手动安装 Apple 提供的完整字体包 - Linux 执行
fc-list :lang=zh,确认输出含中文字体路径;若空,安装fonts-wqy-microhei(Debian/Ubuntu)或google-noto-cjk(Arch),再运行fc-cache -fv - Sublime 用户设置中写
"font_face": "PingFang SC, Hiragino Sans GB",逗号分隔,首项必须存在
别碰 .sublime-package 里的二进制资源
有人试图解压 Default.sublime-package 修改弹窗相关字符串,这是无效且危险的操作:
- ST3.3+ 已移除对弹窗文本的硬编码资源加载,所有 UI 文本由系统字体 + Unicode 渲染引擎动态合成
- 手动编辑
.sublime-package内的menu_en.json或messages.pak不影响弹窗,只会让主菜单变乱 - 社区维护的 SublimeText-Localization 只覆盖菜单栏和命令面板的静态文本,不干预系统级弹窗渲染
真正起效的只有字体配置和系统 locale —— 其他任何操作都是绕远路。











