python2.7 中unicode、str的编解码关系

注意：本文实验主要基于win7，Python2.7；以及Linux ，Python2.7。除非特殊说明，所有的命令都是在终端中交互式输入；如果没有强调平台，那么就是window上的结果。下面是一些默认的环境信息（其重要性后文会介绍）

windows

>>> import sys,locale

>>> sys.getdefaultencoding()

'ascii'

>>> locale.getdefaultlocale()

('zh_CN', 'cp936')

>>> sys.stdin.encoding

'cp936'

>>> sys.stdout.encoding

'cp936'

>>> sys.getfilesystemencoding()

'mbcs'

注意，上面CP936是GBK的别名，在https://docs.python.org/2/library/codecs.html#standard-encodings 可以查看。

Linux

>>> import sys,locale

>>> sys.getdefaultencoding()

'ascii'

>>> locale.getdefaultlocale()

('zh_CN', 'UTF-8')

>>> sys.stdin.encoding

'UTF-8'

>>> sys.stdout.encoding

'UTF-8'

>>> sys.getfilesystemencoding()

'UTF-8'

从字符编码说起

首先来说一说gbk gb2312 unicode utf-8这些术语，这些术语与语言无关。

计算机的世界只有0和1，因此任何字符（也就是实际的文字符号）也是由01串组成。计算机为了运算方便，都是8个bit组成一个字节（Byte），字符表达的最小单位就是字节，即一个字符占用一个或者多个字节。字符编码（character encoding）就是字集码，编码就是将字符集中的字符映射为一个唯一二进制的过程。

计算机发源于美国，使用的是英文字母（字符），所有26个字母的大小写加上数字0到10，加上符号和控制字符，总数也不多，用一个字节（8个bit）就能表示所有的字符，这就是ANSI的“Ascii”编码（American Standard Code for Information Interchange，美国信息互换标准代码）。比如，小写字母‘a’的ascii 码是01100001，换算成十进制就是97，十六进制就是0x61。计算机中，一般都是用十六进制来描述字符编码。

但是当计算机传到中国的时候，ASCII编码就行不通了，汉字这么多，一个字节肯定表示不下啊，于是有了GB 2312（中国国家标准简体中文字符集）。GB2312使用两个字节来对一个字符进行编码，其中前面的一个字节（称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，GB2312能表示几千个汉字，而且与asill吗也是兼容的。

但后来发现，GB2312还是不够用，于是进行扩展，产生了GBK（即汉字内码扩展规范）， GBK同Gb2312一样，两个字节表示一个字符，但区别在于，放宽了对低字节的要求，因此能表示的范围扩大到了20000多。后来，为了容纳少数名族，以及其他汉字国家的文字，出现了GB13080。GB13080是兼容GBK与GB2312的，能容纳更多的字符，与GBK与GB2312不同的是，GB18030采用单字节、双字节和四字节三种方式对字符编码

因此，就我们关心的汉字而言，三种编码方式的表示范围是：

GB18030 》 GBK 》 GB2312

即GBK是GB2312的超集，GB1803又是GBK的超集。后面也会看到，一个汉字可以用GBK表示，但不一定能被GB2312所表示

当然，世界上还有更多的语言与文字，每种文字都有自己的一套编码规则，这样一旦跨国就会出现乱码，亟待一个全球统一的解决办法。这个时候ISO（国际标准化组织）出马了，发明了”Universal Multiple-Octet Coded Character Set”，简称 UCS, 俗称 “unicode”。目标很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号 的编码！

unicode每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。unicode编码一定以u开头。

但是，unicode只是一个编码规范，是所有字符对应二进制的集合，而不是具体的编码规则。或者说，unicode是表现形式，而不是存储形式，就是说没用定义每个字符是如何以二进制的形式存储的。这个就跟GBK这些不一样，GBK是表里如下，表现形式即存储形式。

