Sublime Text汇编中文乱码需三步解决：先Reopen with Encoding选Chinese (GBK)正确解码源文件，再在.sublime-build中为NASM等添加-finput-charset=UTF-8及"encoding": "utf-8"，最后在代码中调用SetConsoleOutputCP(CP_UTF8)确保控制台输出UTF-8。
Sublime Text 编译汇编代码时中文乱码，根本不是文件编码设成 UTF-8 就能解决的——它卡在三个环节：源文件读取、编译器输入解析、控制台输出解码。跳过任一环，都会出现“锟斤拷”或方块字。
Reopen with Encoding 必须先做，否则后续全错
右下角显示的 UTF-8 只是 Sublime 当前怎么读这个文件，不是文件真实编码。你看到乱码，恰恰说明它正用 UTF-8 错解一个 GBK 字节流。
- 打开乱码的 .asm 文件后，立刻点击右下角编码名 →
Reopen with Encoding→ 选Chinese (GBK) - 如果还是乱码，再试
Chinese (GB2312)或Western (Windows 1252)；只要中文一出来，右下角变成Chinese (GBK)，就说明原始编码识别对了 - 千万别点
Convert to UTF-8（老版本菜单里有）——它会静默重写文件且不提示，原始编码信息直接丢失 - 确认显示正常后，内存里已经是正确解码的 Unicode 内容，磁盘文件一字未动
汇编构建系统必须显式指定 -finput-charset=UTF-8
很多用户以为改完文件编码就完了，但 NASM/YASM/MASM 并不默认按 UTF-8 解析源码。尤其 Windows 下，默认按 CP936（GBK）读取，遇到中文字符串字面量就会崩。
- 如果你用的是 NASM，
.sublime-build中的cmd必须包含-finput-charset=UTF-8参数 - 示例（NASM + Windows）：
{ "cmd": ["nasm.exe", "-f", "win64", "-finput-charset=UTF-8", "$file", "-o", "${file_path}/${file_base_name}.obj"], "file_regex": "^(.*?):([0-9]+):([0-9]+):\s+(.*)$", "working_dir": "${file_path}", "encoding": "utf-8", "selector": "source.asm" } -
"encoding": "utf-8"是唯一生效的字段，写成"UTF-8"或"utf8"都无效 - 路径必须用绝对路径（如
"C:/nasm/nasm.exe"），避免环境变量污染导致编码行为不一致
控制台输出中文需绕过 Windows 默认代码页
即使源码正确编译，printf 或 WriteConsoleA 输出中文仍可能变问号——因为 Windows 控制台默认用 CP936，而你的可执行文件输出的是 UTF-8 字节流。
- 不要在构建命令里加
chcp 65001：它只改当前 cmd 窗口，对 Sublime 启动的子进程完全无效 - 更可靠的做法：在汇编代码中调用
SetConsoleOutputCP(CP_UTF8)（Windows API），确保输出通道明确设为 UTF-8 - 若用 C 运行时包装汇编逻辑（比如
main在 C 里），在main()开头加：#ifdef _WIN32 SetConsoleOutputCP(CP_UTF8); #endif
- 验证是否生效：编译后在 CMD 中手动运行 exe，看是否正常；若 CMD 正常而 Sublime 构建面板仍乱码，说明
"encoding": "utf-8"没配对或路径错误
最容易被忽略的一点：Sublime Text 4 已彻底移除 fallback_encoding，你配了也白配；真正管保存行为的是 default_encoding_on_save。如果还要长期混用 GBK 旧项目，建议用 Notepad++ 先批量转存为 UTF-8 无 BOM，再导入 Sublime ——比反复切换编码更省事。
