[转]字符集、字符编码、乱码问题相关知识总结

　　计算机在存储和传输文件信息（图片，文档，音频，视频等）的过程中，都是使用二进制的比特流形式。

　　所以要保持文件信息，就需要把文件信息按一定的规则转成二进制的比特流进行存储。

　　要查看文件信息，计算机也需要把拿到的文件信息（二进制比特流）按一定的规则转成我们能识别的东西。

　　这里所说的规则，即指编码和解码方式。

　　当把原始文件转成二进制比特流的编码方式和把二进制比特流转成文件的解码方式不兼容的情况下，就会出现乱码。

 

　　下面介绍字符集，字符编码。

　　字符集：是多个字符的集合。字符是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。

　　字符集对应到生活中就是对某种语言的称呼，如英语、日语、汉语等。

　　字符集规定了某个字符对应的二进制数值存放方式（编码）和某串二进制数值代表了哪个字符（解码）的转换关系。

 

　　那么为什么有很多种不相同的字符集呢？

　　就像世界上有不同的语言，不同地区或组织在最初制定字符集的时候，并不会意识到这将会是以后全球普适的准则，或者对于自身利益的考虑，就产生了那么多具有相同效果但又不相互兼容的标准了。

　　

　　字符编码：是一套法则，使用该法则能够将字符集合中的每个字符与计算机能识别的一个二进制数值进行一一配对。

　　

　　对于一个字符集来说，要正确编码解码一个字符需要三个关键元素：字库表、字符集、字符编码。

　　字库表是一个相当于所有可读或者可显示字符的数据库，字库表决定了整个字符集能够展现表示的所有字符的范围。

　　字符集，即用一个编码值code point来表示一个字符在字库中的位置。

 

　　每个字符在字库表中都有唯一的序号，为什么不把该唯一序号作为存储内容，却还要把该字符通过字符编码转成另外一种格式呢？　　

　　这是因为统一字库表的目的是为了能够涵盖世界上所有的字符，但实际使用过程中会发现真正用的上的字符相对整个字库表来说比例非常低。如果把每个字符都用字库表中的序号来存储的话，每个字符就需要3个字节（这里以Unicode字库为例），这样对于原本用仅占一个字符的ASCII编码的英语地区国家显然是一个额外成本（存储体积是原来的三倍）。于是就出现了UTF-8这样的变长编码。在UTF-8编码中原本只需要一个字节的ASCII字符，仍然只占一个字节。而像中文及日语这样的复杂字符就需要2个到3个字节来存储。

 

　　我们平常接触到的字符集有下面几种：

　　1.ASCII 字符集

　　计算机刚出现的时候，主要在西方国家应用，当时的字符集，ASCII 字符集主要用于显示现代英语和其他西欧语言。

　　对应于ASCII编码，用一个字节表示一个字符。

 

　　2.GB2312字符集

　　中国国家标准总局发布了主要用于表示简体中文的字符集，GB2312字符集。

　　对应于GB2312编码，用两个字节表示一个字符。

 

　　3.GBK字符集

　　因为GB2312并不能处理一些罕用字等，又出现了GBK字符集。GBK是从GB2312扩展而来，兼容GB2312。

　　对应于GBK编码，用两个字节表示一个字符。

 

　　4.BIG5字符集

　　台湾的多个组织共同发布了主要用于表示繁体中文的字符集，BIG5字符集。

　　对应于BIG编码，用两个字节表示一个字符。

 

　　5.Unicode字符集

　　Unicode 学术学会机构制订的Unicode字符集，收录了多种语言的字符并设定了统一且唯一的二进制码，支持现今世界各种不同语言的书面文本的交换、处理及显示。

　　Unicode字符集有多种字符编码方式：UTF-32编码 / UTF-16编码 / UTF-8编码。

　　UTF-32：每个字符都使用四个字节表示一个字符。

　　UTF-16：将0–65535范围内的字符都使用两个字节表示一个字符，65535范围外的字符用其他技巧

　　UTF-8：是一种可变长度的字符编码，也是一种前缀码。它可以用来表示Unicode标准中的任何字符，且与ASCII兼容，用一至四个字节为每个字符进行编码。（中文一般用三个字节进行编码）

　