比如汉字“严”的unicode编码是u4e25，对应的二进制是1001110 00100101，但是当其经过网络传输或者文件存储时，是没法知道怎么解析这些二进制的，容易和其他字节混在一起。那么怎么存储unicode呢，于是出现了UTF（UCS Transfer Format），这个是具体的编码规则，即UTF的表现形式与存储格式是一样的。

因此，可以说，GBK和UTF-8是同一个层面的东西，跟unicode是另一个层面的东西，unicode飘在空中，如果要落地，需要转换成utf-8或者GBK。只不过，转换成Utf-8，大家都能懂，更懂用，而转换成GBK，只有中国人才看得懂

UTF也有不同的实现，如UTF-8， UTF-16， 这里以UTF-8为例进行讲解（下面一小节引用了阮一峰的文章）。

unicode与utf-8

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表示可用编码的位。

Unicode符号范围      |        UTF-8编码方式

(十六进制)           |        （二进制）

----------------------+---------------------------------------------

0000 0000-0000 007F | 0xxxxxxx

0000 0080-0000 07FF | 110xxxxx 10xxxxxx

0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

以汉字“严”为例，演示如何实现UTF-8编码。

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

当编解码遇上Python2.x

下面使用Python语言来验证上面的理论。在这一章节中，当提到unicode，一般是指unicode type，即Python中的类型；也会提到unicode编码、unicode函数，请大家注意区别。

另外，对于编码，也有两种意思。第一个是名字，指的是字符的二进制表示，如unicode编码、gbk编码。第二个是动词，指的是从字符到二进制的映射过程。不过后文中，编码作为动词，狭义理解为从unicode类型转换成str类型的过程，解码则是相反的过程。另外强调的是，unicode类型一定是unicode编码，而str类型可能是gbk、ascii或者utf-8编码。

unicode 与 str 区别

在python2.7中，有两种“字符串”类型，分别是str 与 unicode，他们有同一个基类basestring。str是plain string，其实应该称之为字节串，因为是每一个字节换一个单位长度。而unicode就是unicode string，这才是真正的字符串，一个字符（可能多个字节）算一个单位长度。

python2.7中，unicode类型需要在文本之间加u表示。

>>> us = u'严'

>>> print type(us), len(us)

<type 'unicode'> 1

>>> s = '严'

>>> print type(s), len(s)

<type 'str'> 2

>>>

从上可以看到，第一，us、s的类型是不一样的；其二，同一个汉字，不同的类型其长度也是不一样的，对于unicode类型的实例，其长度一定是字符的个数，而对于str类型的实例，其长度是字符对应的字节数目。这里强调一下，s（s = ‘严’）的长度在不同的环境下是不一样的！后文会解释

__str__ __repr__的区别

这是python中两个magic method，很容易让新手迷糊，因为很多时候，二者的实现是一样的，但是这两个函数是用在不同的地方

_str__， 主要是用于展示，str(obj)或者print obj的时候调用，返回值一定是一个str 对象

__repr__， 是被repr(obj)， 或者在终端直接打obj的时候调用

>>> us = u'严'

>>> us

u'\u4e25'

>>> print us

严

可以看到，不使用print返回的是一个更能反映对象本质的结果，即us是一个unicode对象（最前面的u表示，以及unicode编码是用的u），且“严”的unicode编码确实是4E25。而print调用可us.__str__，等价于print str(us)，使得结果对用户更友好。那么unicode.__str__是怎么转换成str的呢，答案会在后面揭晓

unicode str utf-8关系

前面已经提到，unicode只是编码规范（只是字符与二进制的映射集合），而utf-8是具体的编码规则（不仅包含字符与二进制的映射集合，而且映射后的二进制是可以用于存储和传输的），即utf-8负责把unicode转换成可存储和传输的二进制字符串即str类型，我们称这个转换过程为编码。而从str类型到unicode类型的过程，我们称之为解码。

