sublime text 默认不支持 utf-8 多字节特殊字符是因字体和解码逻辑未覆盖相关 unicode 范围；需配置含 emoji 的字体回退链、确保文件为无 bom 的 utf-8 编码，并重启编辑器生效。
Sublime Text 默认不支持显示或正确处理 UTF-8 多字节特殊字符（如 emoji、全角符号、零宽字符、某些 Unicode 4.0+ 新增汉字），也不是它“坏了”，而是默认启用的字体和解码逻辑不覆盖这些范围——你得手动告诉它：用什么字体渲染、按什么规则读取、哪些字节该被允许。
为什么 emoji 和部分 Unicode 字符显示为方块或乱码
Sublime Text 渲染文本依赖两个关键层：一是文件实际编码是否为合法 UTF-8，二是当前 font_face 是否包含对应字形。很多中文字体（如 SimSun、NSimSun）根本不含 emoji 区段（U+1F600–U+1F64F 等），一遇到就 fallback 成□；另外，如果文件混入了 UTF-8 不兼容字节（比如从微信复制带 BOM 的 emoji），Sublime 会静默截断或显示 。
常见现象包括：
- 输入 ? 后保存再打开，变成
😂或空白 - Git 提交日志里有 ?，但在 Sublime 里显示为
- 正则搜
[^\x00-\x7F]能匹配到中文，但匹配不到 ?
设置支持 emoji 的字体链（Windows/macOS/Linux 通用）
不能只换一个字体，要配置字体回退链（font fallback），让 Sublime 在主字体缺字时自动切到含 emoji 的字体。直接改 Preferences.sublime-settings：
{
"font_face": "Consolas, \"Apple Color Emoji\", \"Segoe UI Emoji\", \"Noto Color Emoji\", \"HanaMinA\", \"HanaMinB\"",
"font_size": 12
}
说明：
-
"Apple Color Emoji"macOS 原生支持，无需安装 -
"Segoe UI Emoji"Windows 10/11 自带，Win7 需手动下载安装 -
"Noto Color Emoji"Google 开源字体，跨平台可用，推荐下载后安装系统字体库 - 避免把
"Microsoft YaHei"放在链首——它不含 emoji，会直接卡住 fallback
确保文件是干净的 UTF-8 编码（而非 UTF-8 with BOM 或混合编码）
很多 emoji 来源（微信、钉钉、网页复制）会悄悄塞入 BOM 或 GBK 残留字节，导致 Sublime 解析失败。别信右下角显示的 “UTF-8” —— 它可能是假的。
验证并修复步骤：
- 右下角点击编码名 → 选
Reopen with Encoding → UTF-8，观察是否仍有 - 若仍有 ，打开 Find 面板（
Ctrl+F），勾选Regular Expression，搜\ufffd（即 的 Unicode 码点），定位损坏位置 - 用正则
[^\x00-\x7F\u4e00-\u9fff\u3000-\u303f\uff00-\uffef\U0001F600-\U0001F64F]扫描非标准字符（注意：\U表示 4 字节 Unicode，Sublime 支持） - 确认无误后，
File → Save with Encoding → UTF-8（不是 “UTF-8 with BOM”）
插件不是万能的，ConvertToUTF8 对 emoji 无效
ConvertToUTF8 插件解决的是 GBK/BIG5 → UTF-8 的**编码转换问题**，但它不处理字体渲染、不扩展 Unicode 范围、也不修复已损坏的多字节序列。如果你的文件本来就是 UTF-8，只是显示为方块，装这个插件毫无作用。
真正需要关注的是：
- 操作系统是否已安装含 emoji 的字体（尤其 Win7 / Linux）
-
font_face设置是否用了逗号分隔的 fallback 链（不是单字体） - 文件是否真为无 BOM 的 UTF-8（可用
file -i filename或 VS Code 查看） - 是否在构建/运行环节二次转码（例如 Python subprocess 默认用 locale 编码读 stdin，会破坏 emoji）
最常被忽略的一点：改完 font_face 后必须重启 Sublime Text——它不会热重载字体配置。
