C/C++: “error: stray ‘357’ in program“问题及其解决方法

1. 问题由来

2. UTF-8 BOM (byte order mark)

3. 简单的实验

4. What is FEFF?

5. 解决方法

5.1 方法一

5.2 方法二

5.3 方法三：dos2unix

1. 问题由来

在Linux中用GCC C++ Compiler（g++）编译报告以下错误：

error: stray ‘357’ in program
error: stray ‘357’ in program
error: stray ‘274’ in program
error: stray ‘233’ in program

查了查有些博客中有诸如此类的说法：“出现此类错误的原因，在编辑器中使用的utf-8的格式保存源代码中出现了中文的标点符号”、“在程序中打入了全角字符，也就是不是英文输入法”。

这些可能是会导致以上错误的原因的一种，但是并不适用于我现在碰到的这种情况。

以下总结一下关于这个问题的调查结果以及出现这种问题的简单的解决办法。

2. UTF-8 BOM (byte order mark)
        357、273等等是属于所谓的”UTF-8 byte order mark“。

那UTF-8 BOM是什么东东呢？参考以下链接：

        What Does UTF-8 With BOM Mean? - DZone Java

        But in Notepad++, it appears to support UTF-8 wihtout BOM, but it won't recoginze it when first open. You can check this by going Menu > Encoding and see which one is selected. Notepad++ seems to only recognize UTF-8 wihtout BOM with ones it converted by it's own conversion utility. Perhaps it's a bug in notepad++.

        So what is BOM? The byte order mark is useless for UTF-8. They only used for UTF-16 so they know which byte order is first. But UTF-8 will allow you to save these BOM for conversion purpose... they are ineffective in encoding the doc itself. So a "normal" UTF-8, it won't have BOM, but Windows would like to use them anyway. The Windows NOTEPAD would automatically save BOM in UTF-8!

        So be-aware when viewing UTF-8 without BOM encoding files in Notepad++, as it can be deceiving at first glance.

简而言之，UTF-8并不需要BOM，BOM是在UTF-16中用于指示字节顺序的。在Linux编辑的文件会使用UTF-8 instead of UTF-8 BOM。但是，如果你不小心在Windows下用Notepad++打开了文件，它可能会自动地替你转成UTF-8 BOM，然后你把它保存了以后就把BOM字符带进文件了。

        要命的是，这些BOM字符是不可见的（至少在Windows Notepad++编辑器中）。

3. 简单的实验
        先在Linux下创建一个文件如下：

在Windows下用Notepad++打开，缺省地并没有如以上博客所说会设定成UTF-8 BOM：

可能还需要什么别的误（骚）操作才会把格式变为UTF-8 BOM。这里手动的切换为UTF-8 BOM，然后保存。在Notepad++编辑器中并没有看出有什么异样（如上所述，BOM字符是不可见的）。

        然后回到Linux下用Gvim打开文件：

        OMG！妖孽现形了，第一行行首多出了个“”!

回头看最初发现这个编译问题时报错的那个文件打开一看，果然也是有这个东西，如下所示：