[C/C++] 各种C/C++编译器对UTF-8源码文件的兼容性测试（VC、GCC、BCB）

在不同平台上开发C/C++程序时，为了避免源码文件乱码，得采用UTF-8编码来存储源码文件。但是很多编译器对UTF-8源码文件兼容性不佳，于是我做了一些测试，分析了最佳保存方案。

一、测试程序

　　为了测试编译器对UTF-8源码文件兼容性，我编写了这样的一个测试程序——

//#if _MSC_VER >= 1600    // VC2010
//#pragma execution_character_set("utf-8")
//#endif

#include <stdio.h>
#include <locale.h>
#include <string.h>
#include <wchar.h>

char* psa = "\u4e00字A";
wchar_t* pdw = L"\u4e00字W";

int main(int argc, char* argv[])
{
    char* pa;
    wchar_t* pw;

    setlocale(LC_ALL, "");    // 使用系统当前代码页.

    // char
    printf("len<%d>=%d,str=%s\t//", sizeof(char), strlen(psa), psa);
    for(pa=psa; *pa!=0; ++pa)    printf(" %.2X", (unsigned char)*pa);
    printf("\n");

    // wchar_t
    printf("len<%d>=%d,str=%ls\t//", sizeof(wchar_t), wcslen(pdw), pdw);
    for(pw=pdw; *pw!=0; ++pw)    printf(" %.4X", (unsigned int)*pw);
    printf("\n");

    return 0;
}

　　如果系统默认编码是GB2312（如中文Windows系统），该程序的输出结果应是——
len<1>=5,str=一字A // D2 BB D7 D6 41
len<2>=3,str=一字W // 4E00 5B57 0057

　　如果系统默认编码是UTF-8（如Linux系统），该程序的输出结果应是——
len<1>=7,str=一字A // E4 B8 80 E5 AD 97 41
len<4>=3,str=一字W // 4E00 5B57 0057

　　注：
1. “len”旁尖括号内的是字符类型的宽度。char类型一般是1字节。而wchar_t类型跟编译器与操作系统有关，Windows平台下一般2字节，Linux平台下一般4字节。
2. “len<?>=”右侧的数字是字符个数。用char类型，一个汉字的GB2312编码是2个字符，一个汉字的UTF-8编码一般是3个字符。而对于wchar_t类型，一个汉字一般是1个字符。
3. “str=”右侧的是所显示的字符串。
4. “//”右侧用于显示每一个字符的值。

二、测试结果

　　需要测试这些方面——
1. 分别测试不同操作系统下的多种编译器。
2. 无签名的UTF-8与带签名的UTF-8。UTF-8存储方案分别有两种，一是无签名的UTF-8，另一是带签名的UTF-8，这两种方案的区别是——是否存在签名字符（BOM）。
3. 执行字符集。VC2010增加了“#pragma execution_character_set("utf-8")”，指示char的执行字符集是UTF-8编码。

　　根据上面的要求，制定好了测试项目，分别有Window平台下的测试与Linux平台下的测试。
　　Window平台下的测试有——
[VC6, noBOM]：VC6.0 sp1，源码使用无签名的UTF-8编码。
[VC6, BOM]：VC6.0 sp1，源码使用带签名的UTF-8编码。
[VC2003, noBOM]：VC2003 sp1，源码使用无签名的UTF-8编码。
[VC2003, BOM]：VC2003 sp1，源码使用带签名的UTF-8编码。
[VC2005, noBOM]：VC2005 sp1，源码使用无签名的UTF-8编码。
[VC2005, BOM]：VC2005 sp1，源码使用带签名的UTF-8编码。
[VC2010, noBOM]：VC2010 sp1，源码使用无签名的UTF-8编码。
[VC2010, BOM]：VC2010 sp1，源码使用带签名的UTF-8编码。
[VC2010, noBOM, execution_character_set]：VC2010 sp1，源码使用无签名的UTF-8编码，并使用“#pragma execution_character_set("utf-8")”。
[VC2010, BOM, execution_character_set]：VC2010 sp1，源码使用带签名的UTF-8编码，并使用“#pragma execution_character_set("utf-8")”。
[BCB6, noBOM]：Borland C++ Builder 6.0，源码使用无签名的UTF-8编码。
[BCB6, BOM]：Borland C++ Builder 6.0，源码使用带签名的UTF-8编码。
[gcc(mingw), noBOM]：MinGW中的GCC 4.6.2，源码使用无签名的UTF-8编码。
[gcc(mingw), BOM]：MinGW中的GCC 4.6.2，源码使用带签名的UTF-8编码。