你需要知道的字符串编码

在打开网页或者文件的时候，你一定会遇过像这样的字符串乱码问题：

É��OÇ��，常见的操作系统包括...

同时或多或少也遇到 Unicode, UTF-8, ASCII, Latin-1 这些编码术语。编码问题可以说是新人必踩坑，虽然从最后的解决方案来看，可能两三句代码就能解决，但是实际大部分开发者，包括以前的我，也没有真正地理解它。原因并不是因为它复杂，而是它涉及了计算机科学中一个常见的问题，理论与工程实现的区别。理论上我们只需要统一按照 A 方案就可以解决问题，但是由于历史原因，许多编程语言的编码实现都不同，例如 Unicode 编码的第一代标准是 1991 年诞生的，而 Python 和 Java 分别在 1990年 和 1995年才被发明。要真正地理解字符串编码，首先需要了解计算机的一些*础知识，包括字符串如何存储在计算机硬盘中。如果只是希望靠运气来解决或者避开它，反而会在一次次盲目的尝试中浪费更多的时间。如果你不熟悉 Python代码的话，完全可以跳过这篇文章所有的代码段，它不会影响你对这篇文章的影响。

目录

  • *础术语
  • 计算机如何存储数据
  • ASCII编码
  • GBK编码
  • Unicode
  • UTF-8编码
  • HTML实体编码
  • URL编码
  • 常见问题
  • 总结

*础术语

  • 字符
  • 字符串
  • 双射表
  • 字符串编码与解码

字符

A B C 天 气 エ ン コ

上面的用空格分割的每一个都是单个字符，它代表对人类能看懂的有意义的语言文字。在计算机实际的存储中，不同字符占用的空间可能会不同。

字符串

Hello 天气 Hola

上面的用空格分割的每一个就是字符串，也就是多个字符组成的集合

双射表

一一对应的双射表，最常见的类似结构是哈希表，例如：

y = x * 2

中每个 x 都对应并唯一对应一个 y 值，x 与 y 组成的集合就是双射表，例如：

1 -> 2
2 -> 4
3 -> 6

上面每一 个 x 都有对应的 y。

字符串编码与解码

编码指将字符串按照一定的模式（按照双射表的转换）转换成二进制数字，再进行显示或者存储在计算机。如果按照上面的双射表，要把字符串 "123" 存储起来的话，先要转换成对应的 "246"。最后存储 “246“ 的二进制表示，所以计算机实际存储的值是

0010 0100 0110
   2    4    6

与编码相反，字符串解码就是把二进制数据按照相反模式转换成字符串。那么为什么我们不直接存储 “123” 的二进制表示呢？别急，看下去你就明白了。

计算机如何存储数据

早期的计算机存储资源非常宝贵。计算机科学家们希望用最少的空间来存储字符。同时，计算机是使用二进制存储数据的，无论是文字，图片，数字还是其他数据，都是以数字 "0" 或者 "1" 存储起来的。举个例子，如果计算机要存储 "BEE" 这个字符串，它无法直接存储 “BEE"，而必须找到合适的方法来表达 "BEE"，它根据对应的双射表把字母转换成二进制然后存储。这里我们假设计算机使用了一个简单的双射表叫做 EngineGo 表，EngineGo 表用 3位 的二进制数字就能表示 8种 不同的字符。

EngineGo表：

当我们打开文件编辑器，添加"BEE"这3个字母并保存，计算机根据 EngineGo 表存储数据

001 100 100
  B   E   E

当读取文件的时候，计算机会先猜测应该使用哪个双射表（不同语言或者系统会使用不同的双射表）来把二进制数据还原为字符串。如果它猜对了，使用 EngineGo 表还原的话，就会重新得到"BEE"这个字符串。不过如果计算机猜错了，使用其他双射表来打开这个文件的话，最终可能会报错，也可能是乱码，大部分的乱码都是因为这样而出现。理解了这个之后，其实就很容易理解字符串编码和解码了！

ASCII编码

