Necromanov1. 问题背景与现象分析
作为一名长期使用Visual Studio进行C/C++开发的程序员，我最近在项目中遇到了一个令人头疼的编码问题。当我在代码中使用中文字符串（如printf("中文提示信息");）时，编译运行后控制台显示正常。但当我尝试读取UTF-8编码的文本文件时，却出现了各种乱码现象。
具体来说，当读取"滚滚长江东逝水"这样的UTF-8编码文本时，控制台可能显示两种不同类型的乱码：
第一种是"古文式"乱码，如：
code复制锘?/ 婊氭粴闀挎睙涓滈€濇按锛屾氮鑺辨窐灏借嫳闆勩€
第二种是在执行chcp 65001命令后出现的"口字式"乱码：
code复制������
这个问题的根源在于Windows系统、Visual Studio编译器和控制台三者之间的编码不匹配。Windows默认使用GBK编码（代码页936），而现代开发中我们更倾向于使用UTF-8编码（代码页65001）。这种编码不一致导致了上述乱码现象。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 编码系统深度解析
2.1 GBK与UTF-8编码的本质区别
GBK编码是中文Windows系统的默认编码，它采用双字节表示中文字符，单字节表示ASCII字符。这种编码方式主要针对简体中文环境设计，兼容性有限。
UTF-8则是Unicode的一种实现方式，具有以下特点：
- 可变长度编码（1-4字节）
- 完全兼容ASCII
- 支持全球所有语言的字符
- 已成为互联网和跨平台开发的事实标准
在Visual Studio中，虽然源代码默认保存为UTF-8（无BOM），但编译器默认仍按系统编码（GBK）解析源码中的字符串字面量，这就埋下了乱码的隐患。
2.2 Visual Studio编译流程中的编码转换
理解VS的完整编译流程对解决编码问题至关重要：
- 源代码保存：VS默认以UTF-8无BOM格式保存源文件
- 编译器解析：在没有明确参数时，cl.exe默认按系统本地编码（GBK）解析源文件
- 字符串处理：源码中的中文字符串被错误地按GBK解析为字节序列
- 运行时输出：控制台默认使用GBK编码显示，但程序可能输出UTF-8编码的文本
这种编码不一致的"链条"导致了各种乱码现象。要彻底解决问题，必须确保整个流程中编码的一致性。