Qt Creator编码设置本身不报错,但保存、添加文件或MSVC编译时易出错,根源是UTF-8(无BOM)与GBK/GB2312混用;改默认编码仅影响新建文件,已有文件需手动转码并添加BOM或统一为GBK,.pro文件尤其敏感。

Qt Creator 编码设置本身不会直接报错,但错误往往出现在“保存文件”“添加文件到项目”或“MSVC 编译”环节——根源几乎全是编码不匹配,尤其是 UTF-8(无 BOM)和 GBK/GB2312 混用。
为什么改了编码设置还是报 C2001 或 Failed to add to Project?
因为 Qt Creator 的“默认编码”设置只影响新创建的文件,对已存在的 .pro、.cpp、.h 文件无效。这些文件仍保留原始编码,而 MSVC 编译器读取时会按本地代码页(如 GBK)解析 UTF-8 字节流,把中文的多字节序列误判为非法字符或换行符,触发 C2001;Qt Creator 在写入 .pro 时也会因编码不一致拒绝修改,弹出 Failed to add to Project。
- 仅改全局设置
Default encoding≠ 所有文件自动转码 -
.pro文件特别敏感:哪怕只有一行中文注释,且文件是 UTF-8 无 BOM,就可能让添加操作失败 - Qt Creator 右上角显示的编码,是它“当前加载所用的编码”,不是文件磁盘实际编码——两者可能不一致
怎么确认并统一现有文件的真实编码?
别猜,用工具看。Notepad++ 是最可靠的验证手段:
Qt Creator 18.0.2 Windows x86_64 历史版本安装包,适合需要旧版本 IDE、旧项目兼容、Qt/C++ 项目维护、构建套件配置和调试环境回退的用户使用。
- 用 Notepad++ 打开
.pro、.cpp、.h文件,右下角明确显示当前编码(如UTF-8、ANSI、GBK) - 若显示
ANSI,在简体中文 Windows 下基本等于GBK(代码页 936) - 若显示
UTF-8 without BOM,而你用的是 MSVC,这就是高危状态 - 不要依赖 Qt Creator 自带的“重新加载为…”菜单——它有时会错误识别,尤其对无 BOM UTF-8
MSVC 下最稳的编码组合是什么?
不是纯 UTF-8,也不是纯 GBK,而是 UTF-8 with BOM —— 它能同时满足 Qt Creator 和 MSVC:
- Qt Creator 识别 BOM 后,会严格按 UTF-8 解析,中文注释、字符串正常显示
- MSVC 看到 BOM(
EF BB BF)就知道这是 UTF-8,不再按 GBK 解析,C2001消失 - 设置路径:
工具 → 选项 → 文本编辑器 → 行为 → 文件编码 → Default encoding设为UTF-8,勾选Add BOM on save - 对已有文件:在 Qt Creator 中打开 → 右上角编码显示点击 → 选
UTF-8→ 点Save with Encoding(必须手动保存才生效) - 注意:
Add BOM on save必须开启,否则新建文件仍是无 BOM,问题复发
为什么有时候改成 GBK 反而更简单?
当你项目完全在 Windows + MSVC 环境下运行,且不涉及跨平台协作或 Git 历史混乱时,GBK 是兼容性最强的兜底方案:
- MSVC 默认按 GBK 解析源码,零配置即可编译中文字符串
- Qt Creator 设置
Default encoding为GBK后,新建文件、保存、添加到项目全部顺畅 - 风险点:Git 提交时可能被标记为二进制(GBK 不是标准文本编码),且 Linux/macOS 开发者打开会乱码
- 操作:全局设为
GBK,再批量用 Notepad++ 打开所有源文件 → 编码 → 转为GBK→ 保存 - 关键检查点:
.pro文件必须也转成 GBK,否则添加文件仍失败
真正麻烦的从来不是改一个设置,而是让所有文件、所有环节、所有参与方用同一套编码规则。BOM 是 UTF-8 在 Windows MSVC 上唯一可靠的“身份证明”,没它,编译器就当你是乱码。动手前先用 Notepad++ 看清每个文件的真实编码,比盲目调设置有效十倍。

