忘记 Enginego 表吧，回到现实，计算机最初由西方国家设计以及发展，理所当然他们使用了英文作为常用的字符集，字符集包括大小写字母，数字加上一些标点符号和运算符号大概120个。Enginego 表的 3位 二进制数字只能表达 8个 不同的字符，明显不够，最简单的解决方案就是使用更多的位来保存，7位 能表示 128个 字符，加多 1位 用作错误检查以及提高寻址效率。最后选择使用 8位 来存储字符，称为一个字节。8位 数字对应的表就更长了（为了方便阅读把二进制转换成了十进制）：

早期计算机科学家们统一用这张表作字符串编码，称为 ASCII 编码。存储和读取也是像使用 EngineGo 表一样简单。这时候存储"BEE"就会存储为：

1000010 1000101 1000101
      B       E       E

非常简单吧。

GBK编码

ASCII 编码只能表示 128个 字符。遇到中文，常用字就 、几千个肯定应付不来，其他亚洲语言也遇到这样的问题。所以一开始国内使用的并不是 ASCII 编码，而是 GBK 编码（像我之前提到的，不同的系统会使用不同的双射表）。本质其实也一样，一张更大的表，用更多的位来表示字符。GBK的编码特别的地方是，它是可变长度的编码，它为了兼容 ASCII 编码，保证能编辑与保存使用 ASCII 编码保存的文件，使用了单字节编码和双字节编码。注意， 如果遇到一个小于 127 的字符，那么编码方式就与 ASCII 表一样，遇到大于 127 的字符，就用两个字节表示一个汉字。当我们把 "BEE" 用 GBK 编码存储的时候，它和使用 ASCII 表存储的二进制数据是一样的。

1000010 1000101 1000101 (无论使用 ASCII 编码还是 GBK 编码都得到这个结果）
      B       E       E

# 以 Python2 为例，encode 是 Python 中编码的方法
>>> foo = 'BEE'.encode('ascii')
>>> bar = 'BEE'.encode('gb2312')
# 结果是一样的
>>> foo == bar
True
# 虽然 bar 使用 gb2312 编码保存，但是因为只包含 ASCII 中的字符，所以可以用 ASCII 来解码
>>> bar.decode('ascii')
u'BEE'
>>> u'BEE' == 'BEE'
True

从上面的输出可以看到，如果只是存储 ASCII 表出现的字符，那么大部分编码表保存的结果都是一样。都能被 ASCII 解码，因为它们都需要兼容 ASCII 表。

不过如果我们要存储中文内容的时候，就不一样啦，例如存储"你好"，GBK编码会把这个字符串编码成

11000100 11100011 10111010 11000011

"你"和"好"这两个字符是用两个字节保存的。 这时候使用 ASCII 编码保存的话就会报错，因为ASCII编码中不知道怎么保存“你"和"好"：

# 要注意这里的'你好'带有 'u' 前缀，在 Python2 里面这是代表这是一个
# unicode 字符串。如果有兴趣你可以从文章最后的常见问题中找到解答，在这里可以先忽略它。
>>> u'你好'.encode('ascii')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)

使用 GBK 编码就没有问题了。

>>> u'你好'.encode('gbk')
'\xc4\xe3\xba\xc3'

当你使用 GBK 编码保存文件，而文件里面包含了中文字符，那么别人使用 ASCII 表就无法解码。就像你使用 GBK 编码在文件中保存了一些中文然后发给你的外国朋友，如果它的编辑软件不支持 GBK 编码的话（早期这经常发生），就会看到乱码。其实大多数编码问题都很好解决，只需要在文档的信息上面添加这是用什么编码的，打开的时候选择对应的解码就好，但是当文档中没有包含编码信息的时候，计算机就会猜测这是什么编码。很多国家都有自己的编码表，例如日本使用 Shift JIS，韩国使用 KS X 1001。我们再看下面这个例子，"你好"经过 GBK 编码变成 4个 字节，从这 4个 字节，计算机无法知道它原本是什么编码的，它尝试用日本的 Shift JIS 编码来解码，发现 Shift JIS 中刚好有这 4个 字节对应的字符串。因为计算机并不了解字符串的含义，所以计算机就会猜这个文件是使用 Shift JIS 编码保存的，按照 Shift JIS 编码来解码，这样在人类看起来，当然就是乱码了。如果我们用 ASCII 表来解码，就会因为找不到对应的字符串而报错。

