[C++基础] 字符编码

Posted 2022-12-01 WangBo_NLPR

前言

　　[C++基础] 系列是以我在工作中的系统研发笔记为基础加以整理推出的。该系列内容主要涉及C/C++中的基础知识，常用函数的使用说明和技巧，讨论函数在不同平台（windows和linux）、不同编译器版本环境下的差异，指出函数使用过程中的大坑，并给出笔者在研发中常用的代码示例。

　　本文内容主要整理自笔者的工作笔记中：关于C++字符集编解码部分的资料和心得。研究对比了C++开发中遇到的常见字符集编码，给出了字符集编码的基础知识，容易混淆的概念，开发中常用的技巧，并给出了代码示例。

　　文章小节安排如下：
　　1）locale与字符集
　　2）常见字符集
　　3）单字节字符集与多字节字符集
　　4）记事本程序（notepad）里的编码
　　5）关于Little endian和Big endian
　　6）如何利用程序检查文件的字符集编码
　　

一、locale与字符集

1.1 locale

　　locale，意思是“一套和地域有关的习惯而形成的程序运行上下文”，locale 就是某一个地域内的人们的语言习惯和文化传统和生活习惯，一个地区的locale就是根据这几大类的习惯定义的。在Linux下，这些locale定义文件放在/usr/share/i18n/locales目录下面，例如en_US, zh_CN and de_DE@euro都是locale的定义文件。
　　
　　由上述可以知道，locale 由很多方面组成，包括货币单位（LC_MONETARY）、数字形式（LC_NUMERIC）、时间显示格式（LC_TIME）等等，其中我们在本文中最关心的是字符类型（LC_CTYPE）。LC_CTYPE 规定了系统内有效的字符以及这些字符的分类，诸如什么是大写字母，小写字母，大小写转换，标点符号、可打印字符和其他的字符属性等方面。
　　

1.2 字符集

　　字符集就是字符（尤其是非英语字符）在系统内的编码方式，也就是通常所说的内码。通俗地说，字符集就是一个字符在网络传输，计算机内部通信的时候的编码方式，对于不同字符的不同表达方式。
　　
　　例如，UTF-8字符集是目前流行的字符编码方式，UTF-8用一个字节表示常用的拉丁字母，用两个字节表示常用的符号，包括常用的中文字符，用三个表示不常用的字符，用四个字节表示其他的古怪的字符。而GB2312字符集就是用两个字节表示所有的字符。
　　
　　

二、常见字符集

2.1 Native ANSI 字符集

2.1.1 ASCII
　　ANSI 发布的字符编码标准，编码空间 0x00-0x7F，占用1个字节。
　　
2.1.2 ISO-8859-1
　　ISO 发布的字符编码标准，又称 Latin-1 字符集，编码空间 0x00-0xFF，占用1个字节，可以编码大多数的西欧地区语言。
　　
2.1.3 GB2312，GBK，GB18030
　　GB 系列是由中国国标局发布的字符编码方案（其中 GBK 不是正式标准），后期发布的版本兼容之前的（是之前的超集）。
　　GB2312
　　为1-2字节变长编码，汉字区中编码 6763 个字符。
　　GBK
　　是微软对 GB2312 的扩展，后由国标局作为指导性标准，为1-2字节变长编码，编码 21886 个字符，分为汉字区和图形符号区。汉字区编码 21003 个字符，支持CJK汉字（简体、繁体、常用日韩文），Windows 代码页为 CP936。
　　GB18030
　　为1-2-4字节变长编码，汉字区编码 27484 个字符，支持CJK汉字、常用藏文、蒙文、维吾尔文等，Windows 代码页为 CP54936。
　　
　　

补充：关于ANSI的由来