Python中使用decode()和encode()来进行解码和编码，以unicode类型作为中间类型。如下图所示

　　decode　　　　 encode

str ---------> unicode --------->str

即str类型调用decode方法转换成unicode类型，unicode类型调用encode方法转换成str类型。for example

>>> us = u'严'

>>> ss = us.encode('utf-8')

>>> ss

'\xe4\xb8\xa5'

>>> type(ss)

<type 'str'>

>>> ss.decode('utf-8') == us

True

从上可以看出encode与decode两个函数的作用，也可以看出’严’的utf8编码是E4B8A5。

就是说我们使用unicode.encode将unicode类型转换成了str类型，在上面也提到unicode.__str__也是将unicode类型转换成str类型。二者有什么却比呢

unicode.encode 与 unicode.__str__的区别

首先看看文档

str.encode([encoding[, errors]])

　　Return an encoded version of the string. Default encoding is the current default string encoding.

　　

object.__str__(self)

　　Called by the str() built-in function and by the print statement to compute the “informal” string representation of an object.

注意：str.encode 这里的str是basestring，是str类型与unicode类型的基类

可以看到encode方法是有可选的参数：encoding 和 errors，在上面的例子中encoding即为utf-8；而__str__是没有参数的，我们可以猜想，对于unicode类型，__str__函数一定也是使用了某种encoding来对unicode进行编码。

首先不禁要问，如果encode方法没有带入参数，是什么样子的：

>>> us.encode()

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

UnicodeEncodeError: 'ascii' codec can't encode character u'\u4e25' in position 0: ordinal not in range(128)

不难看出，默认使用的就是ascii码来对unicode就行编码，为什么是ascii码，其实就是系统默认编码（sys.getdefaultencoding的返回值）。ascii码显然无法表示汉字，于是抛出了异常。而使用utf-8编码的时候，由于utf能够表示这个汉字，所以没报错。

如果直接打印ss（us.encode(‘utf-8’)的返回值）会怎么样

>>> print ss

涓