>>> hello = '你好'
# 使用 gb2312 编码保存'你好'（前面的 decode 是 python2 独有的特性，在最后会解释）
>>> hello_gbk = hello.decode('utf-8').encode("gb2312")
'\xc4\xe3\xba\xc3'
# 使用 Shift-JIS 解码也能成功，得到 'ﾄ羲ﾃ' 的 '乱码' 
>>> hello_gbk.decode("Shift-JIS")
u'\uff84\u7fb2\uff83' 
# 使用 ASCII 解码报错
>>> hello_gbk.decode('ascii')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 0: ordinal not in range(128)

如果你足够聪明的话，最简单解决的方法就是，大家都用统一的表达方式，并且用足够多的二进制位来存储世界上所有字符串。这并不是痴人说梦，Unicode 就是为此而生，它把每个国家的每个字符都编进去，最新的版本已经有 136,755个字符串了。例如你好，对应的是 U+4F60 U+597D。不同于之前的其他编码，Unicode不是一种二进制存储方式，而是一个标准，它规定了表现形式，至于如何编码和解码则根据不同的方式，这是什么意思呢？

Unicode中把每个字符串都定义了不同的表现形式：

4f60 597d
   你   好

Unicode 特别的地方，它只指定了表示形式，而存储形式则可以根据需要而选择，如果根据我们之前的方法直接转换成二进制，每个字符都使用 4个 字节的二进制保存（把“你好”保存为 00004f60，0000597d），那么这就称为 UTF-32 编码。很直观用 4个 字节表达所有字符串了，这没有任何技术上的问题。如果大家都使用 UTF-32 进行编码和解码的话其实就已经解决我们上面的问题了。

UTF-8编码

新的问题其实是传输量的问题，我们可以看到原本传输 "A" 这个字符串，使用 UTF-32 编码的话现在需要用 4个 字节。而以前使用 ASCII 则只需要一个字节，平白无故增加三倍的存储量和传输量当然不划算。UTF-8 编码其实就是用了一些数学技巧，把常用的字符（例如英文字符）用一个字节来表示（其实就是 ASCII 编码），其他用两到四个字节表示。

从上表可以看到，使用 UTF-8编码之后，"A" 还是只需要一个字节存储，而汉字"你"从 4个 字节减少为 3个 字节，大大减少了网络传输量。其实我刚刚说的数学技巧也不复杂，把 Unicode 编码转换成 UTF-8 编码非常简单，我们首先需要一张官方指定的转换表：

  1. 找出要转换的字符的 Unicode 范围，我们以"你"为例子，它的 Unicode 编码是 U+4f60，对应的是第三列（07FF<4f60<FFFF），找到右边的转换规则。
  2. 把 4f60 的二进制 1001111 01100000 从右到左填入转换规则的 x 中，空的填0。得出1001111 01100000 -> 1110xxxx 10xxxxxx 10xxxxxx -> 11100100 10111101 10100000
  3. 最后得到的 11100100 10111101 10100000(e4bda0) 也就是"你"的 UTF-8 编码了。

很可惜，大部分国内的在线转码工具都把 Unicode 和 UTF-8 混淆了，如果你尝试汉字转换成UTF-8 编码，工具返回的却是它的 HTML 实体编码。

HTML实体编码

什么是 HTML 实体编码呢？你可以尝试新建一个后缀为.html的文件，内容为

<!doctype html>
<html>
    <p></div></p>
</html>

保存，然后打开。奇怪，怎么没有把</div>这个字符串显示出来呢？ ，因为浏览器把<div&amp;gt; 中的左右括号当成标签的开始和结束来解析，而不是当成字符串。大多数情况这是我们期望的情景，不过有的时候我们就想显示<div&amp;gt;在页面上，而解决这个问题也很简单，只需要使用转义字符，把文件内容更改为：

<!doctype html>
<html>
    <p>&#60;/div&#62;</p>
</html>

浏览器解析 HTML 的时候会把特殊的字符串理解成非字面的含义，所以当需要显示这些特殊字符串的时候，需要经过下表的转换：

