打开APP
userphoto
未登录

开通VIP,畅享免费电子书等14项超值服

开通VIP
计算机编码,想说爱你不容易,文本让你彻底搞懂

序言

一直以来,计算机编码问题像幽灵一般,不少开发人员都受过它的困扰。

试想你请求一个数据,却得到一堆乱码,丈二和尚摸不着头脑。有同事质疑你的数据是乱码,虽然你很确定传了 UTF-8 ,却也无法自证清白,更别说帮同事 debug 了。

本文从 ASCII 码说起,带你扒一扒编码背后那些事。相信搞清编码的原理后,你将不再畏惧任何编码问题。

从 ASCII 码说起

现代计算机技术起源于美国,最先遇到的也是英文文本。英文文本一般由 26 个小写字母、26个大写字母,外加 0-9 共个10数字以及若干!$特殊符号组成,共计也不过 100个左右。

而计算机中最基本的存储单位为 字节 ( byte ),由 8 个比特位( bit )组成,也叫做 八位字节 ( octet )。8 个比特位可以表示 2^8 = 256 个字符,看上去完全可用一个字节来存储英文字符。

计算机先驱们也是这么想的。他们为每个英文字符编号,再加上一些控制符,形成了我们所熟知的 ASCII 码表。实际上,由于英文字符不多,他们只用了字节的后 7 位而已

ASC编码表

根据 ASCII 码表,参考上面表,由 01000001 这 8 个比特位组成的八位字节,代表字母 A。

因为01000001对应的十进制为65,所以,通常使用下表表示ASC编码,以方便教学。

128位的ASCII编码表

Latin1拉丁字母

西欧人民来了,他们主要使用拉丁字母语言。与英语类似,拉丁字母数量并不大,大概也就是几十个。于是,西欧人民打起 ASCII 码表那个未用的比特位( b8 )的主意。

还记得吗?ASCII 码表总共定义了 128 个字符,范围在 0~127 之间(参考上图),字节最高位 b8 暂未使用。于是,西欧人民将拉丁字母和一些辅助符号(如欧元符号)定义在 128~255 之间。这就构成了 Latin1 ,它是一个 8 位字符集,定义了以下字符:

256的ASC编码表

图中绿色部分是不可打印的( unprintable )控制字符,左半部分8列是 ASCII 码,右边部分8列是扩展码。因此,latin1 字符集是 ASCII 码的超集:

一个字节掰成两半,欧美两兄弟各用一半。至此,欧美人民都玩嗨了,东亚人民呢?

GB2312、GBK和GB18030

由于受到汉文化的影响,东亚地区主要是汉字圈,我们便以中文为例展开介绍(日韩泰等类似)。

汉字有什么特点呢?—— 最大的问题是:数量多!光常用汉字就有几千个,这可不是一个字节能胜任的。一个字节不够就两个呗。道理虽然如此,操作起来却未必这么简单。

首先,将需要编码的汉字和 ASCII 码整理成一个字符集,同时还需要兼容现有的ASCII编码 。为什么需要 ASCII 码呢?因为,在计算机世界,不可避免要跟数字、英文字母打交道。至于拉丁字母,重要性就没那么大。

GB2312 字符集总共收录了 6 千多个汉字,用两个字节来表示足矣,但事情远没有这么简单。同样的数字字符,物理、化学符号等。在 GB2312 中占用 2 个字节,在 ASCII 码中占用 1 个字节,这不就不兼容了吗?计算机里太多东西涉及 ASCII 码了,看看一个 http 请求:

GET / HTTP/1.1Host: www.example.com

那么,怎么兼容 GB2312 和 ASCII 码呢?天无绝人之路, 变长 编码方案应运而生。

变长编码方案,字符由长度不一的字节表示,有些字符只需 1 字节,有些需要 2 字节,甚至有些需要更多字节。GB2312 中的 ASCII 码与原来保持一致,还是用一个字节来表示,这样便解决了兼容问题。

在 GB2312 中,如果一个字节最高位 b8 为 0 ,该字节便是单字节编码,即 ASCII 码。如果字节最高位 b8 为 1 ,它就是双字节编码的首字节,与其后字节一起表示一个字符。

变长编码方案目的在于兼容 ASCII 码,但也带来一个问题:由于字节编码长度不一,定位第 N 个字符只能通过遍历实现,时间复杂度从 O(1) 退化到 O(N) 。好在这种操作场景并不多见,因此影响可以忽略。

GB2312 收录的汉字个数只有常用的 6 千多个,遇到生僻字还是无能为力。因此,后来又推出了 GBK 和 GB18030 字符集。GBK 是 GB2312 的超集,完全兼容 GB2312 ;而 GB18030 又是 GBK 的超集,完全兼容 GBK 。