　　开始计算机只在美国用，所以一个八位的字节（可以组合出256（2的8次方）种不同状态）就已经够用了。
　　其中，编号从0开始的32种状态分别规定了特殊的用途，一但终端、打印机等遇上这些约定好的字节，就要做一些约定的动作。例如，遇上0x0a, 终端就换行，遇上0x07, 终端就响铃等等。于是就把这些0x20以下的字节状态称为”控制码”。
　　编号从33到127，则是把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字了。大家看到这样，都感觉很好，于是把这个方案叫做 ANSI 的”Ascii”编码（American Standard Code for Information Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
　　
　　随着世界各地都开始使用计算机，很多国家用的不是英文，他们的字母里有许多是ASCII里没有的，为了可以在计算机保存他们的文字，他们决定采用127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128到255这一页的字符集被称”扩展字符集”。从此之后，人类再没有新的状态可以用了，也许那个时候美帝国主义还没有想到第三世界国家的人们也希望可以用到计算机吧！
　　

补充：关于GB2312/GBK/GB18030以及全角/半角字符的由来

　　等中国得以使用计算机时，已经没有可以利用的字节状态来表示汉字，而我们国家有6000多个常用汉字需要保存。于是中国把那些127号之后的奇异符号们直接取消掉，规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，这样就可以组合出大约7000多个简体汉字了。在这种编码方式里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的”全角”字符，而原来在127号以下的那些就叫”半角”字符了。
　　
　　这种汉字编码方案叫做 “GB2312”。可以看出，GB2312 是对 ASCII 的中文扩展。

　　随着计算机的普及，我们发现GB2312编码方案还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。
　　再后来，少数民族也开始普及使用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。
　　

补充：关于ANSI与GB系列编码的关系

　　从前面的讲述可以看出，GB2312，GBK，GB18030本质上都是从ANSI衍生出来的，这些编码方案都将ASCII作为自己的子集实现，所以这些字符集又叫做本地化的（Native）ANSI 字符集。在windows平台下建立文本文件，只能看到ANSI、Unicode、Unicode big endian、UTF-8这四种编码，就是这个道理。
　　每个地区、国家都有自己的 Native ANSI 字符集，它们在 ASCII 子集部分是相同的，其它部分都不尽相同。

2.2 Unicode 字符集

　　Unicode要比以前我们所以为的复杂的多，它是一种编码设计标准或者说思路。
2.2.1 UCS
　　Native ANSI字符集的问题在于，各个国家甚至各个地区都在搞出一套自己的编码标准，导致互相之间谁也不懂谁的编码，谁也不支持其他人的编码。此时，ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：设计一个可以包括地球上所有文化、所有字母和符号的编码方案！他们打算叫它”Universal Multiple-Octet Coded Character Set”，简称 UCS，俗称 “UNICODE”。
　　UNICODE 开始制订时，计算机的存储器容量极大地发展了，空间不再成为问题。于是 ISO 直接规定编码必须用两个字节，也就是16位来统一表示所有的字符，这也就是UCS-2。对于ascii里的那些“半角”字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于”半角”英文符号只需要用到低8位，所以其高8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
　　如前所述，UNICODE 是用两个字节来表示为一个字符，总共可以组合出65535不同的字符，这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系，ISO已经准备了UCS-4方案，说简单了就是四个字节来表示一个字符，这样就可以组合出21亿个不同的字符出来（最高位有其他用途），这大概可以用到银河联邦成立那一天吧！

　　UNICODE 的问题在于，它在制订时没有考虑与任何一种现有的编码方案保持兼容，这使得 GBK 与 UNICODE 在汉字的内码编排上完全是不一样的，没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，这种转换必须通过查表来进行。
　　