从上表可以看到，特殊字符串是强制需要转换的，而且实际上，任意字符（例如中文）都可以经过转换表示，只需要用

  • &#x 加上其 16 进制 Unicode 编码或者
  • &# 加上其 10 进制 Unicode 编码

作为实体编号即可，浏览器既能解析字符串本身，也能解析其UTF-8编码。

URL编码

URL编码其实也简单易懂，因为 RFC3986 中规定了 URI 中不能出现

: / ? # [ ] @ ! $ & ' ( ) * + , ; =

当要表示这些字符的时候，使用%加上该字符的 16 进制 UTF-8 编码来表示，出现非 ASCII 表的字符也一样，例如在浏览器输入

https://www.example.com/你好

浏览器会自动把不合规定的字符转换成%加 UTF-8 编码再进行请求（但是在地址栏还是会显示原本的字符"你好"），当你复制粘贴这个 URL ，在文本编辑器的时候就可以看到它变成：

https://www.example.com/%E4%BD%A0%E5%A5%BD

这里可以看到"你好"使用了它的 UTF-8 编码表示

常见问题

Python

python2 在保存字符串的时候，是直接用终端的默认编码保存的。一般 Linux 或者苹果系统的默认终端编码是 UTF-8，Windows 中文版的默认终端编码是 cp936 (GBK)。当前终端的默认编码可以通过以下命令查看：

>>> import sys 
>>> sys.stdin.encoding 
'UTF-8' # 'cp936'在Windows系统下

我们可以测试一下：

>>> "你好"
'\xe4\xbd\xa0\xe5\xa5\xbd' # Linux/mac系统使用"你好"的utf-8编码保存
'\xc4\xe3\xba\xc3' # Windows系统使用"你好"的cp936编码保存

“u“ 前缀是 Python 语言的特色，加上 “u“ 前缀的字符串会被当成 Unicode 编码，进行字符串相加的时候要注意，非 ASCII 编码的字符，Unicode 编码和 Utf-8 编码不能直接相加：

>>> u'你好' + '费曼'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe8 in position 0: ordinal not in range(128)
>>> u'hello ' + 'world'
u'hello world'

另外一个常见的问题是：

>>> '你好'.encode('gb2312')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0: ordinal not in range(128)

留意报错的信息，居然说的是 ASCII 编码无法解码字符串，为什么呢？其实在 Python2 中，当它要执行 encode 方法的时候，需要先把字符串解码成 ASCII 编码，所以：

>>> '你好'.encode('gb2312') # 实际python会这样处理
            |
>>>'你好'.decode('ascii').encode('gb2312')

解决这个问题也很容易，把“你好“改成 u“你好“就可以了。

总结

UTF-8编码是现在标准的解决方案，当遇到乱码或者编码出错的时候，先想想原本数据是用什么编码存储的，然后使用对应的方式解码就好。单纯从二进制数据是无法判断它是用什么编码存储的。

字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8

1、引言

今天中午，我突然想搞清楚 Unicode 和 UTF-8 之间的关系，就开始查资料。

这个问题比我想象的复杂，午饭后一直看到晚上9点，才算初步搞清楚。

下面就是我的总结，主要用来整理自己的思路。我尽量写得通俗易懂，希望能对其他朋友有用。毕竟，字符编码是计算机技术的*石，对于程序员来说尤其重要，字符编码的知识是必须要懂的。

2、*础知识

计算机中储存的信息都是用二进制数表示的；而我们在屏幕上看到的英文、汉字等字符是二进制数转换之后的结果。通俗的说，按照何种规则将字符存储在计算机中，如'a'用什么表示，称为"编码"；反之，将存储在计算机中的二进制数解析显示出来，称为"解码"，如同密码学中的加密和解密。在解码过程中，如果使用了错误的解码规则，则导致'a'解析成'b'或者乱码。

字符集（Charset）：是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。

字符编码（Character Encoding）：是一套法则，使用该法则能够对自然语言的字符的一个集合（如字母表或音节表），与其他东西的一个集合（如号码或电脉冲）进行配对。即在符号集合与数字系统之间建立对应关系，它是信息处理的一项*本技术。通常人们用符号集合（一般情况下就是文字）来表达信息。而以计算机为*础的信息处理系统则是利用元件（硬件）不同状态的组合来存储和处理信息的。元件不同状态的组合能代表数字系统的数字，因此字符编码就是将符号转换为计算机可以接受的数字系统的数，称为数字代码。

