【转】关于C++程序的编码问题

引用自：http://blog.chinaunix.net/uid-26790551-id-3190813.html

我们传统的程序基本都只在Windows或只在Linux下运行，Windows程序使用简体
中文GB18030编码，Linux程序则只使用英文，多年以来这些程序运行起来都没有
问题。

近年来，随着程序的组件化，部分代码特别是公用组件都需要同时支持Windows
及Linux平台，这样就出现了不同程度的编码问题，例如在编译时编译器报错，
或者在运行时出现乱码。这些问题都和程序选用的字符编码不正确有关。

本文简要地分析了C++的一些字符编码问题，并提供了建议的方案。受经验和时
间的限制，有些内容可能不一定全面，仅供大家参考。

1. C++源文件的编码需要特别考虑吗？

1.1. 几个相关概念

首先要区分几个概念：

C++源文件的编码

指的是C++源程序文件（.cpp/.h）本身使用什么字符编码（GB18030/UTF-8等）。

C++程序的内码

编译后，C++中的字符串常量都会变成一串字节存放在可执行文件中。这个内
码指的就是在可执行文件中，字符串以什么编码进行存放。这里的字符串常量
指的是窄字符（char）而非宽字符（wchar_t）。宽字符通常是以Unicode（VC
使用UTF-16BE，gcc使用UTF-32BE）存放。

运行环境编码

指的是执行程序时，操作系统或终端所使用的编码。程序中输出的字符最终要
转换为运行环境编码才能正确显示，否则就会出现乱码。

1.2. 各种环境下通常使用的编码

C++源文件的编码

通常在简体中文Windows环境下，各种编辑器（包括Visual Studio）新建文件的
缺省编码都是GB18030，所以不特别指定的话，Windows环境下C++源文件的编码
通常为GB18030。

而在Linux环境下，最常使用，也是推荐使用的是UTF-8编码。

C++程序的内码

一般来说，我们常用的简体中文版VC所使用的内码是GB18030，而gcc/g++使用的
内码缺省是utf-8，但可以通过-fexec-charset参数进行修改。


Note 		可以通过在程序中打印字符串每个字节十六进制形式来判断程序所使用的内码。

运行环境编码

我们常用的简体中文版Windows的环境编码是GB18030，而Linux下最常用的环境
编码是UTF-8。

1.3. 这几个编码之间的关系

源程序需要由编译器编译为目标文件，目标文件运行后输出信息到终端，因此这
几个编码之间存在一些的关联：

+--------+
| 源程序 |----------源文件编码 +---+----+ | 编译器编译 +---+----+
|目标文件|----------程序内码 +---+----+ | 运行后输出信息 +---+----+ | 输出
|----------运行环境编码 +--------+

  • 编译器需要正确识别源文件的编码，把源文件编译为目标文件，并把源文件中
    的以源文件编码的字符串转换为以程序内码编制的字符串保存在目标文件中。


    Note     		当源文件的字符编码与程序内码都是UTF-8时（gcc的缺省情况），gcc似乎并不会对源文件中的字符编码进行转换，而是直接把字符串原样存放到目标文
    件中，在这种情况下，源程序中的GB18030编码的字符串在输出时仍然为GB18030
    编码。但如果在其它源文件字符编码的实际值与编译选项不同时，会在编译时报无法从XXX转换到UTF-8的错，因此还不清楚为什么两个编码都是UTF-8时，GB18030 编码的源文件能通过编译。
  • C++标准库需要正确识别终端的运行环境编码，并把程序的输出转换为运行环
    境所使用的编码，以便正确显示。

在这过程中，如果有一个环节出现问题，就会导致程序的输出发生异常，产生乱
码或其它更严重的后果。

2. 源文件应该采用什么编码？

2.1. 编译器对不同源文件编码的支持一样吗？

根据 http://stackoverflow.com/questions/688760/how-to-create-a-utf-8-string-literal-in-visual-c-2008
一文中提供的资料，gcc/vc各版本对C++源文件编码有不同的处理：

支持UTF-8编码的源文件，UTF-8编码的源文件可以有BOM，也可以没有。

  • vc2005+:

如果源文件使用UTF-8编码的话，必须有BOM。


Note 		gcc提供了-finput-charset参数可以指定源文件的字符编码，但由于标准
头文件都是ascii编码的，因此如果要引用标准头文件的话，源代码的编码必须兼容ascii。而vc未能找到类似的选项。

2.2. 源文件应该采用什么编码？

很多文章都推荐C/C++代码中只使用ascii字符，如果有非ascii字符可以用\xHH
或\uXXXX表示。注释中建议使用utf-8编码。也可以使用gettext 把非ascii字符串放到单独的语言文件中，而在源代码中只保留ascii字符。

