编码问题以及其在Python2与3的差异
本人工作使用Python2.7，在业余做玩具的时候使用的Python3.5，今天在使用zipfile模块的时候，遇到zip文件中有中文的文件夹，导致乱码。所以在解决问题的时候，顺道就摸索了一下编码问题的差异。
如有错误，请指正！
一般我们遇到的编码问题，主要是两类：文件的编码和数据的编码。
- 文件的编码问题，请再编辑器中设置文件的编码为utf-8，如果使用中文注释，Python2和3的处理方式相同，请在第一行或第二行加一个编码申明即可（'# -- coding=utf-8 --' 或者 '# encoding=utf-8'）
- 而数据的编码，Python2与3稍微有些差别。这里也主要记录下数据编码的问题。
是什么导致的编码问题
在语言设计之初，都是使用英文，所以字符集是ascii码。即在存储的时候，使用只占一个字节的数字对映射一个字符，你想呀，一个字节可以表示的最大字符数是255（00H—FFH）。这对于英文而言，是完全足够的，一般只用到前128个(00H--7FH,最高位为0)。而最高位为1 的另128 个字符（80H—FFH）被称为“扩展ASCII”，一般用来存放英文的制表符、部分音标字符等等的一些其它符号。
后来国际化了，到中国，发现ASCII码不够用呀。咋办？
于是中国的编码方式出现了：GB2312。它是和ASCII 兼容的一种编码规范， 其实就是利用扩展ASCII没有真正标准化这一点，把一个中文字符用两个扩展ASCII 字符来表示，以区分ASCII 码部分。但是中文的文字编码和扩展ASCII 码有重叠呀：把两个英文符号解释为中文的一个字或者把一个中文字解释为两个英文符号，就“乱码”了。同样的问题再其他国家也类似。
为了解决这个问题，unicode字符集就出现了。并且再后面的发展中把全世界所有的文字都考虑进来，给每一个文字分配一个编码。因为编码方式的不同，所以可以使用2个字节来表示，也可使用4个字节来表示。
所以编码问题主要原因是不同字符集以及其编码方式不同导致的。
Python2与3在编码的差异
- 文件编码：都是使用utf-8，此处是针对文件BOM头（文件最前头的不可见的内容，帮助编辑器识别文件编码方式的一个标识）。
- Python环境编码方式：都需要文件第一行或者第二行申明文件编码方式。
- Python变量编码方式：
在Python2中主要有str和unicode两种字符串类型，而到Python3中改为了bytes和str。因为Python3默认了字符串类型为unicode（所以再3中，字符串抛弃了u'中文'的定义方式，但Python3中如果是写或者读bytes类型就必需带上'b'）。
| - | 字符串类型 | 默认编码 |
|---|---|---|
| Python2 | str & unicode | 默认采取的ASCII编码，字母、标点和其他字符只使用一个字节来表示，但对于中文字符来说，一个字节满足不了需求。使用u'中文'方式申明变量。 |
| Python3 | bytes & str | 默认用unicode编码，所以申明变量不用使用u'中文'方式。 |
根据上表可以看出来，代码中申明的变量的问题就解决了。
但是外来的数据呢？
比如说读取文件中的数据或者web前端传过来的数据呢？
其实很简单，而且Python2和3的处理方式是有一些差异的。
就拿我在使用ziplib，举个例子：比如ZipFile对象中的info_list的filename的编码方式为cp437。
-
Python3中，那么filename为unicode的str。那么首先需要把filename翻译为计算机认识的字符串：filename.encode('cp437')，然后再转为人能看到的字符串：decode('gbk')。
此处可能有同学要问了，为什么decode不使用utf-8方式呢？
因为cp437和gbk是ASCII编码，而utf-8为unicode编码了，在解码过程中decode为utf-8，直接不认识呀，那么就出错了。 -
Python2中，那么filename为ascii码的str。那么想象下要输出中文，首先他要是一个unicode，那毫不犹豫要是unicode(filename, 'utf-8')或者unicode(filename, 'gbk')就可以。