常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。计算机要准确的处理各种字符集文字，需要进行字符编码，以便计算机能够识别和存储各种文字。

3、ASCII 码

我们知道，计算机内部，所有信息最终都是一个二进制值。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从00000000到11111111。

上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为 ASCII 码，一直沿用至今。

ASCII 码一共规定了128个字符的编码，比如空格SPACE是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的一位统一规定为0。

▲ ASCII编码表

 

4、非 ASCII 编码

英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中，字母上方有注音符号，它就无法用 ASCII 码表示。于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比如，法语中的é的编码为130（二进制10000010）。这样一来，这些欧洲国家使用的编码体系，可以表示最多256个符号。

 

▲ 扩展ASCII编码表

 

但是，这里又出现了新的问题。不同的国家有不同的字母，因此，哪怕它们都使用256个符号的编码方式，代表的字母却不一样。比如，130在法语编码中代表了é，在希伯来语编码中却代表了字母Gimel (ג)，在俄语编码中又会代表另一个符号。但是不管怎样，所有这些编码方式中，0--127表示的符号是一样的，不一样的只是128--255的这一段。

至于亚洲国家的文字，使用的符号就更多了，汉字就多达10万左右。一个字节只能表示256种符号，肯定是不够的，就必须使用多个字节表达一个符号。比如，简体中文常见的编码方式是 GB2312，使用两个字节表示一个汉字，所以理论上最多可以表示 256 x 256 = 65536 个符号。

中文编码的问题比较复杂，将在文末讨论。这里先了解下，虽然都是用多个字节表示一个符号，但是GB类的汉字编码与后文的 Unicode 和 UTF-8 是毫无关系的。

5、Unicode

正如上一节所说，世界上存在着多种编码方式，同一个二进制数字可以被解释成不同的符号。因此，要想打开一个文本文件，就必须知道它的编码方式，否则用错误的编码方式解读，就会出现乱码。为什么电子邮件常常出现乱码？就是因为发信人和收信人使用的编码方式不一样。

可以想象，如果有一种编码，将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码，那么乱码问题就会消失。这就是 Unicode，就像它的名字都表示的，这是一种所有符号的编码。

Unicode 当然是一个很大的集合，现在的规模可以容纳100多万个符号。每个符号的编码都不一样，比如，U+0639表示阿拉伯字母Ain，U+0041表示英语的大写字母A，U+4E25表示汉字严。具体的符号对应表，可以查询unicode.org，或者专门的汉字对应表。

6、Unicode 的问题

需要注意的是，Unicode 只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。

比如，汉字严的 Unicode 是十六进制数4E25，转换成二进制数足足有15位（100111000100101），也就是说，这个符号的表示至少需要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚至更多。

这里就有两个严重的问题，第一个问题是，如何才能区别 Unicode 和 ASCII ？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？第二个问题是，我们已经知道，英文字母只用一个字节表示就够了，如果 Unicode 统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。

它们造成的结果是：1）出现了 Unicode 的多种存储方式，也就是说有许多种不同的二进制格式，可以用来表示 Unicode。2）Unicode 在很长一段时间内无法推广，直到互联网的出现。

7、UTF-8

互联网的普及，强烈要求出现一种统一的编码方式。UTF-8 就是在互联网上使用最广的一种 Unicode 的实现方式。其他实现方式还包括 UTF-16（字符用两个字节或四个字节表示）和 UTF-32（字符用四个字节表示），不过在互联网上*本不用。重复一遍，这里的关系是，UTF-8 是 Unicode 的实现方式之一。

UTF-8 最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。

UTF-8 的编码规则很简单，只有二条：

1）对于单字节的符号：字节的第一位设为0，后面7位为这个符号的 Unicode 码。因此对于英语字母，UTF-8 编码和 ASCII 码是相同的；
2）对于n字节的符号（n > 1）：第一个字节的前n位都设为1，第n + 1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的 Unicode 码。

下表总结了编码规则，字母x表示可用编码的位：

 