　　Linux平台下的测试有——
[gcc(fedora), noBOM, chs]：Fedora 17自带的GCC 4.7.0，源码使用无签名的UTF-8编码，系统语言设为“简体中文”。
[gcc(fedora), BOM, chs]：Fedora 17自带的GCC 4.7.0，源码使用带签名的UTF-8编码，系统语言设为“简体中文”。
[gcc(fedora), noBOM, eng]：Fedora 17自带的GCC 4.7.0，源码使用无签名的UTF-8编码，系统语言设为“英语”。
[gcc(fedora), BOM, eng]：Fedora 17自带的GCC 4.7.0，源码使用带签名的UTF-8编码，系统语言设为“英语”。

　　测试结果汇总如下（分号“;”后的是我写的注释）——

[VC6, noBOM]
len<1>=9,str=u4e00瀛桝    // 75 34 65 30 30 E5 AD 97 41    ; VC6无法识别“\u”转义符，直接输出了“u4e00”。
len<2>=7,str=u4e00瀛梂    // 0075 0034 0065 0030 0030 701B 6882

[VC6, BOM]
无法编译！    ; 因BOM字符被编译器当做了错误的语句。

[VC2003, noBOM]
len<1>=0,str=    //    ; 编译器无法识别字符串。
len<2>=3,str=一瀛梂    // 4E00 701B 6882

[VC2003, BOM]
len<1>=0,str=    //
len<2>=3,str=一字W    // 4E00 5B57 0057

[VC2005, noBOM]
len<1>=6,str=一瀛桝    // D2 BB E5 AD 97 41
len<2>=3,str=一瀛梂    // 4E00 701B 6882

[VC2005, BOM]
len<1>=5,str=一字A    // D2 BB D7 D6 41
len<2>=3,str=一字W    // 4E00 5B57 0057

[VC2010, noBOM]
len<1>=6,str=一瀛桝    // D2 BB E5 AD 97 41    ; “字A”的UTF-8编码为“E5 AD 97 41”，编译器将它们识别为GB2312编码的“瀛桝”，并将其存储为GB2312字符串。
len<2>=3,str=一瀛梂    // 4E00 701B 6882    ; “字W”的UTF-8编码为“E5 AD 97 57”，编译器将它们识别为GB2312编码的“瀛梂”，并将其存储为UTF-16字符串。

[VC2010, BOM]
len<1>=5,str=一字A    // D2 BB D7 D6 41    ; 因带有BOM，编译器正确的识别了字符串，并将其存储为GB2312字符串。
len<2>=3,str=一字W    // 4E00 5B57 0057    ; 因带有BOM，编译器正确的识别了字符串，并将其存储为UTF-16字符串。

[VC2010, noBOM, execution_character_set]
len<1>=8,str=一鐎涙    // D2 BB E7 80 9B E6 A1 9D    ; “\u4e00”被识别为“一”，并存储为GB2312编码“D2 BB”。“字A”的UTF-8编码为“E5 AD 97 41”，编译器将它们识别为GB2312编码的“瀛桝”，并存储为UTF-8编码的“E7 80 9B E6 A1 9D”。但显示时系统默认是 GB2312 编码。
len<2>=3,str=一瀛梂    // 4E00 701B 6882

[VC2010, BOM, execution_character_set]
len<1>=6,str=一瀛桝    // D2 BB E5 AD 97 41    ; “\u4e00”被识别为“一”，并存储为GB2312编码“D2 BB”。“字A”的UTF-8编码为“E5 AD 97 41”，编译器正确的将其存储为UTF-8编码。但显示时系统默认是 GB2312 编码。
len<2>=3,str=一字W    // 4E00 5B57 0057

[BCB6, noBOM]
len<1>=6,str=一瀛桝    // D2 BB E5 AD 97 41
len<2>=3,str=一瀛梂    // 4E00 701B 6882