在实践中，由于\xHH或\uXXXX等方式很不直观，容易出错且不易发现，而未必所
有程序都需要支持多语言，因此未必想引入gettext或类似的解决方案。在这样
的情况下，大家都习惯在源程序文件中直接写入中文等非ascii字符，这就需要
选择一种至少能被gcc和vc接受的文件编码。

本来，Unicode是解决多语言问题的最好选择，而UTF-8由于与ASCII兼容，也是
最通用的Unicode编码方式，但从上面的资料中可见，如果用UTF-8的话，gcc（
至少是低版本）不允许有BOM，而vc2005 以上要求必须有BOM，因此同一个文件
无法在gcc及vc下通过编译，UTF-8似乎不是一个好的选择。但如果使用gcc比较
高的版本（4.4.0以上？），使用带BOM的UTF-8编码文件应该也是可行的。

考虑到目前现状，我们一般都在简体中文Windows下工作，源文件中使用GB18030
编码似乎是一个比较现实的选择。在vc下可以直接编译，而在gcc下也可以通过
增加编译选项-finput-charset=gb18030予以支持。而且根据维基百科中GB18030
的词条内容，GB18030 is a superset of ASCII and can represent the whole
range of Unicode code points（GB18030向后兼容ASCII，并且能表示所有的
Unicode码点），因此使用GB18030有足够的表达能力，可以表示所有的Unicode
字符。使用GB18030的唯一缺点就是在非简体中文版本的VC下，由于无法指定源
文件的编码，因此有可能无法正确识别此编码的源文件。

3. 应该使用什么程序内码？

正如前面提到的，C++有窄字符（char）和宽字符（wchar_t）的分别，分别有一
套相应的类和函数（string/cout/strlen与wstring/wcout/wcslen等）。前者在
不同的编译器下有不同的缺省编码（简体中文vc是GB18030，gcc是UTF-8），后
者一般都使用Unicode，其中vc下使用UTF-16，gcc缺省使用UTF-32。

C++在输出窄字符时会按程序内码原样输出，不会进行编码转换，因此在使用窄
字符时要求程序内码与运行环境编码一致，这样才不会出现乱码。由于简体中文
版vc的程序内码是GB18030，因此使用窄字符的vc程序只能运行在GB18030环境下
。同样，由于gcc缺省使用UTF-8作为程序内码，因此使用窄字符的gcc程序只能
运行在UTF-8的终端环境下。（这里说的都是在源代码中直接写中文等非ascii字
符的程序。用前面提到的gettext及其它工具，使用窄字符的程序也可以在不同
编码的运行环境中正确输出中文）

C++在输出宽字符时会自动转换为运行环境的编码，因此只要正确设置了运行环
境编码，同一个程序就可以在不同编码的运行环境中正确显示中文。这一点与
Java/.Net很象，Java/.Net的字符串类型都使用Unicode，在输入/输出时都需要
与当前运行环境的编码进行互转。

一般来说，如果需要支持多语言，有两种比较好的做法：

  1. 使用窄字符，但源程序中只使用ascii字符，非ascii字符通过gettext或其它
    工具放到单独的文件中，由gettext等工具处理编码转换的问题。

    • 在各种编码的运行环境中均能正确输出中文。
    • 程序中不能直接出现非ascii字符，也不能通过\uXXXX方式指定非ascii字符，后者也会被编译器转换为非ascii字符并存放在目标文件中。
    • 注释中可以使用ascii兼容的编码，不影响编译器。
    • 有比较多的现成代码可供重用。
  2. 使用宽字符。
    • 在各种编码的运行环境中均能正确输出中文。
    • 程序中可以使用非ascii字符。
    • 需要配合前面的源程序文件编码设置，让编译器能正确识别源程序中的非
      ascii字符。
    • 由于以前使用宽字符的程序比较少，可供重用的代码较少。

Note 		如果程序中需要一些固定字符编码的字符串常量，例如固定是GB18030
编码的字符串常量，这些常量应该以\xXX的方式存放字符串常量经GB18030编码后的内容，这样的内容才不会被转换为程序的内码，也不会转换为运行环境编码。

4. 运行环境应该用什么字符编码？

正如上面提到的，使用窄字符和使用宽字符的程序对运行环境的字符编码要求是
不一样的。

  • 使用宽字符，只要在程序中正确设置当前环境的字符编码（一般通过locale::global(locale("")) 进行设置），C++标准库会在输入、输出时正
    确进行字符编码转换，因此可以适应各种编码的运行环境。
  • 使用窄字符，但程序中不出现非ascii字符的话，对运行环境没有特别要求，
    可以适应各种编码的运行环境。
  • 使用窄字符，程序中也直接使用汉字等非ascii字符的话，由于C++标准库会把
    目标文件中保存的字符串（以程序内码保存）直接输出，不会进行字符编码转换，因此要求运行环境的编码与程序内码一致。即简体中文VC编译的程序只能运行在GB18030环境下，gcc编译的程序只能运行在UTF-8环境下（可以在编译时通过-fexec-charset参数进行修改）。

