Python 字符串和字符编码

一个字符不等价于一个字节，字符是人类能够识别的符号，而这些符号要保存到计算的存储中就需要用计算机能够识别的字节来表示。一个字符往往有多种表示方法，不同的表示方法会使用不同的字节数。这里所说的不同的表示方法就是指字符编码，比如字母A-Z都可以用ASCII码表示（占用一个字节），也可以用UNICODE表示（占两个字节），还可以用UTF-8表示（占用一个字节）。字符编码的作用就是将人类可识别的字符转换为机器可识别的字节码，以及反向过程。

UNICDOE才是真正的字符串，而用ASCII、UTF-8、GBK等字符编码表示的是字节串。关于这点，我们可以在Python的官方文档中经常可以看到这样的描述“Unicode string ,  translating a Unicode string into a sequence of bytes"

我们写代码是写在文件中的，而字符是以字节形式保存在文件中的，因此当我们在文件中定义一个字符串时被当做字节串也是可以理解的。但是，我们需要的是字符串，而不是字节串。一个优秀的编程语言，应该严格区分两者的关系并提供巧妙的完美的支持。JAVA语言就很好，以至于了解Python和PHP之前我从来没有考虑过这些不应该由程序员来处理的问题。遗憾的是，很多编程语言试图混淆“字符串”和“字节串”，他们把字节串当做字符串来使用，PHP和Python2都属于这种编程语言。最能说明这个问题的操作就是取一个包含中文字符的字符串的长度：

注意：Windows的cmd终端字符编码默认为GBK，因此在cmd输入的中文字符需要用两个字节表示

Python3中对字符串的支持做了很大的改动，具体内容会在下面介绍。

先做下科普：UNICODE字符编码，也是一张字符与数字的映射，但是这里的数字被称为代码点（code point），实际上就是十六进制的数字。

Python官方文档中对Unicode字符串、字节串与编码之间的关系有这样一段描述：

Unicode字符串是一个代码点（code point）序列，代码点取值范围为0到0x10FFFF（对应的十进制为1114111）。这个代码点序列在存储（包括内存和物理磁盘）中需要被表示为一组字节(0到255之间的值)，而将Unicode字符串转换为字节序列的规则称为编码。

这里说的编码不是指字符编码，而是指编码的过程以及这个过程中所使用到的Unicode字符的代码点与字节的映射规则。这个映射不必是简单的一对一映射，因此编码过程也不必处理每个可能的Unicode字符，例如：

将Unicode字符串转换为ASCII编码的规则很简单，对于每个代码点：

将Unicode字符串转换为UTF-8编码使用以下规则：

简单总结：

可见，无论是编码还是解码，都需要一个重要因素，就是特定的字符编码。因为一个字符用不同的字符编码进行编码后的字节值以及字节个数大部分情况下是不同的，反之亦然。

我们都知道，磁盘上的文件都是以二进制格式存放的，其中文本文件都是以某种特定编码的字节形式存放的。对于程序源代码文件的字符编码是由编辑器指定的，比如我们使用Pycharm来编写Python程序时会指定工程编码和文件编码为UTF-8，那么Python代码被保存到磁盘时就会被转换为UTF-8编码对应的字节（encode过程）后写入磁盘。当执行Python代码文件中的代码时，Python解释器在读取Python代码文件中的字节串之后，需要将其转换为UNICODE字符串（decode过程）之后才执行后续操作。

上面已经解释过，这个转换过程（decode，解码）需要我们指定文件中保存的字节使用的字符编码是什么，才能知道这些字节在UNICODE这张万国码和统一码中找到其对应的代码点是什么。这里指定字符编码的方式大家都很熟悉，如下所示：

那么，如果我们没有在代码文件开始的部分指定字符编码，Python解释器就会使用哪种字符编码把从代码文件中读取到的字节转换为UNICODE代码点呢？就像我们配置某些软件时，有很多默认选项一样，需要在Python解释器内部设置默认的字符编码来解决这个问题，这就是文章开头所说的“默认编码”。因此大家所说的Python中文字符问题就可以总结为一句话：当无法通过默认的字符编码对字节进行转换时，就会出现解码错误(UnicodeEncodeError)。

Python2和Python3的解释器使用的默认编码是不一样的，我们可以通过sys.getdefaultencoding()来获取默认编码：