[BCB6, BOM]
无法编译！    ; 因BOM字符被编译器当做了错误的语句。

[gcc(mingw), noBOM]
len<1>=7,str=涓€瀛桝    // E4 B8 80 E5 AD 97 41    ; 存储为UTF-8编码。但显示时系统默认是 GB2312 编码。
len<2>=3,str=一字W    // 4E00 5B57 0057

[gcc(mingw), BOM]
len<1>=7,str=涓€瀛桝    // E4 B8 80 E5 AD 97 41
len<2>=3,str=一字W    // 4E00 5B57 0057

[gcc(fedora), noBOM, chs]
len<1>=7,str=一字A    // E4 B8 80 E5 AD 97 41    ; 存储为UTF-8编码。显示时系统默认是 zh_CN.utf8 编码，正常输出。
len<4>=3,str=一字W    // 4E00 5B57 0057

[gcc(fedora), BOM, chs]
len<1>=7,str=一字A    // E4 B8 80 E5 AD 97 41
len<4>=3,str=一字W    // 4E00 5B57 0057

[gcc(fedora), noBOM, eng]
len<1>=7,str=一字A    // E4 B8 80 E5 AD 97 41    ; 存储为UTF-8编码。显示时系统默认是 en_US.utf8 编码，正常输出。
len<4>=3,str=一字W    // 4E00 5B57 0057

[gcc(fedora), BOM, eng]
len<1>=7,str=一字A    // E4 B8 80 E5 AD 97 41
len<4>=3,str=一字W    // 4E00 5B57 0057

三、结果分析

　　观察测试结果，我们首先可以发现以下几点——　　
VC6和BCB6都无法编译带签名UTF-8编码的代码文件，它们会将签名字符（BOM）当做错误的语句。
VC6无法识别“\u”转义符。
VC2003无法识别UTF-8编码的char。

3.1 原理分析

　　Windows下的测试以VC2010最为典型，以此为例来讲解。

　　在编译过程中，处理字符串时会涉及下面两种字符集——
源码字符集(the source character set)：源码文件是使用何种编码保存的。
执行字符集(the execution character set)：可执行程序内保存的是何种编码。

　　要想使程序不会乱码，必须满足——
1) 编译器准确识别了源码字符集，从而得到正确的字符串数据。
2) 运行环境的编码与执行字符集相同。运行环境的编码可通过setlocale函数来配置，“setlocale(LC_ALL, "")”表示使用系统默认编码。对于简体中文Windows来说一般是GB2312，如果执行字符集相同，那就能正常显示，否则会乱码。

　　VC2010是这样处理的——
源码字符集：如果有签名字符，就按它的编码来解析；否则使用本地Locale字符集。
执行字符集：对于char类型，如果有“#pragma execution_character_set”，就按它的编码来存储字符串；否则使用本地Locale字符集。对于wchar_t类型，总是使用UTF-16编码。

　　当源码使用带签名的UTF-8编码时，VC2010能正确的识别源码字符集是UTF-8。然后因没有“#pragma execution_character_set”，执行字符集是本地Locale字符集——
[VC2010, BOM]
len<1>=5,str=一字A // D2 BB D7 D6 41 ; 因带有BOM，编译器正确的识别了字符串，并将其存储为GB2312字符串。
len<2>=3,str=一字W // 4E00 5B57 0057 ; 因带有BOM，编译器正确的识别了字符串，并将其存储为UTF-16字符串。

　　当源码使用无签名的UTF-8编码时，VS2010因找不到签名字符，源码字符集被误认为是本地Locale字符集。然后因没有“#pragma execution_character_set”，执行字符集是本地Locale字符集——
[VC2010, noBOM]
len<1>=6,str=一瀛桝 // D2 BB E5 AD 97 41 ; “字A”的UTF-8编码为“E5 AD 97 41”，编译器将它们识别为GB2312编码的“瀛桝”，并将其存储为GB2312字符串。
len<2>=3,str=一瀛梂 // 4E00 701B 6882 ; “字W”的UTF-8编码为“E5 AD 97 57”，编译器将它们识别为GB2312编码的“瀛梂”，并将其存储为UTF-16字符串。