因此,对中文编码文本进行解码,指定 GB18030 最为健壮:

>>> raw = b'\xfd\x88\xb5\xc4\xb4\xab\xc8\xcb'>>> raw.decode('gb18030')'龍的传人'

指定 GBK 或 GB2312 就只好看运气了,GBK 多半还没事:

>>> raw.decode('gbk')'龍的传人'

GB2312 经常直接抛锚不商量:

>>> raw.decode('gb2312')Traceback (most recent call last):File '<stdin>', line 1, in <module>UnicodeDecodeError: 'gb2312' codec can't decode byte 0xfd in position 0: illegal multibyte sequence

chardet 是一个不错的文本编码检测库,用起来很方便,但对中文编码支持不是很好。经常中文编码的文本进去,检测出来的结果是 GB2312,但一用 GB2312 解码就跪:

>>> import chardet>>> raw = b'\xd6\xd0\xb9\xfa\xc8\xcb\xca\xc7\xfd\x88\xb5\xc4\xb4\xab\xc8\xcb'>>> chardet.detect(raw){'encoding': 'GB2312', 'confidence': 0.99, 'language': 'Chinese'}>>> raw.decode('GB2312')Traceback (most recent call last):File '<stdin>', line 1, in <module>UnicodeDecodeError: 'gb2312' codec can't decode byte 0xfd in position 8: illegal multibyte sequence

掌握 GB2312 、 GBK 、 GB18030 三者的关系后,我们可以略施小计。如果 chardet 检测出来结果是 GB2312 ,就用 GB18030 去解码,大概率可以成功!

>>> raw.decode('GB18030')'中国人是龍的传人'

Unicode

GB2312 、 GBK 与 GB18030 都是中文编码字符集。虽然 GB18030 也包含日韩表意文字,算是国际字符集,但毕竟是以中文为主,无法适应全球化应用。

在计算机发展早期,不同国家都推出了自己的字符集和编码方案,互不兼容。中文编码的文本在使用日文编码的系统上是无法显示的,这就给国际交往带来障碍。

这时,英雄出现了。统一码联盟 站出来说要发展一个通用的字符集,收录世界上所有字符,这就是 Unicode 。经过多年发展, Unicode 已经成为世界上最通用的字符集,也是计算机科学领域的业界标准。

Unicode 已经收录的字符数量已经超过 13 万个,每个字符需占用超过 2 字节。由于常用编程语言一般没有 24 位数字类型,因此一般用 32位数字表示一个字符。这样一来,同样的一个英文字母,在 ASCII 中只需占用 1 字节,在 Unicode 则需要占用 4 字节!英美人民都要哭了,试想你磁盘中的文件大小都增大了 4 倍是什么感受!

UTF-8

为了兼容 ASCII 并优化文本空间占用,我们需要一种变长字节编码方案,这就是著名的 UTF-8 。与 GB2312 等中文编码一样,UTF-8 用不固定的字节数来表示字符:

  1. ASCII 字符 Unicode 码位由 U+0000 至 U+007F ,用 1 个字节编码,最高位为 0 ;
  2. 码位由 U+0080 至 U+07FF 的字符,用 2 个字节编码,首字节以 110 开头,其余字节以 10 开头;
  3. 码位由 U+0800 至 U+FFFF 的字符,用 3 个字节编码,首字节以 1110 开头,其余字节同样以 10 开头;
  4. 4 至 6 字节编码的情况以此类推;

如图,以 0 开头的字节为 单字节 编码,总共 7 个有效编码位,编码范围为 U+0000 至 U+007F ,刚好对应 ASCII 码所有字符。以 110开头的字节为 双字节 编码,总共 11 个有效编码位,最大值是 0x7FF ,因此编码范围为 U+0080 至 U+07FF ;以 1110 开头的字节为 三字节 编码,总共 16 个有效编码位,最大值是 0xFFFF 因此编码范围为 U+0800 至 U+FFFF 。

根据开头不同, UTF-8 流中的字节,可以分为以下几类:

字节最高位类别有效位0单字节编码710多字节编码非首字节110双字节编码首字节111110三字节编码首字节1611110四字节编码首字节21111110五字节编码首字节261111110六字节编码首字节31

至此,我们已经具备了读懂 UTF-8 编码字节流的能力,不信来看一个例子:

UTF-16,UTF-32

除了UTF-8,还有UTF-16,UTF-32编码,这些编码设计到更复杂的程序现实。例如在上面,我们讲过英文使用一个字节,汉字 使用两个字节。

这使得在程序里,计算字符长度出现了不同,例如

 string word1='hi'; string word2='你好'; int length1=word1.Length; int lenth2=word2.Length;

当计算字符长度时, length1表示的长度表示的是2, length2的长度也是2,但是length1是2个字节,而length2是四个字节,导致意想不到的结果。