因此，对于Python2来讲，Python解释器在读取到中文字符的字节码尝试解码操作时，会先查看当前代码文件头部是否有指明当前代码文件中保存的字节码对应的字符编码是什么。如果没有指定则使用默认字符编码"ASCII"进行解码导致解码失败，导致如下错误：

对于Python3来讲，执行过程是一样的，只是Python3的解释器以"UTF-8"作为默认编码，但是这并不表示可以完全兼容中文问题。比如我们在Windows上进行开发时，Python工程及代码文件都使用的是默认的GBK编码，也就是说Python代码文件是被转换成GBK格式的字节码保存到磁盘中的。Python3的解释器执行该代码文件时，试图用UTF-8进行解码操作时，同样会解码失败，导致如下错误：

其实Python3中对字符串支持的改进，不仅仅是更改了默认编码，而是重新进行了字符串的实现，而且它已经实现了对UNICODE的内置支持，从这方面来讲Python已经和JAVA一样优秀。下面我们来看下Python2与Python3中对字符串的支持有什么区别：

Python2中对字符串的支持由以下三个类提供

执行 help(str) 和 help(bytes) 会发现结果都是str类的定义，这也说明 Python2中 str就是字节串，而后来的unicode对象才是真正的字符串。

输出结果：

Python3中对字符串的支持进行了实现类层次的上简化，去掉了unicode类，添加了一个bytes类。从表面上来看，可以认为Python3中的str和unicode合二为一了。

实际上，Python3中已经意识到之前的错误，开始明确的区分字符串与字节。因此Python3中的str已经是真正的字符串，而字节是用单独的bytes类来表示。也就是说，Python3默认定义的就是字符串，实现了对UNICODE的内置支持，减轻了程序员对字符串处理的负担。

输出结果：

上面提到，UNICODE字符串可以与任意字符编码的字节进行相互转换，如图：

那么大家很容易想到一个问题，就是不同的字符编码的字节可以通过Unicode相互转换吗？答案是肯定的。

字节串-->decode('原来的字符编码')-->Unicode字符串-->encode('新的字符编码')-->字节串

输出结果：

字符串-->encode('新的字符编码')-->字节串

输出结果：

输出结果：

特别说明：Unicode不是有道词典，也不是google翻译器，它并不能把一个中文翻译成一个英文（即中文还是中文）。正确的字符编码的转换过程只是把同一个字符的字节表现形式改变了，而字符本身的符号是不应该发生变化的，因此并不是所有的字符编码之间的转换都是有意义的。怎么理解这句话呢？比如GBK编码的“中国”转成UTF-8字符编码后，仅仅是由4个字节变成了6个字节来表示，但其字符表现形式还应该是“中国”，而不应该变成“你好”或者“China”。

chr()函数用一个范围在range（256）内的（就是0～255）整数作参数，返回一个对应的字符。unichr()跟它一样，只不过返回的是Unicode字符，这个从Python 2.0才加入的unichr()的参数范围依赖于你的Python是如何被编译的。如果是配置为USC2的Unicode，那么它的允许范围就是range（65536）或0x0000-0xFFFF；如果配置为UCS4，那么这个值应该是range（1114112）或0x000000-0x110000。如果提供的参数不在允许的范围内，则会报一个ValueError的异常。

ord()函数是chr()函数（对于8位的ASCII字符串）或unichr()函数（对于Unicode对象）的配对函数，它以一个字符（长度为1的字符串）作为参数，返回对应的ASCII数值，或者Unicode数值，如果所给的Unicode字符超出了你的Python定义范围，则会引发一个TypeError的异常。

unichr()函数被取消了，因为Python3中的chr()不仅仅支持ASCII码的转换，而且直接支持了更为适用的Unicode码的转换，但是Unicode码的0-127和ASCII码还是一样的，所以不用担心ASCII不能用的问题。

注意：127-255的扩展ASCII码和Unicode是不同的，这点要注意。

参考：

Python中的字符串与字符编码

[廖雪峰]Python字符串和编码

Python2和Python3中的字符串编码问题解决

Python3.x 中，chr() 和 ord() 默认支持unicode

关于Python ord()和chr()返回ASCII码和Unicode码的看法