前段时间搞那个串口程序，顺便将doxygen学习了一下，看资料，doxygen支持utf8(生成的配置文件默认的编码就是utf8)，但我很久没在程序中使用中文作注释了，原因是我都是在文本模式下编写程序的，用中文会造成不必要的麻烦。而且，这些计算机英文不难，当学习英文了。

经调查，gcc从4.4.0版本就开始支持utf了。但是我系统中使用的gcc都低于这个版本，fc9中是4.3.0，fc10是4.3.2，为了使用doxygen生成中文文档，我特意去下载了一个比较高版本的gcc，重新编译，果然可以！

当源代码文件使用utf编码保存时，编译会出错，出错提示信息如下：

main.c:1: 错误：程序中有游离的‘357’

main.c:1: 错误：程序中有游离的‘273’

main.c:1: 错误：程序中有游离的‘277’

main.c:1: error: stray '357' in program

main.c:1: error: stray '273' in program

main.c:1: error: stray '277' in program

注意，main.c中没有多任何不应该的字符，只是将源代码文件保存为utf格式而已。没什么，只是utf多了3个字符而已。下面作一小小实验，就是建立一个只有“123”三个字符的文件，分别保存为不同的格式，看一下其中的内容。注意，保存“123”的文件名称为“utf”，使用notepad++这个工具来保存，当然，也可以使用其它如UE等等编辑器来保存，方法很多。另外，本文测试环境为物理机Windows，虚拟机为Linux，分别使用两个系统中不同的工具(notepad++在Windows使用，hexdump在Linux中使用)。

hexdump的用法就不介绍了，直接man一下就行了。我们直接dump一下它：

$ hexdump utf

0000000 bbef 31bf 3332

0000006

这个结果很让人惊奇，先不管那些bbef什么的，我们保存了“123”，也就是十六进制的“31 32 33”，但这里显示的却是“31bf 3332”，我只能用小端模式来解释了(2在3的后面就是证据了)。

我们再使用hexdump的其它选项看一下：

$ hexdump -c utf

0000000 357 273 277   1   2   3

0000006

$ hexdump -C utf

00000000  ef bb bf 31 32 33                                 |...123|

00000006

上面显示的结果包含有“357 273 277”，熟悉不？没错，它们就出现在前面那个出错的提示信息中。这两个显示的结果跟我们概念中的是一样的，“123”依次显示出来。对此，我只能说是hexdump这个工具搞的鬼(大家可以用winHex工具查看一下)。“ef bb bf”是utf8格式开头的三个字符。具体怎么样，在此不介绍。

下面是无BOM的utf格式(实践证明，使用无BOM的utf8保存源代码文件，是可以通过gcc的编译的，即gcc 4.3.x版本)：

$ hexdump -c utf-nobom

0000000   1   2   3

0000003

$ hexdump -C utf

00000000  31 32 33                                          |123|

00000003

可以看到，它没有前面开头的几个字符。BOM是Byte Order Mark的意思。

下面是一些unicode的测试，第二个是big endian模式的unicode，据说网络中传输就是采用big endian的，所以在Linux下编写网络程序时需要注意这个问题。

utf-unicode

$ hexdump -C utf-unicode

00000000  ff fe 31 00 32 00 33 00                           |..1.2.3.|

00000008

utf-unicode big endian

$ hexdump -C utf-unicode-be

00000000  fe ff 00 31 00 32 00 33                           |...1.2.3|

00000008

另外，既然使用了hexdump，也不妨对比一下Windows系统与Linux系统之间所谓的“回车换行”：

Unix(Linux)

$ hexdump -C ansi

00000000  31 32 33 0a                                       |123.|

00000004

Dos

hexdump -C ansi

00000000  31 32 33 0d 0a                                    |123..|

00000005

可以看，Windows比Linux多了一个0d，如果我们使用记事本打开Linux下编写的程序的源代码文件，会发现这些格式很乱，我以为是这个原因造成的，如果使用像notepad++或UE这类的编辑器查看的话，没有这样的问题。

更多的信息，请google之(个人认为对于这类的问题，最好不要使用baidu，大家可以使用两个搜索引擎对比一下结果)，或者参考下面给出的超链接。

伐木丁丁鸟鸣嘤嘤的主页：

伐木丁丁鸟鸣嘤嘤CSDN博客关于编码的文章：