UTF-16 LE是windows上默认的Unicode编码方式,在C++编程里,使用wchar_t表示。所有wchar_t *类型的字符串 VC都自动采用UTF-16的编码。

但是由于没有统一的表示UTF-16编码的字符类型。C++98/03里对wchar_t的定义是非常宽泛的。这导致在Windows平台上,wchar_t是2字节的;在Unix-like系统上是4字节的。代码移植上,可能会遇到挑战

UTF-32

优势这个优势就明显了,所有字符都是4字节,固定长度,劣势是对以英文为主的字符串来说,空间消耗大。例如一个100M文件,突然变成400M,用户会傻眼。在记事本上,另存文件时,可以选择编码类型。

概念回顾

一直以来,字符集编码 这两个词一直是混着用的。现在,我们总算有能力厘清这两者间的关系了。

字符集 顾名思义,就是由一定数量字符组成的集合,每个字符在集合中有唯一编号。前文提及的 ASCII 、 latin1 、 GB2312 、GBK 、GB18030 以及 Unicode 等,无一例外,都是字符集。

计算机存储和网络通讯的基本单位都是 字节 ,因此文本必须以 字节序列 的形式进行存储或传输。那么,字符编号如何转化成字节呢?这就是 编码 要回答的问题。

在 ASCII 码和 latin 中,字符编号与字节一一对应,这是一种编码方式。GB2312 则采用变长字节,这是另一种编码方式。而 Unicode 则存在多种编码方式,除了 最常用的 UTF-8 编码,还有 UTF-16 等。实际上,UTF-16 编码效率比 UTF-8 更高,但由于无法兼容 ASCII ,应用范围受到很大制约。

最佳实践

认识文本编码的前世今生之后,应该如何规避编码问题呢?是否存在一些最佳实践呢?答案是肯定的。

编码选择

项目开始前,需要选择一种适应性广的编码方案,UTF-8 是首选,好处多多:

  • Unicode 是业界标准,编码字符数量最多,天然支持国际化;
  • UTF-8 完全兼容 ASCII 码,这是硬性指标;
  • UTF-8 目前应用最广;

如因历史原因,不得不使用中文编码方案,则优先选择 GB18030 。这个标准最新,涵盖字符最多,适应性最强。尽量避免采用 GBK ,特别是 GB2312 等老旧编码标准。

编程习惯

如果你使用的编程语言,字符串类型支持 Unicode ,那问题就简单了。由于 Unicode 字符串肯定不会导致诸如乱码等编码问题,你只需在输入和输出环节稍加留意。

举个例子,Python 从 3 以后, str 就是 Unicode 字符串了,而 bytes 则是 字节序列 。因此,在 Python 3 程序中,核心逻辑应该统一用 str 类型,避免使用 bytes 。文本编码、解码操作则统一在程序的输入、输出层中进行。

假如你正在开发一个 API 服务,数据库数据编码是 GBK ,而用户却使用 UTF-8 编码。那么,在程序 输入层 , GBK 数据从数据库读出后,解码转换成 Unicode 数据,再进入核心层处理。在程序 核心层 ,数据以 Unicode 形式进行加工处理。由于核心层处理逻辑可能很复杂,统一采用 Unicode 可以减少问题的发生。最后,在程序的 输出层 将数据以 UTF-8 编码,再返回给客户端。

整个过程伪代码大概如下:

# input# read gbk data from database and decode it to unicodedata = read_from_database().decode('gbk')# core# process unicode data onlyresult = process(data)# output# encoding unicode data into utf8response_to_user(result.encode('utf8'))

这样的程序结构看起来跟个三明治一样,非常形象:

当然了,还有很多编程语言字符串还不支持 Unicode 。Python 2 中的 str 对象,跟 Python 3 中的 bytes 比较像,只是字节序列;C 语言中的字符串甚至更原始。

这都无关紧要,好的编程习惯是相通的:程序核心层统一使用某种编码,输入输出层则负责编码转换。至于核心层使用何种编码,主要看程序中哪种编码使用最多,一般是跟数据库编码保持一致即可。

注:本文主要来源博客园的fasionchan编写的《一文说清文本编码那些事》,略有改动。

本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请点击举报
打开APP,阅读全文并永久保存 查看更多类似文章
猜你喜欢
类似文章
【热】打开小程序,算一算2024你的财运
存文本文件及其字符编码
文本与文本处理(一)
关于文本乱码的问题
UNICODE与UTF8,UTF16的含义
编码歪传
Python中关于coding=utf
更多类似文章 >>
生活服务
热点新闻
分享 收藏 导长图 关注 下载文章
绑定账号成功
后续可登录账号畅享VIP特权!
如果VIP功能使用有故障,
可点击这里联系客服!

联系客服