结果略有些奇怪，us.__str__(即直接打印us）的结果不一样，那么试试encoding = gbk呢？

>>> print us.encode('gbk')

严

U got it! 事实上也是如此，python会采用终端默认的编码（用locale.getdefaultlocale()查看，windows是为gbk）将unicode编码成str类型。

在Linux（终端编码为utf-8），结果如下：

>>> us= u'严'

>>> print us.encode('utf-8')

严

>>> print us.encode('gbk')

▒▒

>>> print us

严

>>>

注意上面的乱码！

unicode gbk之间的转换

在上上小节，介绍了unicode可以通过utf-8编码（encoding = utf-8），转换成utf-8表示的str，在上一节也可以看出unicode也可以通过gbk编码（encoding=gbk），转换成gbk表示的str。这里有点晕，留作第一个问题，后面解释

unicode与utf8之间的相互转换可以计算得知，但unicode与gbk之间的相互转换没有计算公式，就只能靠查表了，就是说有一张映射表，有某一个汉字对应的unicode表示与gbk表示的映射关系

>> us = u'严'

>>> us

u'\u4e25'

>>> us.encode('gbk')

'\xd1\xcf'

>>> us.encode('gb2312')

'\xd1\xcf'

>>> us.encode('gb18030')

'\xd1\xcf'

>>> s = '严'

>>> s

'\xd1\xcf'

>>>

从上不难看出，严的unicdoe编码是4e25，GBK编码是d1cf，因此us通过gbk编码就是d1cf。同样也能看到，GB18030，GBK，GB2312是兼容的

为什么print us.encode(‘utf-8’)打印出“涓”

ss = us.encode(‘utf-8’)， ss是一个str类型，直接打印结果有点奇怪，一个“涓”字，那一个str类型的“涓”是哪些二进制组成的呢

>>> s = '涓'

>>> s

'\xe4\xb8'

可以看到，str类型的“涓”，其二进制是E4B8，跟’严’的utf8编码（E4B8A5）相差了一个A5，那么就是因为A5显示不出来，验证如下：

>>> print '--%s--' % ss

--涓?-

因此，只是碰巧显示了“涓”而已，事实上ss跟“”涓“”毫无关系

回答第一个问题：str类型到底是什么

在上上小节，提到了utf-8编码的str，与gbk编码的str，感觉有点绕。我们知道，一个汉字‘严’，可存储的编码格式可以是gbk（’xd1xcf’），也可以是utf-8（’xe4xb8xa5’），那么当我们在终端敲入这个汉字的时候，是哪一种格式呢？取决于终端默认编码。

windows上（默认终端编码为gbk）：

>>> s = '严'

>>> s

'\xd1\xcf'

Linux上（默认终端编码为utf-8）：

>>> a = '严'

>>> a

'\xe4\xb8\xa5'

同样一个汉字，同样都是Python中的str类型，在不同的编码格式下，其二进制是不一样的。因此，其长度也是不一样的，对于str类型，其长度是对应的字节长度。

也能看出gbk编码的字节长度一般小于utf-8，这也是gbk继续存在的一个原因。

这里，要强调一下，unicode的二进制形式是与终端的编码格式无关的！这个也不难理解。

unicode函数

str类型到unicode类型的转换，出了上面提到的str.decode，还有一个unicode函数。两个函数的签名为：

unicode(object[, encoding[, errors]])

Return the Unicode string version of object using one of the following modes:

 

str.decode([encoding[, errors]])

Decodes the string using the codec registered for encoding. encoding defaults to the default string encoding.

二者参数相同，事实上二者是等价的，encoding的默认值也是一样的，都是sys.getdefaultencoding()的结果。for example：

>>> s = '严'

>>> newuse = unicode(s)

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

UnicodeDecodeError: 'ascii' codec can't decode byte 0xd1 in position 0: ordinal not in range(128)

 

>>> newuse = unicode(s, 'utf-8')

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

UnicodeDecodeError: 'utf8' codec can't decode byte 0xd1 in position 0: invalid continuation byte

>>> newuse = unicode(s, 'gbk')

>>> newuse

u'\u4e25'

第一个UnicodeDecodeError，就是因为系统默认的编码是asill吗；第二个UnicodeDecodeError，是因为，s（str类型的实例）的编码取决于终端默认编码（即windows下的gbk），为了能打印出来，也就必须用gbk编码来表示这个str，因此只能查询gbk与unicode的映射表将s转换成unicode类型。

为啥调用sys.setdefaultencoding

在诸多Python代码中，都会看到这么一段：

import sys

reload(sys)

sys.setdefaultencoding('utf-8')

不难猜想，setdefaultencoding跟getdefaultencoding是配对的，为啥要将系统的默认编码设置成utf-8，其实就是解决str到unicode的转换问题。

上一小节已经提到过，使用unicode函数将str类型转换成unicode类型时，要考虑两个因素：第一，str本身是什么编码的；第二，如果没有传入encoding参数，默认使用sys.getdefaultencoding。encoding参数必须与str本身的编码对应，否则就是UnicodeDecodeError。

写python代码的程序都知道，我们要在py文件第一行写上：

# -*- coding: utf-8 -*-

这句话的作用在于，告诉编辑器，该文件里面的所有str都采用utf-8编码，且存储文件的时候也是使用utf-8格式。

然后文件中就会使用下面的这种代码。

s='中文'

us=unicode(s)

使用unicode强制转换的时候，都不习惯带参数，为了保证encoding参数必须与str本身的编码一致，所以使用setdefaultencoding将系统默认编码设置为utf-8

乱码与UnicodeError

下面介绍几种常见的乱码与异常UnicodeError， 大多数乱码或者异常的原因在前面已经讲过了，同时，对于一些乱码，也试图给出可行的解决办法。

UnicodeError包括UnicodeDecodeError 与UnicodeEncodeError ，前者是decode也就是str转unicode的时候出了异常，后者则是encode也就是unicode转str的时候出了异常。

对于一个str，直接打印

例子就是上面反复提到的例子

>>> ss = us.encode('utf-8')

>>> print ss

涓

如果一个str类型来自网络或者文件读取，最好先按照对端encode的方式先decode成unicode，然后再输出（输出的时候会自动转换成期望终端支持的编码格式的str）

编码范围无法包括的汉字

直接上例子

>>> newus = u'囍'

>>> newus

u'\u56cd'

>>> newus.encode('gbk')

'\x87\xd6'

>>> newus.encode('gb2312')

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

UnicodeEncodeError: 'gb2312' codec can't encode character u'\u56cd' in position 0: illegal multibyte sequence

>>>

可以看到，‘囍’字可以被gbk编码，但是不能被gb2312编码。

str转unicode的时候

在上面讲unicode函数的时候已经举过例子，会爆出UnicodeDecodeError 异常。

这个错误比较的原因，更多来自str到unicode的默认转换，比如一个str与一个unicode相加的时候：

>>> a = '严'

>>> b = u'严'

>>> c = a + b

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

UnicodeDecodeError: 'ascii' codec can't decode byte 0xd1 in position 0: ordinal not in range(128)

unicode 与 str相加，str会转换为unicode,使用默认的unicode(strobj, encoding = sys.getdefaultencoding())

看起来向unicode编码的字符串

某些情况下，我们打印出一个str类型，看到结果是’\u4e25’， 或者’u4e25’，对于这个字符串，是不是很眼熟，不错， ‘严‘的unicode编码就是u’u4e25’。仔细一看，只是在引号前面多了一个u（表示是一个unicode类型）。那么当我们看到一个’u4e25’的时候，怎么知道对应的汉字是什么？对于已知的这种格式的str，自然可以手动加一个u，然后在终端输出，但是如果是一个变量，需要自动转换成unicode呢，这个时候就可以使用python-specific-encodings中的unicode_escape

>>> s = '\u4e25'

>>> s

'\\u4e25'

>>> us = s.decode('unicode_escape')

>>> us

u'\u4e25'

十六进制格式的字符串

有时候，也会看到类似这样的str，’\xd1\xcf’， 看起来也很熟悉，跟汉字“严”的gbk编码’xd1xcf’很像，区别在于前者多了一个‘’， 这样就无法解释成一个十六进制了。解决办法是python-specific-encodings中的string_escape

>>> s='\\xd1\\xcf'

>>> s

'\\xd1\\xcf'

>>> print s

\xd1\xcf

>>> news = s.decode('string_escape')

>>> news

'\xd1\xcf'

>>> print news

严

给读者的一个问题

在这里留下一个问题：

u'严' == '严'

返回值是True 还是 False呢？当然这里故意省去了上下文环境，不过明确的说，在不同的编码环境下，答案是不一样的，原因都在上文中！

总结与建议

不管怎么样解释，python2.x中的字符编码还是一件让人头疼的事情，即使搞懂了，之后遇到了也可能忘记。对于这个问题，诸多建议如下：

第一：使用python3，就不用再纠结str于unicode了；但是这个很难开发者说了算；

第二：不要使用中文，注释什么的都用英文；理想很丰满，现实很难，只是导致大量的拼音；

第三：对于中文字符串，不要用str表示，而是用unicode表示；现实中也不好实施，大家都不愿意多写一个u

第四：只在传输，或者持久化的时候对unicode进行encode，相反的过程时decode

第五：对于网络接口，约定好编解码格式，强烈建议使用utf-8

第六：看到UnicodeXXXError不要慌，如果XXX是Encode，那么一定是unicode转str的时候出了问题；如果是Decode，一定是str转unicode的时候出了问题。