解决Sublime Text在编译大型C++项目时的控制台输出乱码与截断问题-sublime-PHP中文网

根本原因不是文件编码设为utf-8就能解决，而是g++未加-finput-charset=utf-8和-fexec-charset=utf-8，且windows控制台默认不识别utf-8，需程序调用setconsoleoutputcp(cp_utf8)并确保源文件为utf-8无bom。

解决sublime text在编译大型c++项目时的控制台输出乱码与截断问题

为什么控制台输出中文会变方块或问号

根本不是文件编码设成 UTF-8 就能解决的问题。Sublime 的构建系统启动 g++ 或 clang++ 后，子进程 stdout 默认按 Windows 代码页（CP936/GBK）编码输出，而你的源码是 UTF-8，编译器又没被告知输入编码——结果就是字节流错位：UTF-8 的“你好”被当成 GBK 解码，显示为两个乱码字符；更糟的是，如果编译错误信息含中文（比如 MinGW 报的“未声明的标识符”），也会直接崩成方块。

g++ 必须加 -finput-charset=UTF-8 -fexec-charset=UTF-8，否则字符串字面量在内存里就是错的
即使编译成功，std::cout 仍会乱码——因为 Windows 控制台默认不识别 UTF-8，得靠程序自己调用 <code>SetConsoleOutputCP(CP_UTF8)
别信 chcp 65001 写进构建命令里：它只改当前 cmd 窗口，对 Sublime 启动的子进程无效

C++ 构建系统必须显式声明 encoding 和 cmd 模式

Sublime 的 .sublime-build 文件里，"shell_cmd" 写法完全忽略 "encoding" 字段，必须用 "cmd" 数组 + 绝对路径 + 显式参数。以下配置才是可靠生效的：

{
  "cmd": ["D:/mingw64/bin/g++.exe", "-finput-charset=UTF-8", "-fexec-charset=UTF-8", "-o", "${file_path}/${file_base_name}.exe", "$file"],
  "file_regex": "^(.*?):([0-9]+):([0-9]+):\s+(.*)$",
  "working_dir": "${file_path}",
  "encoding": "utf-8",
  "selector": "source.c++, source.cpp"
}

"encoding": "utf-8" 是唯一生效的解码声明字段，写成 "UTF-8" 或 "utf8" 都不行
必须用 "cmd" 而非 "shell_cmd"，否则 "encoding" 被无视
g++.exe 路径必须写绝对路径，避免环境变量污染导致编码行为不一致
file_regex 正则要匹配实际错误格式，MinGW 错误行通常是 main.cpp:12:5: error: ...，不能照搬 GCC Linux 版本的正则

大型项目输出截断的真实原因和绕过方法

不是 Sublime 控制台“太小”，而是 Windows 控制台缓冲区默认只有 9000 行、每行最多 32766 字符，且 Sublime 的内置输出面板不支持滚动加载——一旦编译日志超限（比如 CMake + 多个源文件 + 模板展开），后面的内容直接被丢弃，连报错都看不到。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

临时缓解：在构建命令末尾加 && pause，让窗口停留，手动滚动查看
真正可靠的做法：把输出重定向到文件，再用 Sublime 自带的 view.run_command("open_file", {"file": log_path}) 打开，例如："cmd": ["cmd", "/c", "g++ ... > build.log 2>&1 && notepad build.log"]
更工程化的方案：用 Ninja 或 Make 替代直接调用 g++，配合 cmake --build . --verbose 输出结构化日志，再用插件解析
注意：重定向后 file_regex 失效，错误跳转需改用日志解析插件（如 Terminal 或 Build Next）

运行时中文输出仍乱码？检查三处关键点

编译通过不代表运行时 OK。常见漏掉的环节比想象中多：

源文件保存时选“UTF-8 无 BOM”——有 BOM 的话，MSVC 可能多读一个 ufeff，GCC 则可能报 invalid byte sequence
程序开头必须调用 SetConsoleOutputCP(CP_UTF8)（#include <windows.h></windows.h>），仅靠 setlocale(LC_ALL, "") 不够
如果用了 std::wcout，必须配 std::wcout.imbue(std::locale("")) 且禁用同步：std::ios_base::sync_with_stdio(false)，否则输出静默失败
别在构建系统里加 "env": {"PYTHONIOENCODING": "utf-8"}——这玩意对 C++ 进程完全无效，纯属浪费字段