当前位置: 首页 > GNU/Linux程序 > 正文

utf的一点笔记

前段时间搞那个串口程序,顺便将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,大家可以使用两个搜索引擎对比一下结果),或者参考下面给出的超链接。

伐木丁丁鸟鸣嘤嘤的主页:http://www.fmddlmyy.cn/

伐木丁丁鸟鸣嘤嘤CSDN博客关于编码的文章:http://blog.csdn.net/fmddlmyy/category/279030.aspx

本文固定链接: http://www.latelee.org/programming-under-linux/utf-notes.html

如无特别说明,迟思堂工作室文章均为原创,转载请注明: utf的一点笔记 | 迟思堂工作室

目前暂无评论

发表评论

*

快捷键:Ctrl+Enter