2.2.2 UTF - Unicode Transformation Format
　　与 UNICODE 一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，例如UTF8、UTF16等。顾名思义，UTF8就是每次8个位传输数据，而UTF16就是每次16个位，只不过为了传输时的可靠性，从UNICODE到UTF时并不是直接的对应，而是要过一些算法和规则来转换。
　　简单来说，UNICODE规定符号的二进制代码，但没有定义符号的存储和传输方案。UTF就是解决这个问题的，它是对 UCS 再次编码映射得到的字符集，某种程度可以看作是Unicode的具体实现方式。
　　
　　
2.2.3 UTF-8
　　UTF-8 使用 8 位单元（1字节）变长编码，并将 ASCII 作为子集，这样就可以将 UTF-8 当做一种 MBCS 的 Native ANSI 字符集的实现，因此 UTF-8 需要使用1字节流方式解析字符。
　　UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。
　　UTF-8 和所有的 Native ANSI 字符集一样，当数据块中只有 ASCII 子集部分的字符时，是无法区分这个数据块用哪种 Native ANSI 字符集进行编码的，因为这部分的编码映射关系对于所有的 Native ANSI 字符集是共享的，只有当未来数据块中包含像CJK汉字这种在 ASCII 子集之外的字符时，采用不同 Native ANSI 字符集的数据块才会表现出不同。
　　

2.2.4 BOM
　　如前所述，当数据块中只有 ASCII 子集部分的字符时，是无法区分这个数据块用哪种 Native ANSI 字符集进行编码的。那么如何标识使用的是编码是UTF-8呢？
　　方法就是在UTF-8 文件头部放置 BOM（byte order mark）。
　　先来说说BOM的本义：
　　BOM（byte order mark）本来是为 UTF-16 和 UTF-32 准备的，用于标记字节序（byte order）的标识，也就是用于标识一个 UCS 字符数据块是采用 Big Endian 还是 Little Endian 进行存储。在 Unicode 概念中有一个字符，它不映射到任何地区、国家中的可能字符，Unicode 标准对它的注释为：ZERO WIDTH NO-BREAK SPACE）。当开始处理 UCS 数据块时，UCS 标准建议先处理这个 ZERO WIDTH NO-BREAK SPACE 字符，比如 UCS-2 数据块，如果一开始读到/写入的字节序列是 FF FE（8 进制：377 376），那么说明后续的 UCS-2 按 Little Endian 存储；如果是 FE FF（8进制：376 377），则说明后续的 UCS-2 按 Big Endian 存储。
　　BOM的主要用途是网络传输时候标明字节的序列（先传高位还是低位），后续会有说明。然而微软将BOM作为区分UTF-8和ASCII的标识。

　　标识UTF-8的BOM字节序列是：EF BB BF，在文件中放置该BOM字节序列是微软的习惯，因为这样可以把 UTF-8 和 ASCII 等编码明确区分开，但此时，BOM 已经失去其在 UCS-2 中作为标识字节序大小端的作用，而仅把 EF BB BF 作为 UTF-8 编码的标识功能。当数据块的开始有这个字节序列时就说明后续字符采用 UTF-8 编码。
　　
　　但是BOM不受欢迎主要是在UNIX环境下，这方面资料可以参考：　　http://www.cnblogs.com/findumars/p/3620078.html
　　
　　

三、单字节字符集与多字节字符集

　　ASCII、ISO-8859-1 这种用1个字节编码的字符集，叫做单字节字符集（SBCS - Single-Byte Character Set）。
　　GB 系列这种用1-2、4个不等字节编码的字符集，叫做多字节字符集（MBCS - Multi-Byte Character Set）。
　　
　　由 SBCS 编码的数据可以随机访问，从任意字节偏移开始解编码都能保证解析出的字符和后继字符是正确的。
　　而由MBCS编码的数据，只能将其作为字节流进行解析，如果从随机任意的字节偏移开始解编码，有可能定位到切断一个字符的中间位置，导致后继解析出的字符连续出错。作为字节流时，是从某个标识位置进行解析字符，比如从数据的开始位置，或从每个新行符 ‘\\n’ 之后开始解析字符。
　　
　　

四、记事本程序（notepad）里的编码