跟据上表，解读 UTF-8 编码非常简单。如果一个字节的第一位是0，则这个字节单独就是一个字符；如果第一位是1，则连续有多少个1，就表示当前字符占用多少个字节。

下面，还是以汉字严为例，演示如何实现 UTF-8 编码。

严的 Unicode 是4E25（100111000100101），根据上表，可以发现4E25处在第三行的范围内（0000 0800 - 0000 FFFF），因此严的 UTF-8 编码需要三个字节，即格式是1110xxxx 10xxxxxx 10xxxxxx。然后，从严的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，严的 UTF-8 编码是11100100 10111000 10100101，转换成十六进制就是E4B8A5。

8、Unicode 与 UTF-8 之间的转换

通过上一节的例子，可以看到严的 Unicode码 是4E25，UTF-8 编码是E4B8A5，两者是不一样的。它们之间的转换可以通过程序实现。

Windows平台，有一个最简单的转化方法，就是使用内置的记事本小程序notepad.exe。打开文件后，点击文件菜单中的另存为命令，会跳出一个对话框，在最底部有一个编码的下拉条。

 

里面有四个选项：ANSI，Unicode，Unicode big endian和UTF-8

1）ANSI是默认的编码方式：对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对 Windows 简体中文版，如果是繁体中文版会采用 Big5 码）；
2）Unicode编码这里指的是notepad.exe使用的 UCS-2 编码方式：即直接用两个字节存入字符的 Unicode 码，这个选项用的 little endian 格式；
3）Unicode big endian编码与上一个选项相对应：我在下一节会解释 little endian 和 big endian 的涵义；
4）UTF-8编码：也就是上一节谈到的编码方法。

选择完"编码方式"后，点击"保存"按钮，文件的编码方式就立刻转换好了。

9、Little endian 和 Big endian

上一节已经提到，UCS-2 格式可以存储 Unicode 码（码点不超过0xFFFF）。以汉字严为例，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，就表示该文件采用小头方式。

10、实例讲解

下面，举一个实例。

打开"记事本"程序notepad.exe，新建一个文本文件，内容就是一个严字，依次采用ANSI，Unicode，Unicode big endian和UTF-8编码方式保存。

然后，用文本编辑软件UltraEdit 中的"十六进制功能"，观察该文件的内部编码方式：

1）ANSI：文件的编码就是两个字节D1 CF，这正是严的 GB2312 编码，这也暗示 GB2312 是采用大头方式存储的。

2）Unicode：编码是四个字节FF FE 25 4E，其中FF FE表明是小头方式存储，真正的编码是4E25。

3）Unicode big endian：编码是四个字节FE FF 4E 25，其中FE FF表明是大头方式存储。

4）UTF-8：编码是六个字节EF BB BF E4 B8 A5，前三个字节EF BB BF表示这是UTF-8编码，后三个E4B8A5就是严的具体编码，它的存储顺序与编码顺序是一致的。

UltraEdit下载地址请至官网：

▲ UltraEdit软件

 

11、最后简要看看中文字符集和编码

11.1 GB系列字符集&编码

计算机发明之处及后面很长一段时间，只用应用于美国及西方一些发达国家，ASCII能够很好满足用户的需求。但是当天朝也有了计算机之后，为了显示中文，必须设计一套编码规则用于将汉字转换为计算机可以接受的数字系统的数。

天朝专家把那些127号之后的奇异符号们（即EASCII）取消掉，规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，还把数学符号、罗马希腊的 字母、日文的假名们都编进去了，连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，而原来在127号以下的那些就叫"半角"字符了。

上述编码规则就是GB2312。GB2312或GB2312-80是中国国家标准简体中文字符集，全称《信息交换用汉字编码字符集·*本集》，又称GB0，由中国国家标准总局发布，1981年5月1日实施。GB2312编码通行于中国大陆；新加坡等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持GB2312。GB2312的出现，*本满足了汉字的计算机处理需要，它所收录的汉字已经覆盖中国大陆99.75%的使用频率。对于人名、古汉语等方面出现的罕用字，GB2312不能处理，这导致了后来GBK及GB 18030汉字字符集的出现。下图是GB2312编码的开始部分（由于其非常庞大，只列举开始部分，具体可查看GB2312简体中文编码表）。

 