5. C++源文件编码的选择

5.1. 几种可行做法

根据上面的讨论，目前看来，要兼容Windows/Linux，VC/gcc的话，有几种做法
：

  1. 使用窄字符，源程序中只使用ascii字符，非ascii字符，如中文等通过
    gettext等工具放到单独的语言包中。

    • 这种做法比较多人推荐。
    • 兼容VC及gcc各版本。
    • 由于源程序中不出现非ascii字符，因此不需要考虑源程序文件的编码问题。
    • 兼容各种编码的运行环境。
  2. 使用窄字符，源程序中允许使用非ascii字符。
    • 要求运行环境的编码与程序内码一致，即只支持GB18030编码的Windows及
      UTF-8编码的Linux。
    • 根据源程序使用的编码不同，对编译器的兼容性也不同：
      1. 使用窄字符，源程序使用带BOM的UTF-8编码。

        • 兼容VC各语种的各版本。
        • 兼容gcc 4.4.0以上版本。
      2. 使用窄字符，源程序使用GB18030编码。
        • 兼容VC的简体中文各版本。
        • 兼容gcc各版本，但在编译时需要加上-finput-char=gb18030参数。
  3. 使用宽字符，源程序中允许使用非ascii字符。
    • 兼容各种编码的运行环境。
    • 根据源程序使用的编码不同，对编译器的兼容性也不同：
      1. 使用窄字符，源程序使用带BOM的UTF-8编码。

        • 兼容VC各语种的各版本。
        • 兼容gcc 4.4.0以上版本。
      2. 使用窄字符，源程序使用GB18030编码。
        • 兼容VC的简体中文各版本。
        • 兼容gcc各版本，但在编译时需要加上-finput-char=gb18030参数。

5.2. 推荐做法

根据我们的现状，对于需要支持多语种的程序，建议使用窄字符，源程序中只使
用ascii字符。

对于不需要支持多语种的程序，考虑到重用已有的代码，可以考虑使用窄字符，
采用GB18030编码，但只能运行在GB18030编码的Windows环境及UTF-8编码的
Linux环境下。

6. 其它问题

6.1. 用户输入、输出及持久化

由于用户输入、输出及从文件、网络等设施读写的数据在程序底层看来都是字节
流，因此存在在输入时如何把这些字节流解释成有效的信息，在输出时怎么把程
序中的信息转换为正确的字节流的问题。

  • 如果程序本身不需要处理这些数据，只是把数据从一个来源搬到另一个地方（
    如把用户输入保存到文件，或者从一个流读入，写到另一个流等），而输入的字符编码与输出的字符编码一致的话，程序不需要对数据进行任何编码转换，只需要把读入的数据按原样写到输出即可，数据的字符编码与程序的编码没有关系。

    比如网站应用程序，只需要保证用户页面使用UTF-8编码，数据库、数据文件也都使用UTF-8编码，那么用户输入的数据可以直接写入数据库及数据文件，从数据库或数据文件中读取的数据也可以直接展现给用户，不需要进行编码转换。

  • 如果程序需要在一定程序上对数据进行处理（如需要判断字符个数、对字符进
    行比较、在字符串上附加或去掉内容），就要把数据转换为一种明确的字符编码，一般来说是程序内码，再进行处理，在处理后再转换为所需的字符编码进行输出。
    • 对于宽字符程序，如果只需要处理采用当前运行环境字符编码的数据，可以通过ios::imbue()可以指定io流的字符编码，在输入、输出时C++标准库会自动在所指定的字符编码与程序内码之间进行编码转换。如果不使用流的话，也可以通过标准的wcstombs()或mbstowcs()函数进行当前编码（通过locale::global()或setlocale()指定）与宽字符之间的转换。
    • 对于窄字符程序，如果数据的字符编码与程序内码一致也不需要进行编码转换，直接处理即可。
    • 对于其它情形，需要引入iconv或类似的字符编码转换库，以便实现不同
      字符编码之间的转换。

6.2. gettext、iconv的替代品

由于gettext及iconv都属于GNU
Project，考虑到版权因素，并非所有程序，特别是商业程序，都适合使用这些库。在Boost
1.48.0中，Boost.Locale库首次正式发布，该库提供了gettext、iconv的功能，并在此基础上进行了增强，提供了大小写变换、字符顺序比较、时间的处理
、分词、数字的格式化输入/输出、消息格式化、多语种支持、字符编码转换等功能，值得进一步研究及使用。

时间： 2024-10-11 21:34:55

【转】关于C++程序的编码问题的相关文章

