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

时间  2019-12-14
标签 c++ 各类 编译器 utf 源码 文件 兼容性 测试 gcc bcb 栏目 C&C++ 繁體版
原文   原文链接

　　在不一样平台上开发C/C++程序时，为了不源码文件乱码，得采用UTF-8编码来存储源码文件。可是不少编译器对UTF-8源码文件兼容性不佳，因而我作了一些测试，分析了最佳保存方案。javascript

1、测试程序

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

复制代码 
//#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. “//”右侧用于显示每个字符的值。ui


2、测试结果

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

　　根据上面的要求，制定好了测试项目，分别有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编码，系统语言设为“英语”。spa

　　测试结果汇总以下（分号“;”后的是我写的注释）——操作系统

复制代码 
[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
复制代码


3、结果分析

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


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

 

做者： zyl910
版权声明：自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0.
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程