　　当使用“#pragma execution_character_set("utf-8")”配置了执行字符集为UTF-8后，情况变得更复杂了。我们先看看VC2010能正确识别源码字符集的带签名文件——
[VC2010, BOM, execution_character_set]
len<1>=6,str=一瀛桝 // D2 BB E5 AD 97 41 ; “\u4e00”被识别为“一”，并存储为GB2312编码“D2 BB”。“字A”的UTF-8编码为“E5 AD 97 41”，编译器正确的将其存储为UTF-8编码。但显示时系统默认是 GB2312 编码。
len<2>=3,str=一字W // 4E00 5B57 0057

　　再看看无签名时的情况。VS2010因找不到签名字符，源码字符集被误认为是本地Locale字符集，即误将UTF-8识别为GB2312。然后根据执行字符集，又转换编码为UTF-8进行存储。最后在运行时因默认编码是GB2312，再次误将UTF-8识别为GB2312——
[VC2010, noBOM, execution_character_set]
len<1>=8,str=一鐎涙 // D2 BB E7 80 9B E6 A1 9D ; “\u4e00”被识别为“一”，并存储为GB2312编码“D2 BB”。“字A”的UTF-8编码为“E5 AD 97 41”，编译器将它们识别为GB2312编码的“瀛桝”，并存储为UTF-8编码的“E7 80 9B E6 A1 9D”。但显示时系统默认是 GB2312 编码。
len<2>=3,str=一瀛梂 // 4E00 701B 6882

　　从上面这2个例子中，发现VC2010存在一个Bug——“#pragma execution_character_set”对“\u”转义字符无效，“\u”转义字符总是使用本地Locale字符集，而不是执行字符集。

3.2 GCC分析

　　GCC的源码字符集与执行字符集默认是UTF-8编码，这是因为现在的Linux系统大多使用UTF-8编码。就算调整了Linux系统语言后，只是区域发生了变化，字符编码依然是UTF-8。所以我们的程序在“简体中文”与“英语”下，均能正确的显示中文字符。

　　MinGW中的GCC也是这样的，源码字符集与执行字符集默认是UTF-8编码。但是简体中文的Windows的默认编码是GB2312，会将printf输出UTF-8字符串误认为是GB2312，造成乱码。

3.2 最佳方案

　　如果字符串常量中没有非ASCII字符，建议源码文件使用无签名的UTF-8编码，这样能支持早期的编译器。
　　如果字符串常量中含有非ASCII字符，建议源码文件使用带签名的UTF-8编码，这样能使大多数编译器正确的处理源码字符集。

　　补充——
1. 注意条件仅是“字符串常量中没有非ASCII字符”。如果是从外部文件或其他途径获得非ASCII字符串，只要选择了合适的字符串函数，无签名UTF-8编码的源码文件也是能行的。
2. VC2010新增的“#pragma execution_character_set”用于明确要求UTF-8字符串的场合。由于Windows没有UTF-8的locale，实用性较小，

参考文献——
《ISO/IEC 9899:1999 (C99)》。ISO/IEC，1999。www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
《C99标准》。yourtommy。http://blog.csdn.net/yourtommy/article/details/7495033
《QString乱谈(2) 》。dbzhang800。http://blog.csdn.net/dbzhang800/article/details/7540905

源码下载—— 
http://files.cnblogs.com/zyl910/testwchar.rar

时间： 2024-10-07 16:36:58

[C/C++] 各种C/C++编译器对UTF-8源码文件的兼容性测试（VC、GCC、BCB）的相关文章

VS2010编译器工具cl对c++11标准支持情况测试

本文探讨了VS2010编译工具cl对C++11标准的支持情况,提供了利用C++11新特性的两段代码来进行测试,并同g++ 4.9.3编译器的编译情况相对比.总的说来:VS2010的编译器工具cl部分支持了C++11标准,而g++ 4.9.3则全部支持C++11标准.虽然现在已出现了C++14等新的标准,但熟悉了C++11标准的支持情况有利于我们正确选用符合自己需要的编译工具. 1. 问题产生 一个月前由于编写算法的而使用C++语言,看了一些英文版的算法设计和分析书.一个偶然的机会发现了C++11

CMake使用教程