▲ GB2312编码表的开始部分

 

由于GB 2312-80只收录6763个汉字，有不少汉字，如部分在GB 2312-80推出以后才简化的汉字（如"啰"），部分人名用字（如中国前总理***的"*"字），台湾及香港使用的繁体字，日语及朝鲜语汉字等，并未有收录在内。于是厂商微软利用GB 2312-80未使用的编码空间，收录GB 13000.1-93全部字符制定了GBK编码。根据微软资料，GBK是对GB2312-80的扩展，也就是CP936字码表 (Code Page 936)的扩展（之前CP936和GB 2312-80一模一样），最早实现于Windows 95简体中文版。虽然GBK收录GB 13000.1-93的全部字符，但编码方式并不相同。GBK自身并非国家标准，只是曾由国家技术监督局标准化司、电子工业部科技与质量监督司公布为"技术规范指导性文件"。原始GB13000一直未被业界采用，后续国家标准GB18030技术上兼容GBK而非GB13000。

GB 18030，全称：国家标准GB 18030-2005《信息技术 中文编码字符集》，是中华人民共和国现时最新的内码字集，是GB 18030-2000《信息技术 信息交换用汉字编码字符集 *本集的扩充》的修订版。与GB 2312-1980完全兼容，与GBK*本兼容，支持GB 13000及Unicode的全部统一汉字，共收录汉字70244个。

GB 18030主要有以下特点：

与UTF-8相同，采用多字节编码，每个字可以由1个、2个或4个字节组成；
编码空间庞大，最多可定义161万个字符；
支持中国国内少数民族的文字，不需要动用造字区；
汉字收录范围包含繁体汉字以及日韩汉字。

▲ GB18030编码总体结构

 

本规格的初版使中华人民共和国信息产业部电子工业标准化研究所起草，由国家质量技术监督局于2000年3月17日发布。现行版本为国家质量监督检验总局和中国国家标准化管理委员会于2005年11月8日发布，2006年5月1日实施。此规格为在中国境内所有软件产品支持的强制规格。

11.2 BIG5字符集&编码

Big5，又称为大五码或五大码，是使用繁体中文（正体中文）社区中最常用的电脑汉字字符集标准，共收录13,060个汉字。中文码分为内码及交换码两类，Big5属中文内码，知名的中文交换码有CCCII、CNS11643。Big5虽普及于台湾、香港与澳门等繁体中文通行区，但长期以来并非当地的国家标准，而只是业界标准。倚天中文系统、Windows等主要系统的字符集都是以Big5为*准，但厂商又各自增加不同的造字与造字区，派生成多种不同版本。2003年，Big5被收录到CNS11643中文标准交换码的附录当中，取得了较正式的地位。这个最新版本被称为Big5-2003。

Big5码是一套双字节字符集，使用了双八码存储方法，以两个字节来安放一个字。第一个字节称为"高位字节"，第二个字节称为"低位字节"。"高位字节"使用了0x81-0xFE，"低位字节"使用了0x40-0x7E，及0xA1-0xFE。

有关Big5的更多技术细节读者可单独深入研究，本文就不赘述了。

12、本文小结

这些字符集和编码的关系很容易让程序员混淆，现在小结一下。

简单来说：Unicode、GBK和Big5码等就是编码的值（也就是术语“字符集”），而UTF-8、UTF-16、UTF32之类就是这个值的表现形式（即术语“编码格式”）。

另外：Unicode、GBK和Big5码等字符集是不兼容的，同一个汉字在这三个字符集里的码值是完全不一样的。如＂汉＂的Unicode值与gbk就是不一样的，假设Unicode为a040，GBK为b030。以UTF-8为例，UTF-8码完全只针对Unicode来组织的，如果GBK要转UTF-8必须先转Unicode码，再转UTF-8就OK了。

即GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换：

1）GBK、GB2312 --先转--> Unicode --再转--> UTF8

2）UTF8 --先转--> Unicode --再转--> GBK、GB2312

posted @ 2020-10-14 11:15  CharyGao  阅读(1057)  评论(0)    收藏  举报