[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