转: CMake使用教程 CMake是一个比make更高级的编译配置工具,它可以根据不同平台.不同的编译器,生成相应的Makefile或者vcproj项目.通过编写CMakeLists.txt,可以控制生成的Makefile,从而控制编译过程.CMake自动生成的Makefile不仅可以通过make命令构建项目生成目标文件,还支持安装(make install).测试安装的程序是否能正确执行(make test,或者ctest).生成当前平台的安装包(make package).生成源码包(ma

Linux的简单介绍和基础命令（上）

一.Linux简要介绍 Linux命令基础 Linux命令帮助 目录与文件基本操作 Linux家族 Redhat 红帽 三个认证 (开源但是不免费)--->社区(系统开发者)--->Centos(服务器端) Ubuntu 最好的客户端系统,开源纯免费(软件开发人群) Debian --->kali Linux(专用工具资源占用很少) 树莓派 suse Linux--->ISP(电信,移动,联通) 定制版 shell--Linux系统的一种特殊程序--"翻译官"

深入理解JVM读书笔记四： （早期）编译器优化

10.1概述 Java 语言的 "编译期" 其实是一段 "不确定" 的操作过程,因为它可能是指一个前端编译器(其实叫 "编译器的前端" 更准确一些)把 .java 文件转变成 .class 文件的过程:也可能是指虚拟机的后端运行期编译器(JIT 编译器,Just In Time Compiler)把字节码转变成机器码的过程:还可能是指使用静态提前编译器(AOT 编译器,Ahead Of Time Compiler)直接把 *.java 文件编译成

编译器的工作过程和原理

转帖: http://www.codeceo.com/article/compiler-process.html#0-youdao-1-33675-32553cecb956bf88a1550052113e506a 码要运行,必须先转成二进制的机器码.这是编译器的任务. 比如,下面这段源码(假定文件名叫做test.c). #include <stdio.h> int main(void) { fputs("Hello, world!\n", stdout); return 0

MYC编译器源码分析

前文.NET框架源码解读之MYC编译器讲了MyC编译器的架构,整个编译器是用C#语言写的,上图列出了MyC编译器编译一个C源文件的过程,编译主路径如下: 首先是入口Main函数用来解析命令行参数,读取源文件,并开始编译过程.Main函数在MyC.cs文件,而IO.cs文件主要保存读取源码文件的相关操作.下表是Main函数的源码(批注用注释的方式显示),IO.cs文件用单独的一个小节说明: public static void Main() { try { // 看源码注释,代码是99年写的,也就

Java StuNote 1

1. JAVA语言历史 无心插柳柳成荫,有心栽花花不开. JAVA由SUN Microsystem公司研发. 2. JAVA语言特点 a) 跨平台.一次编译.到处执行. b) 速度慢.但非常稳定, 没有内存泄漏 (memory leakage),不easy出现错误. c) 不适合对速度要求高的图形界面操作, 适合服务端应用. C/S (Client/Server) -> B/S (Browser/Server) 3. JAVA编程一般运行流程 a) 编制JAVA源码文件 (*.java) 该文件

Bootstrap

第一章:认识Bootstrap Bootstrap的特点:灵活.优雅.可扩展. Bootstrap的定义:简单灵活的用于搭建Web页面的HTML.CSS.JavaScript工具集. Bootstrap中的JS插件依赖于jQuery,因此jQuery要在Bootstrap之前引用. Bootstrap不支持IE8. 第二章:排版 一.全局样式: Bootstrap不再一味的清零,而是注重重置可能产生的样式,保留和坚持部分浏览器的基础样式. 二.标题: Bootstrap定义标题也使用<h1>到

Linux Kernel - Debug Guide (Linux内核调试指南 )

http://blog.csdn.net/blizmax6/article/details/6747601 linux内核调试指南 一些前言 作者前言 知识从哪里来 为什么撰写本文档 为什么需要汇编级调试 ***第一部分:基础知识*** 总纲:内核世界的陷阱 源码阅读的陷阱 代码调试的陷阱 原理理解的陷阱 建立调试环境 发行版的选择和安装 安装交叉编译工具 bin工具集的使用 qemu的使用 initrd.img的原理与制作 x86虚拟调试环境的建立 arm虚拟调试环境的建立 arm开发板调试环