　　在Windows平台下的记事本小程序Notepad.exe有四种编码方案：ANSI，Unicode，Unicode big endian 和 UTF-8。
　　1）ANSI是默认的编码方式。对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对Windows简体中文版，如果是繁体中文版会采用Big5码）。
　　2）Unicode编码指的是UCS-2编码方式，即直接用两个字节存入字符的Unicode码。这个选项用的little endian格式。
　　3）Unicode big endian编码与上一个选项相对应。
　　4）UTF-8编码，也就是上一节谈到的编码方法。
　　
　　

五、关于Little endian和Big endian

　　Unicode码可以采用UCS-2格式直接存储。以汉字”严“为例，Unicode码是4E25，需要用两个字节存储，一个字节是4E，另一个字节是25。存储的时候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。
　　这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中，小人国里爆发了内战，战争起因是人们争论，吃鸡蛋时究竟是从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开。为了这件事情，前后爆发了六次战争，一个皇帝送了命，另一个皇帝丢了王位。
　　因此，第一个字节在前，就是”大头方式“（Big endian），第二个字节在前就是”小头方式“（Little endian）。
　　那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？
　　Unicode规范中定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做”零宽度非换行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。这正好是两个字节，而且FF比FE大1。
　　如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。

　　Little endian和Big endian主要应用在数的的网络传输种。在网络里传递信息时有一个很重要的问题，就是对于数据高低位的解读方式，一些计算机是采用低位先发送的方法，例如我们PC机采用的 INTEL 架构，而另一些是采用高位先发送的方式，在网络中交换数据时，为了核对双方对于高低位的认识是否是一致的，采用了一种很简便的方法，就是在文本流的开始时向对方发送一个标志符——如果之后的文本是高位在位，那就发送”FEFF”，反之，则发送”FFFE”。
　　

六、如何利用程序检查文件的字符集编码

6.1 检查头两个字节

　　从前面的讲述可以知道，不同的编码方式，在文件的头几个字节还是差别的，具体如下：
　　

编码	BOM	说明
ANSI	无格式定义	对于英文文件是ASCII编码，对于简体中文文件是GB2312编码
Unicode	文件前两个字节为FF FE	little endian
Unicode big endian	文件前两个字节为FE FF	big endian
UTF-8 with BOM	前两字节为EF BB，第三字节为BF

　　存在的问题是：
　　1）如法进一步精确区分ANSI下的具体字符集，例如ASCII，GB2312等；
　　2）如果编码是UTF-8 no BOM，那用上述方法就无法判断文件是ANSI还是UTF-8 no BOM。
　　

6.2 利用linux的file命令

　　file命令可以查看文件的编码信息，例如：
　　test.txt: ISO-8859 text, with CRLF line terminators
　　test.txt: ASCII text, with CRLF line terminators
　　test.txt: UTF-8 Unicode (with BOM) text, with CRLF line terminators
　　可以利用popen函数执行shell命令并对结果进行分析，从而获得文件的字符集编码。
　　

6.3 Uchardet

　　uchardet是一个开源的用于文本编码检测的C语言库，其功能模块是用C++实现的，通过一定数量的字符样本独立的分析出文本的编码，当前已经支持UTF-8/GB13080/BIG5等共30多种编码。
　　这个我还没有试过，只是在查资料时候看到了，应该是挺好用的。
　　
　　

参考资料

各种编码UNICODE、UTF-8、ANSI、ASCII、GB2312、GBK详解
http://blog.csdn.net/lvxiangan/article/details/8151670
浅谈C/C++编程中的字符编码转换
http://blog.csdn.net/benkaoya/article/details/59522148
字符集编码与 C/C++ 源文件字符编译乱弹
http://jimmee.iteye.com/blog/2165685
UTF8最好不要带BOM，附许多经典评论
http://www.cnblogs.com/findumars/p/3620078.html
用C语言检测文本编码的方法
http://blog.csdn.net/turingo/article/details/8136644