** 本文转载自 CENALULU`S TECH BLOG,学习使用,侵删。 *
本文将简述字符集,字符编码的概念。以及在遭遇乱码时的一些常用诊断技巧
背景:字符集和编码无疑是IT菜鸟甚至是各种大神的头痛问题。当遇到纷繁复杂的字符集,各种火星文和乱码时,问题的定位往往变得非常困难。本文就将会从原理方面对字符集和编码做个简单的科普介绍,同时也会介绍一些通用的乱码故障定位的方法以方便读者以后能够更从容的定位相关问题。在正式介绍之前,先做个小申明:如果你希望非常精确的理解各个名词的解释,那么可以查阅wikipedia。本文是博主通过自己理解消化后并转化成易懂浅显的表述后的介绍。
什么是字符集?
- 在介绍字符集之前,我们先了解下为什么要有字符集。
我们在计算机屏幕上看到的是实体化的文字,而在计算机存储介质中存放的实际是二进制的比特流。那么在这两者之间的转换规则就需要一个统一的标准,否则把我们的U盘插到老板的电脑上,文档就乱码了;小伙伴QQ上传过来的文件,在我们本地打开又乱码了。于是为了实现转换标准,各种字符集标准就出现了。简单的说 ** 字符集规定了某个文字对应的二进制数字存放方式(编码)和某串二进制数值代表了哪个文字(解码)的转换关系。**
- 那么为什么会有那么多字符集标准呢?
这个问题实际非常容易回答。问问自己为什么我们的插头拿到英国就不能用了呢?为什么显示器同时有DVI,VGA,HDMI,DP这么多接口呢?很多规范和标准在最初制定时并不会意识到这将会是以后全球普适的准则,或者处于组织本身利益就想从本质上区别于现有标准。于是,就产生了那么多具有相同效果但又不相互兼容的标准了。 说了那么多我们来看一个实际例子,下面就是“屌”这个字在各种编码下的十六进制和二进制编码结果,怎么样有没有一种很“屌”的感觉?
字符集 | 十六进制编码 | 对应的二进制数据 |
---|---|---|
UTF-8 | 0xE5B18C | 1110 0101 1011 0001 1000 1100 |
UTF-16 | 0x5C4C | 1011 1000 1001 1000 |
GBK | 0x8CC5 | 1000 1100 1100 0101 |
什么是字符编码?
** 字符集只是一个规则集合的名字,对应到真实生活中,字符集就是对某种语言的称呼。 ** 例如:英语,汉语,日语。对于一个字符集来说要正确编码转码一个字符需要三个关键元素:** 字库表 (character repertoire)、 编码字符集 (coded character set)、 字符编码 **(character encoding form)。
其中 ** 字库表 ** 是一个相当于所有可读或者可显示字符的数据库,字库表决定了整个字符集能够展现表示的所有字符的范围。** 编码字符集 ,即用一个编码值code point
来表示一个字符在字库中的位置。 字符编码 **,编码字符集和实际存储数值之间的转换关系。
看到这里,可能很多读者都会有和我当初一样的疑问:** 字库表 和 编码字符 **集看来是必不可少的,那既然 ** 字库表 ** 中的每一个字符都有一个自己的序号,直接把序号作为存储内容就好了。为什么还要多此一举通过 ** 字符编码 ** 把序号转换成另外一种存储格式呢?
其实原因也比较容易理解:统一字库表的目的是为了能够涵盖世界上所有的字符,但实际使用过程中会发现真正用的上的字符相对整个字库表来说比例非常低。例如中文地区的程序几乎不会需要日语字符,而一些英语国家甚至简单的ASCII字库表就能满足基本需求。而如果把每个字符都用字库表中的序号来存储的话,每个字符就需要3个字节(这里以Unicode字库为例),这样对于原本用仅占一个字符的ASCII编码的英语地区国家显然是一个额外成本(存储体积是原来的三倍)。算的直接一些,同样一块硬盘,用ASCII可以存1500篇文章,而用3字节Unicode序号存储只能存500篇。于是就出现了UTF-8这样的变长编码。在UTF-8编码中原本只需要一个字节的ASCII字符,仍然只占一个字节。而像中文及日语这样的复杂字符就需要2个到3个字节来存储。
UTF-8 和 Unicode 的关系
为了更好的理解后面的实际应用,我们这里简单的介绍下UTF-8的编码实现方法。即UTF-8的物理存储和Unicode序号的转换关系。 UTF-8编码为变长编码。最小编码单位(code unit
)为一个字节。一个字节的前1-3个bit为描述性部分,后面为实际序号部分。
如果一个字节的第一位为0,那么代表当前字符为单字节字符,占用一个字节的空间。0之后的所有部分(7个bit)代表在Unicode中的序号;
如果一个字节以110开头,那么代表当前字符为双字节字符,占用2个字节的空间。110之后的所有部分(5个bit)加上后一个字节的除10外的部分(6个bit)代表在Unicode中的序号。且第二个字节以10开头;
如果一个字节以1110开头,那么代表当前字符为三字节字符,占用2个字节的空间。110之后的所有部分(5个bit)加上后两个字节的除10外的部分(12个bit)代表在Unicode中的序号。且第二、第三个字节以10开头;
如果一个字节以10开头,那么代表当前字节为多字节字符的第二个字节。10之后的所有部分(6个bit)和之前的部分一同组成在Unicode中的序号。
具体每个字节的特征可见下表,其中 " x " 代表序号部分,把各个字节中的所有 " x " 部分拼接在一起就组成了在Unicode字库中的序号.
Byte 1 | Byte2 | Byte3 |
---|---|---|
0xxx xxxx | ||
110x xxxx | 10xx xxxx | |
1110 xxxx | 10xx xxxx | 10xx xxxx |
我们分别看三个从一个字节到三个字节的UTF-8编码例子:
实际字符 | 在Uncode字库序号的十六进制 | 在Unicode字库序号的二进制 | Utf-8编码后的二进制 | Utf-8编码后的十六进制 |
---|---|---|---|---|
$ | 0024 | 010 0100 | 0010 0100 | 24 |
¢ | 00A2 | 000 1010 0010 | 1100 0010 1010 0010 | C2 A2 |
€ | 20AC | 0010 0000 1010 1100 | 1110 0010 1000 0010 1010 1100 | E2 82 AC |
细心的读者不难从以上的简单介绍中得出以下规律:
- 3个字节的UTF-8十六进制编码一定是以 " E " 开头的
- 2个字节的UTF-8十六进制编码一定是以 " C " 或 " D " 开头的
- 1个字节的UTF-8十六进制编码一定是以比 8 小的数字开头的
为什么会出现乱码?
“ 乱码 ” 也就是英文常说的 mojibake。简单的说乱码的出现是因为:编码和解码时用了不同或者不兼容的字符集。对应到真实生活中,就好比是一个英国人为了表示祝福在纸上谢了 " bless " (编码过程)。而一个法国人拿到了这张纸,由于在发育中 bless 表示受伤的意思,所以认为他的想法是 “ 受伤 ” (解码过程)。这个就是一个显示生活中的乱码情况。在计算机科学中一样,一个用UTF-8编码后的字符,用GBK去解码。由于连个字符集的字库表不一样,同一个汉字在两个字符表的位置也不同,最终就会出现乱码。我们来看一个例子:假设我们用UTF-8编码储存 “ 很屌 ” 两个字,会有如下转换:
字符 | UTF-8编码后的十六进制 |
---|---|
很 | E5BE88 |
屌 | E5B18C |
于是我们得到了 E5BE88E5B18C
这么一串数值。而显示时我们用GBK解码进行展示,通过查表我们获得一下信息:
两个字节的十六进制数值 | GBK解码后对应的字符 |
---|---|
E5BE | 寰 |
88E5 | 堝 |
B18C | 睂 |
解码后我们就得到了寰堝睂这么一个错误的结果,更要命的是连字符个数都变了。