黑马程序员——“编码人生”之开山篇

------Java培训.Android培训.iOS培训..Net培训.期待与您交流! ------- 一.自我介绍 1.称呼:肖某 2.性别:男 3.年龄:23(1992年) 4.职业:项目实施工程师 5.为什么要选择编码? 首先,我不排斥编码,反而还有点喜欢:其次,程序员的生活相对于项目实施要稳定许多,项目实施需要经常出差,年龄大了肯定受不了,到时候想转行都难,既然要转为何不早点转呢?最后,程序员的工资相比项目实施要高很多,程序员的不可替代性比项目实施要高. 二.学习笔记 在未来的10天里,

[转]JavaScript程序编码规范

原文:http://javascript.crockford.com/code.html 作者:Douglas Crockford 译文:http://www.yeeyan.com/articles/view/cloudwater/4042 译者:cloudwater 更新:2009-12-13 01:08:29 这是一套适用于JavaScript程序的编码规范.它基于Sun的Java程序编码规范.但进行了大幅度的修改, 因为JavaScript不是Java. 软件的长期价值直接源于其编码质量.

java程序应为CRT登录时启动未设置编码，造成启动乱码

1.以下提供CRT连接程序设置编码脚本,后缀为".vbs" # $language = "VBScript"# $interface = "1.0" Sub Main crt.Screen.Synchronous = True crt.Screen.WaitForString "$ " crt.Screen.Send "export LANG=zh_CN.utf-8" & vbCr crt.Scre

使用 Unicode 编码

面向公共语言运行库的应用程序使用编码将字符表示形式从本机字符方案(Unicode)映射为其他方案.应用程序使用解码将字符从非本机方案(非 Unicode)映射为本机方案.System.Text 命名空间提供了使您能够对字符进行编码和解码的类.System.Text 编码支持包括以下编码: Unicode UTF-32 编码 Unicode UTF-32 编码将 Unicode 字符表示为 32 位整数序列.您可以使用 UTF32Encoding 类在字符和 UTF-32 编码之间相互转换. Un

python---字符编码

获取系统默认字符编码 在Python代码中,普通字符串的编码方式与程序源文件编码方式一致的,而很多IDE在默认情况下,将程序源文件按照系统默认字符编码来保存的. 下面给出用Python获取系统默认编码的例子: import sys print(sys.getdefaultencoding()) #显示结果 utf-8

字符集编码

http://blog.chinaunix.net/uid-20761674-id-3486843.html http://www.searchtb.com/2012/04/chinese_encode.html 编码问题的例子 在windows自带的notepad(记事本)程序中输入“联通”两个字,保存后再次打开,会发现“联通”不见了,代之以“???”的乱码.这是windows平台上典型的中文编码问题.即文件保存的时候是按照ANSI编码(其实就是GB2312,后面会详细介绍)保存,打开的时候程

作为高级程序员应具有的基本素质

那么作为高级程序员,以至于系统分析员,也就是对于一个程序项目的设计者而言,除了应该具备上述全部素质之外,还需要具备以下素质: 第一,需求分析能力 对于程序员而言,理解需求就可以完成合格的代码,但是对于研发项目的组织和管理者,他们不但要理解客户需求,更多时候还要自行制定一些需求,为什么这么说呢? 一般而言,进行研发任务,也许是客户提出需求,也许是市场和营销部门提出的需求,这时候对于研发部门,他们看到的不是一个完整的需求,通常而言,该需求仅仅是一些功能上的要求,或者更正规些,可能获得一个完整的用户视

网络编程中的编码问题汇总

应用程序中的编码问题让人头疼,一直是这样,今天下午就被数据库编码错误搞的头疼不已. 那么,就决心好好总结一下编码带来的问题,争取让自己对整个编码体系有一个清晰的认识. 从编码问题的产生说起 我们知道,计算机是美国人发明的,人家的英语体系总从来就只有26个英文字母和一些数字.特殊字符等,为了储存文字信息,于是使用了最早的ascii码进行字符编码.而后来由于计算机的普及,多国语言文字变得重要起来,于是多语言的特性成为了计算机的必备,各国进行各国的国家标准编码,中国的便是GB2312(1980年),而

VS2017新建windows控制台程序打印中文乱码问题

最近刚换上VS2017,由于手头又要做个MFC的程序,所以写控制台程序做功能测试,然后发现居然乱码了. 于是用VS2017新建windows控制台应用程序,在main函数种加一句printf("你好");后,运行结果依然乱码 用notapad++打开该文件后,点击菜单栏的编码一项,发现是UTF-8无BOM格式编码,然后改成以ANSI格式编码后 也就是说VS是用UTF-8来编码代码文件的,编译出的程序中字符串也是按照UTF-8编码的,而控制台却是按照ANSI编码来理解的. 打个比方,A用