隐匿的 BOM

转载：http://blog.csdn.net/dk123/article/details/5261362

最近在学习 C++ 的模板元技术，Loki 库无疑是最好的参考资料之一，至于 Loki 的介绍在这里就不多敷述了，直接说我遇到的问题：
从下面地址可以获得最新的代码：
https://loki-lib.svn.sourceforge.net/svnroot/loki-lib/trunk
把代码检出到本地，执行 make 后提示错误：
../../include/loki/StrongPtr.h:1: error: stray ‘/357’ in program
../../include/loki/StrongPtr.h:1: error: stray ‘/273’ in program
../../include/loki/StrongPtr.h:1: error: stray ‘/277’ in program
根据错误提示，应该是文件里存在非 ASCII 码的字符，用 file 命令查看了一下 StrongPtr.h 的类型，发现是 Unicode text, UTF-8，而别的源文件则是 ASCII C++ program text，看来是 Loki 的某个维护者不小心把源文件存成 UTF-8 编码的文件并在里面引入了非 ASCII 字符（UTF-8 编码是一种兼容 ASCII 编码的变长编码方案）。上述的编译错误中的字符是以 8 进制表示的，将其转换成 16 进制后发现是”EF BB BF”，看着很眼熟——好像是 BOM(byte order mark) 控制字符，去维基百科里查一下 BOM 词条，发现 UTF-8 文件的 BOM 果真是”EF BB BF”。而大多数 Windows 文件编辑器（包括记事本）在将文件保存为 Unicode 编码时默认都会悄悄的在文件头加上 BOM 字符且不会将其显示出来（用 WinHex 之类的十六进制编辑器就打开则可以看到 BOM 字符），而 Linux 下却没这个默认的规矩，所以 Linux 下 g++ 不认 BOM 也是情理之中的。看来是 Loki 的维护者在 Windows 下修改代码后不小心将 StrongPtr.h 存成 UTF-8 编码文件，引入了肉眼看不到的 BOM 字符。后将 StrongPtr.h 另存为 ASCII 编码的文件后果然编译通过。
找到问题后去 Loki 的开发论坛上报告了这一问题，维护者之一的 syntheticpp 随后修正了问题并在回帖里打趣的说：
Good to know “no BOMbs on Linux” ;-)
一语双关的将 BOM 字符比作 BOMB（炸弹），呵呵，隐匿在文件里的 BOM 看不到摸不着，编译时报告的错误也很不直白，大家在使用 Windows 下的文本编辑器编写跨平台代码时要注意这个问题，建议使用 Notepad++ 这种可以显式指定是否要加 BOM 字符的编辑器，以免挨炸。