你有没有遇到过这样的情况：代码明明写得没问题，可一编译就报错，提示“非法字符”或者“无法识别的符号”？删掉重敲一遍又好了。其实，这很可能不是你手误，而是文件的编码格式在捣鬼。
什么是编码格式
简单来说，编码格式决定了计算机怎么把我们写的文字转换成它能理解的二进制数据。常见的比如 UTF-8、GBK、ANSI 等。就像不同国家的人说不同的语言，如果编译器“听不懂”你的文件用的是哪种编码，自然就处理不了。
为什么编码会影响编译
举个例子，你在 Windows 上用记事本写了个 C++ 程序，保存时默认用了 ANSI 编码（在中文系统下通常是 GBK），而你的编译器（比如 g++）默认只认 UTF-8。这时候，如果你的代码里有中文注释，比如：
// 这是一个测试程序
#include <iostream>
using namespace std;
int main() {
cout << "Hello World" << endl;
return 0;
}看起来没问题，但编译时可能就会报错，因为“这是”这两个字在 GBK 和 UTF-8 中的二进制表示完全不同。编译器用 UTF-8 解码 GBK 内容，结果就是一堆乱码，自然识别不出这是注释。
不只是中文注释
有些项目用到了字符串资源，比如：
string msg = "欢迎使用本系统";如果源文件编码和程序运行时预期的编码不一致，显示出来的可能是“锟斤拷”或者干脆是空白。这种情况在跨平台开发时特别常见，比如 Windows 开发完拿到 Linux 上编译，问题立马就出来了。
怎么避免这类问题
最简单的办法：统一用 UTF-8 编码保存源文件。现在的主流编辑器——比如 VS Code、Sublime Text、Notepad++ 都支持在保存时选择编码。打开文件另存为，选“UTF-8”就对了。
很多编译器也支持指定源文件编码。比如 g++ 可以加 -finput-charset=UTF-8 参数来告诉它源码是什么编码。不过依赖参数总归不如统一规范来得省心。
IDE 也不是万能的
别以为用了 Visual Studio 或者 CLion 就高枕无忧。虽然它们通常会自动检测编码，但偶尔也会判断错误。特别是从别人手里接过老项目时，原始文件可能是十年前用老旧工具生成的，编码五花八门。这时候打开一看，注释全是乱码，函数名倒是还好，因为都是英文字符。
建议新项目一开始就约定好编码规则，写在 README 里，避免后来人踩坑。一个小细节，往往能省下大把调试时间。