zyl910

优化技巧、硬件体系、图像处理、图形学、游戏编程、国际化与文本信息处理。

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  180 随笔 :: 0 文章 :: 106 评论 :: 0 引用

公告

作者:zyl910

  在不同平台上开发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

posted on 2012-07-26 23:56 zyl910 阅读(...) 评论(...) 编辑 收藏