[mysql基础文档]-20-字符集与乱码
引言
随着计算机的发展与普及,计算机世界字符编码集变得越来越大和复杂,本文从编码发展的源头入手,详解乱码出现的原因。
文章目录
0×1.字符编码简史
注:以下部分内容来自网络,内容十分有趣,本文整理转述给大家,相信看完这一段,大家对计算机字符编码的发展史会有一个新的认识。
● 字节和计算机的出现
很久很久以前,有一群人,他们决定用8个可以开合的晶体管来组合成不同的状态,以表示世界上的万物。他们看到8个开关状态是好的,于是他们把这称为"字节";
再后来,他们又做了一些可以处理这些字节的机器,机器开动了,可以用字节来组合出很多状态,状态开始变来变去。他们看到这样是好的,于是它们就这机器称为"计算机";
● ASCII编码的诞生
开始时计算机只在美国使用,八位的字节一共可以组合出256(2的8次方)种不同的状态;
他们把其中的编号从0开始的32种状态分别规定了特殊的用途,一但终端、打印机遇上约定好的这些字节被传过来时,就要做一些约定的动作。遇上0x10, 终端就换行,遇上0x07, 终端就向人们嘟嘟叫,例如遇上0x1b, 打印机就打印反白的字,或者终端就用彩色显示字母。他们看到这样很好,于是就把这些0x20以下的字节状态称为"控制码";
他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示,一直编到了第127号,这样计算机就可以用不同字节来存储英语的文字了。大家 看到这样,都感觉很好,于是大家都把这个方案叫做 ANSI 的"ASCII"编码(American Standard Code for Information Interchange,美国信息互换标准代码)。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字;
● ASCII扩展字符集的发展
就像建造巴比伦塔一样,世界各地的都开始使用计算机,但是很多国家用的不是英文,他们的字母里有许多是ASCII里没有的,为了可以在计算机保存他们的文字,他们决定采用127号之后的空位来表示这些新的字母、符号,还加入了很多画表格时需要用下到的横线、竖线、交叉等形状,一直把序号编到了255。从128到255的字符集被称作"扩展字符集";
● GB3212编码的诞生
等中国开始使用计算机时,已经没有可以利用的字节状态来表示汉字,况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民,我们不客气地把那些127号之后的奇异符号们直接取消掉, 并规定:"一个小于127的字符的意义与原来相同,但两个大于127的字符连在一起时,就表示一个汉字,前面的一个字节(称之为高字节)从0xA1用到 0xF7,后面一个字节(称之为低字节)从0xA1到0xFE",这样我们就可以组合出大约7000多个简体汉字了。在这些编码里,我们还把数学符号、罗马希腊的字母、日文的假名都编进去了,连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码,这就是常说的"全角"字符,而原来在127号以下的那些就叫"半角"字符,我们将这种汉字方案叫做"GB2312",是对ASCII的中文扩展;
● GBK编码的诞生
但汉字太多了,我们很快就发现有许多人名没法打出来。于是我们不得不继续把GB2312没有用到的码位找出来用上,但还是不够用,于是干脆不再要求低字节一定是127号之后的内码,只要第一个字节是大于127就固定表示这是一个汉字的开始,不管后面跟的是不是扩展字符集里的内容。扩展之后的编码方案被称为GBK标准,其包括了GB2312的所有内容,同时又增加了近20000个新的汉字(包括繁体字)和符号;
● GB18030编码的诞生
直到有一天少数民族也开始使用电脑了,于是我们又加了几千个新的少数民族字,GBK扩成了GB18030。从此之后,汉字编码体系已经完成,中国的程序员们通称它为 "DBCS"(Double Byte Charecter Set 双字节字符集)。在DBCS系列标准里,最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里,因此他们写的程序为了支持中文处理,必须要注意字串里的每一个字节的值,如果这个值是大于127的,那么就认为一个双字节字符集里的字符出现了;
● ISO组织与UNICODE编码的诞生
当时因为各国都制定了一套自己的编码标准,结果互相之间谁也不懂谁的编码,谁也不支持别人的编码,导致了不同编码之间互通信息时经常出现乱码,就在此时一个叫 ISO(国际标谁化组织)组织决定着手解决这个问题。他们采用的方法很简单——废弃了所有的地区编码方案,重新搞一个包括了地球上所有文化、所有字母和符号的编码,叫做"Universal Multiple-Octet Coded Character Set",简称UCS, 俗称"UNICODE"。
UNICODE开始制订时,计算机的存储器容量迅速发展,储存空间再也不成为问题,于是ISO就直接规定必须用两个字节,也就是16位来统一表示所有的字符,对于ASCII里的那些"半角"字符,UNICODE保持其原编码不变,只是将其长度由原来的8位扩展为16位,而其他文化和语言的字符则全部重新统一编码。由于"半角"英文符号只需要用到低8位,所以其高8位永远是0,因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
这时,从旧社会里走过来的程序员开始发现一个奇怪的现象——他们的strlen函数靠不住了,一个汉字不再是相当于两个字符了,而是一个。从UNICODE开始,无论是半角的英文字母,还是全角的汉字,它们都是统一的"一个字符",同时,也都是统一的"两个字节",请注意"字符"和"字节"两个术语的不同,"字节"是一个8位的物理储存单元,而"字符"则是一个文化相关的符号。在UNICODE中,一个字符就是两个字节。一个汉字算两个英文字符的时代已经过去了。
但UNICODE在制订时没有考虑与任何一种现有的编码方案保持兼容,这使得GBK与UNICODE在汉字的内码编排上完全是不一样的,没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换,这种转换必须通过查表来进行。
如前所述,UNICODE是用两个字节来表示为一个字符,他总共可以组合出65535不同的字符,这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系,ISO已经准备了UCS-4方案,说简单了就是四个字节来表示一个字符,这样我们就可以组合出21亿个不同的字符出来(最高位有其他用途),这大概可以用到银河联邦成立那一天吧;
● 网络时代与UTF-8编码的诞生
UNICODE来到时,一起到来的还有计算机网络的兴起,UNICODE如何在网络上传输也是一个必须考虑的问题,于是面向传输的UTF(UCS Transfer Format)标准出现了,顾名思义,UTF8就是每次8个位传输数据,而UTF16就是每次16个位,只不过为了传输时的可靠性,从UNICODE到UTF时并不是直接的对应,而是要过一些算法和规则来转换,UTF-8用1到6个字节编码UNICODE字符。
UTF-8是一种变长字节编码方式。对于某一个字符的UTF-8编码,如果只有一个字节则其最高二进制位为0;如果是多字节,其第一个字节从最高位开始,连续的二进制位值为1的个数决定了其编码的位数,其余各字节均以10开头。UTF-8最多可用到6个字节。
1字节 0xxxxxxx
2字节 110xxxxx 10xxxxxx
3字节 1110xxxx 10xxxxxx 10xxxxxx
4字节 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
5字节 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
6字节 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
因此UTF-8中可以用来表示字符编码的实际位数最多有31位,即上表中x所表示的位。除去那些控制位(每字节开头的10等),这些x表示的位与UNICODE编码是一一对应的,位高低顺序也相同。
● UNICODE转换UTF-8编码规则简述
编码 | Unicode | UTF-8 |
---|---|---|
1字节编码区域 | 0000 - 007F | 0xxxxxxx |
2字节编码区域 | 0080 - 07FF | 110xxxxx 10xxxxxx |
3字节编码区域 | 0800 - FFFF | 1110xxxx 10xxxxxx 10xxxxxx |
上面这个表格是1~3字节Unicode转UTF-8的规范,请看下面的实例:
例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间,所以要用3字节模板:1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是:0110 1100 0100 1001,将这个比特流按三字节模板的分段方法分为0110 110001 001001,依次代替模板中的x,得到:1110-0110 10-110001 10-001001,即E6 B1 89,这就是"汉"这个字的UTF8编码,这就是为什么中文一个字符在UTF-8编码中占3字节的原因。
在网络里传递信息时有一个很重要的问题,就是对于数据高低位的解读方式,一些计算机是采用低位先发送的方法,例如INTEL架构,而另一些是采用高位先发送的方式,在网络中交换数据时,为了核对双方对于高低位的认识是否是一致的,采用了一种很简便的方法,就是在文本流开始时,向对方发送一个标志符,如果之后的文本先发送高位,那就发送"FEFF",反之,则发送"FFFE"
看到这里,相信大家对字符编码的发展历史有了一个新的认识,如果银河联邦真的成立,那么请翻出这篇文章召唤我,我会复活。
0×2.为什么会出现乱码
这在200x年一段经典例子,故事是这样的,某人在Windows系统中打开了一个记事本程序,并恰巧输入了两个中文字符"联通",而当时的windows,记事本的编码默认是ASCII,ASCII编码并不能识别汉字,但当时的Windows系统大多安装了汉化语言包(GB2312或GBK编码),最终保存的时候,记事本使用GB系列的编码方式将这两个中文字符储存到了硬盘上,在这种编码下,"联通"的内码转换如下;
其中"联"对应的GBK编码是c1aa,"通"对应的GBK编码是cda8,转换成二进制:
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
注意到了吗?第一二个字节、第三四个字节的起始部分的都是"110"和"10",正好与UTF8规则里的两字节模板是一致的,于是再次打开记事本时,记事本就误认为这是一个UTF8编码的文件,对UTF8编码进行还原操作,将第一个字节的110和第二个字节的10去掉,得到"00001 101010",再把各位对齐,前端补0,就得到了"0000 0000 0110 1010",对应了Unicode的006A,也就是小写的字母"j",而之后的两字节用UTF8转换成Unicode是0368,这个字符什么也不是。这就是为什么只有"联通"两个字的文件,保存后再次打开,变成乱码(j口,其中的"口"可能是任意无法识别的字符代替)的原因。
而如果你在"联通"之后多输入几个字再保存,其他的字的编码不见得又恰好是110和10开始的字节,这样再次打开时,记事本就不会坚持这是一个utf8编码的文件,而会尝试ASCII和GBK编码解读,这时乱码又不出现了。
P.s:本例中,记事本程序就相当于连接数据库时候使用的文字终端,记事本文件保存到硬盘,就相当于将数据储存到数据库中,而乱码的产生,就是因为终端和数据库分别使用了不同的编码来解释数据,在下一篇文章中将会实例演示这一点。