由于 Python 在 1989 年被创造出来，Python 2 发布于 2000 年，这时 Unicode 还没有被广泛应用，所以 Python 2 中对于宽字符集的先天支持不够完善，使用过程中会有些容易误解的地方。本文以中文处理为例，说下对于宽字符集的处理。
先说结论：
- 所有 Python 源文件的文件头，加上
# -*- coding: UTF-8 -*-或# coding: u8 - 所有源文件保存为 UTF-8 编码
- 代码中所有带有中文的字面值字符串，都使用 Unicode 字符串，如：
s = u'测试中文' - 从文本文件中读取的内容，如果需要对其中的字符做编辑处理，需要在打开文件时指定编码，或者当做字节流加载后，转为 Unicode 字符串处理。
- 将字符串内容保存到文件时，先指定要使用的编码，将编码后得到的数据写入文件
细说
一、理想状态
近几年相对新一些的开发语言，已经对 Unicode 有了完善支持，个人理解整体的处理思路是这样的：
1、通过对源文件字符编码格式处理能力的增强，编译器可以自动处理源文件的编码格式，或者默认约定为 UTF-8，来减少这方面带来的干扰；
2、内存中的字符串，不存在所谓的编码问题，只是各个字符序号的一个序列；
3、所谓的 UTF-xx 编码这样的说法，只是用于存储和传输过程的需要。UTF 即 Unicode Transformation Format，定义也说明了其用途。
二、历史包袱
对于历史比较悠久的开发语言或者开发工具，由于历史原因，当年还没有 Unicode，所以语言缺乏对于 Unicode 原生的支持，一般会通过类库来做扩展进行支持。个人接触过的开发工具有：Delphi 7 及之前版本（之后的我没用过）中的 Object Pascal、Python 2。（插句题外话，突然觉得 C 当年是多么机灵，竟然没有引入字符串类型，没给自己找麻烦，一切处理交给类库，随时升级，啧啧啧……）
以 Python 2 为例，当初的字符串是个字节流，其中每个字节表示一个 ASCII 码。而且实际上，即便一些字节超出 ASCII 范围，也一样能放到字符串中。所以，遇到宽字符集中的字符，一样可以用字符串表示，但是计算字符串长度、获取特定位置字符时，就会出现问题：
# Python REPL 环境中的测试
>>> s = '测试中文'
>>> print s, type(s), len(s)
测试中文 <type 'str'> 12
这时就需要一种支持 Unicode 的字符串类型作为弥补：
# Python REPL 环境中的测试
>>> s = u'测试中文'
>>> print s, type(s), len(s)
测试中文 <type 'unicode'> 4
三、引起混乱的原因
个人认为，在开发环境对 Unicode 支持不够完善的情况下，以下几方面都容易引入问题：
- 源文件编码格式（建议统一使用 UTF-8）
- 编译器对于源文件格式的识别和处理（这个作为代码编写者无法干预，只能按照规则执行）
- 编译器对于源码中宽字符字面值的理解
- 外部数据的格式，如：外部文件、从网络获取的数据
这几种情况中：
1、2 可以通过规范约定，能扫清很多干扰。
3 比较容易处理，按照语言规则，让编译器按照 Unicode 去处理字面值中的宽字符（如中文）的处理，类似这样
s = u'测试中文'
# 这样编写，字符串 s 就是按照 Unicode 处理其中内容的
4 是真正要注意的情况。这部分内容不受编程时代码的约束，完全决定于外部环境。对于对 Unicode 支持良好的开发环境，获取数据时，会保存到一个二进制字节流中，当转换为字符串表示时，需要指定字符编码，然后才能做转换，每一步都很清晰，而且拿到的字符串，一定是 Unicode。而在 Python 2 中，没有这样的强制要求，所以就需要自己处理：
# -*- coding: UTF-8 -*-
# 打开文件并读取内容
fp = open('file.txt', 'r')
data = fp.read()
print type(data)
# 根据数据实际的编码格式，转换为 Unicode 字符串，再进行使用
s = data.decode('gbk')
print type(s)
print s
四、规则约定总结
本文开头，作为结论提出了一些约定的规范做法，这里再做个总结。
- 所有 Python 源文件的文件头，加上
# -*- coding: UTF-8 -*-或# coding: u8 - 所有源文件保存为 UTF-8 编码
- 代码中所有带有中文的字面值字符串，都使用 Unicode 字符串，如：
# -*- coding: UTF-8 -*-
myStr = u'测试中文'
print myStr
print type(myStr)
print len(myStr)
- 从文本文件中读取的内容，如果需要对其中的字符做编辑处理，需要在打开文件时指定编码，或者当做字节流加载后，转为 Unicode 字符串处理。
# -*- coding: UTF-8 -*-
# 打开文件并读取内容
fp = open('file.txt', 'r')
data = fp.read()
print type(data)
# 根据数据实际的编码格式，转换为 Unicode 字符串，再进行使用
s = data.decode('gbk')
print type(s)
print s
- 将字符串内容保存到文件时，先指定要使用的编码，将编码后得到的数据写入文件
# -*- coding: UTF-8 -*-
s = u'我的中文测试' # 带有中文的 Unicode 字符串
data = s.encode('UTF-8') # 使用指定编码，转成数据
# 将数据写入文件
fp = open('file.txt', 'w')
fp.write(data)
fp.close()
五、案例
Requests 是 Python 中一个强大的的网络库，在写一些爬虫工具时会用到。在网络请求完成后，会拿到一个 response 对象。一般情况，通过 response.text 返回的 Unicode 字符串就可以满足要求。
最近写的一个爬虫工具，就在编码部分出了问题。网站一部分页面是 UTF-8 编码，另一部分是 GBK 编码。开始的时候并不知道，统一使用 response.text 来做处理，但是发现一些冷僻字出现了乱码。
问题原因
response 同时提供了 content 属性和 text 属性。其中：
-
response.content属性类型为 str，保存着原始内容的字节流 -
response.text属性类型为 unicode，是从response.content内容解码得到的
网站的 UTF-8 部分页面，直接用response.text获取没有问题。但是对于 GBK 编码的那部分页面，恰巧冷僻字比较多，Requests 库在解码得到response.text的时候，内部使用了不完善的中文字符集，个人猜测可能是 GB2312 之类的，导致一些字符不能识别，需要用 GBK 解码解决。
解决方法
# 对于确定返回内容为 GBK 编码的情况，通过 GBK 解码，得到原始的 Unicode
response.content.decode('GBK')
参考链接：
Python中的str与unicode处理方法
Python编码格式说明及转码函数encode和decode的使用
（完）
