字符、字符集、编码，以及它们python中会遇到的一些问题（下）

在看了很多的博客文章之后，总结整理得到了以下文章，非常感谢这些无私奉献的博主！

文章末尾有本文引用的文章的链接，如果有漏掉的文章引用，可以发邮件联系我，随后再次附上链接！

侵删！！！

这一部分是下篇，主要讲的是编码部分，以及在python中会遇到的一些编码问题，偏向于实际应用一点。

上篇介绍了字符、字符集的一些概念，以及他们在python中的一些简单的代码示例，偏向于概念。

上篇地址：http://www.cnblogs.com/echo-coding/p/7435118.html

这绝对是个源远流长的大坑，对于新手来说恶心致死（尤其是windows）...........

二、decode、encode（python编码）

上面介绍了字符、字符集和字符编码，为这一小结做了准备。

一些重要概念：

系统编码：默认编码，正常情况下window系统默认是gbk,Linux系统默认是utf-8，可用locale.getdefaultlocale()和locale.setdefaultlocale()来控制，与encode有关

用python自带的locale模块来检测命令行的默认编码（也就是系统的编码）和设置命令行编码：

1. import locale
2. #get coding type
3. print locale.getdefaultlocale()
4. ('zh_CN', 'cp936')
5. #set coding type
6. locale.setlocale(locale.LC_ALL, locale='zh_CN.GB2312')
7. print locale.getlocale()
8. ('zh_CN', 'gb2312')

表明当前系统的内部编码是cp936，近似于GBK。实际上中文XP和WIN7的系统内部编码都是cp936（GBK）。

tips：linux系统下系统默认编码为utf8编码，window默认编码为gbk编码

python编码：指python内设置的解码方式。如果不设定的话，python默认的是ascii解码方式。如果python源代码文件中不出现中文的话，这个地方怎么设定应该不会问题。

1. #查看python编码
2. import sys
3. sys.getdefaultencoding()
4. #结果
5. 'ascii'
6. #更改python编码
7. sys.setdefaultencoding('utf-8')

永久地将python默认采用的编码设置为utf-8：在python的Lib\site-packages文件夹下新建一个sitecustomize.py，内容为：

1. # encoding=utf8
2. import sys
3. reload(sys)
4. sys.setdefaultencoding('utf8')

此时重启python解释器，执行sys.getdefaultencoding()，发现编码已经被设置为utf8的了，多次重启之后，效果相同，这是因为系统在python启动的时候，自行调用该文件，设置系统的默认编码，而不需要每次都手动的加上解决代码，属于一劳永逸的解决方法。

文件编码：文本的编码方式，sys.getfilesystemencoding()

读写文件：

内置的open()方法打开文件时，read()读取的是str，读取后需要使用正确的编码格式进行decode()（变成unicode）。write()写入时，如果参数是unicode，则需要使用你希望写入的编码进行encode()，如果是其他编码格式的str，则需要先用该str的编码进行decode()， 转成unicode后再使用写入的编码进行encode()。如果直接将unicode作为参数传入write()方法，Python将先使用源代码文件声明的字符编码进行编码然后写入。

1. # coding: UTF-8
2. f = open('test.txt')
3. s = f.read()
4. f.close()
5. print type(s) # <type 'str'>
6. # 已知是GBK编码，解码成unicode
7. u = s.decode('GBK')
8. f = open('test.txt', 'w')
9. # 编码成UTF-8编码的str
10. s = u.encode('UTF-8')
11. f.write(s)
12. f.close()

另外，模块codecs提供了一个open()方法，可以指定一个编码打开文件，使用这个方法打开的文件读取返回的将是unicode。写入时，如果参数是unicode，则使用open()时指定的编码进行编码后写入；如果是str，则先根据源代码文件声明的字符编码，解码成unicode后再进行前述操作。相对内置的open()来说，这个方法比较不容易在编码上出现问题。使用codecs直接开unicode通道。

1. # coding: GBK
2. import codecs
3. f = codecs.open('test.txt', encoding='UTF-8')
4. u = f.read()
5. f.close()
6. print type(u) # <type 'unicode'>
7. f = codecs.open('test.txt', 'a', encoding='UTF-8')
8. # 写入unicode
9. f.write(u)
10. # 写入str，自动进行解码编码操作
11. # GBK编码的str
12. s = '汉'
13. print repr(s) # '\xba\xba'
14. # 这里会先将GBK编码的str解码为unicode再编码为UTF-8写入
15. f.write(s)
16. f.close()

python代码中的编码（代码编码）：

1、python代码中的字符串在未被指定编码的情况下，默认编码与代码文件本身的编码一致。举个例子：str = '中文'这个字符串，如果是在utf8编码的代码文件中，该字符串就是utf8编码；如果是在gb2312的文件中，该字符串就是gb2312编码。那么代码文件本身的编码怎么知道呢？

（1）自己指定代码文件的编码：在代码文件的头部加上"#-*- coding:utf-8 -*-"来声明该代码文件为utf-8编码。此时未被指定编码的字符串的编码都变成了utf-8。

顶部的:# -*- coding: utf-8 -*-目前看来有三个作用。

1、如果代码中有中文注释，就需要此声明（否则代码报错，无法解析）

2、比较高级的编辑器（比如我的emacs），会根据头部声明，将此作为代码文件的格式。

3、程序会通过头部声明，解码初始化 u"人生苦短"，这样的unicode对象，（所以头部声明和代码的存储格式要一致）

（2）在没有指定代码文件的编码时，创建代码文件时使用的是python默认采用的编码（一般来说是ascii码，在windows中实际保存为cp936（GBK）编码）。通过sys.getdefaultencoding()和sys.setdefaultencoding('...')来获取和设置该默认编码。

终端输入输出编码：sys.stdin.encoding，sys.stdout.encoding，必须与locale编码保持一致，才能print出正确str。

print会根据sys.stdout.encoding再转一次码。

1. sys.stdout.encoding
2. 'cp936'
3. '严'
4. '\xe4\xb8\xa5'
5. print u'严'
6. 严
7. print u'严'.encode('utf-8')
8. 涓
9. print u'严'.encode('gbk')
10. 严
11. u'严'.encode('utf-8')
12. '\xe4\xb8\xa5'
13. u'涓'.encode('gbk')
14. '\xe4\xb8'

print打印显示的过程

Python2.7中调用print打印var 变量时，操作系统会对var做一定的字符处理：如果var是str类型的变量，则直接将var变量交付给终端进行显示；如果var变量是unicode类型，则操作系统首先将var编码成str类型的对象（编码格式取决于stdout的编码格式），然后再交由终端进行显示。在终端显示时，如果str类型的变量的编码方式和终端设置的编码方式不一致，很可能会出现乱码问题。

还有就是print字符串的时候出现的编码错误问题。原因在于sys.stdout.encoding。print 后面跟的字符串对象的编码类型一定要与sys.stdout.encoding所指定的一致，不一致就会出现编码错误。

console不能正常显示中文，console的编码是由操作系统决定的（windows环境下）；

我的操作系统是win8中文版（GBK）

console的编码决定了sys.stdout.encoding的取值，sys.stdout.encoding='cp936'

decode && encode ：

decode：解码（从其他方向（utf-8，gbk等.......）到unicode）

1. #gbk就是源码的编码方式，解码成了unicode
2. '\xa1\xb0'.decode('gbk') #解码
3. u'\u201c' #unicode

encode：编码（从unicode到其他方向（utf-8，gbk等.......））

1. u'中文'.encode('utf-8')
2. '\xe4\xb8\xad\xe6\x96\x87'

简单来说就是，你用的什么规则去编码，你就得用这个规则去解码，否则，要不然就乱码了，要不然就直接报错，没法解啊！！！

但问题就是呢，系统有系统的默认编码格式，你文件明明是utf-8的编码，他偏偏用gbk方式去解码，那要不然就直接解不了，要不然就是牛头不对马嘴呗。

关于打印：

你在打印str的时候，实际就是直接将字节流发送给shell。如果你的字节流编码格式与shell的编码格式不相同，就会乱码。

而你在打印unicode的时候，系统自动将其编码为shell的编码格式，是不会出现乱码的。

其他命令：

文件系统的编码：sys.getfilesystemencoding()

终端的输入编码：sys.stdin.encoding

终端的输出编码：sys.stdout.encoding

一些建议：

1. 使用字符编码声明，并且同一工程中的所有源代码文件使用相同的字符编码声明；

2. 抛弃str，全部使用unicode：按引号前先按一下u，这么做可以减少90%的编码问题；

3. 使用codecs.open()替代内置的open()；

4. 绝对需要避免使用的字符编码：MBCS/DBCS和UTF-16；

5、主动设置defaultencoding。（默认的是ascii）；

6、代码文件的保存格式要与文件头部的# coding:xxx一致。

其他：

python 3和2很大区别就是python本身改为默认用unicode编码，字符串不再区分"abc"和u"abc", 字符串"abc"默认就是unicode，不再代表本地编码。

python2.7以后不用setdefaultencoding了，这两个（声明头部和setdefaultencoding）是没有区别的

这两个作用不一样：

1. # coding:utf-8 作用是定义源代码的编码。如果没有定义, 此源码中是不可以包含中文字符串的；

2. sys.getdefaultencoding() 是设置默认的string的编码格式。

问题的根源：Python2 中的 string

Python 为了让其语法看上去简洁好用，做了很多 tricky 的事情，混淆 byte string 和 text string 就是其中一例。

在 Python 里，有三大类 string 类型，unicode（text string），str（byte string，二进制数据），basestring，是前两者的父类。

其实，在语言设计领域，一串字节（sequences of bytes）是否应该当做字符串（string）一直是存在争议的。我们熟知的 Java 和 C# 投了反对票，而 Python 则站在了支持者的阵营里。其实我们在很多情况下，给文本做的操作，比如正则匹配、字符替换等，对于字节来说是用不着的。而 Python 认为字节就是字符，所以他们俩的操作集合是一致的。

然后进一步的，Python 会在必要的情况下，尝试对字节做自动类型转换，例如，在上文中的 ==，或者字节和文本拼接时。如果没有一个编码（encoding），两个不同类型之间的转换是无法进行的，于是，Python 需要一个默认编码。在 Python2 诞生的年代，ASCII 是最流行的（可以这么说吧），于是 Python2 选择了 ASCII。然而，众所周知，在需要需要转换的场景，ASCII 都是没用的（128个字符，够什么吃）。

在历经这么多年吐槽后，Python 3 终于学乖了。默认编码是 Unicode，这也就意味着，做所有需要转换的场合，都能正确并成功的转换。

一个非常困惑不解的地方：

打开ipython，一开始就运行：

1. import sys
2. sys.stdout.encoding
3. 'utf-8'
4. sys.stdin.encoding
5. 'utf-8'
6. print '中文'
7. 中文
8. '中文'
9. '\xe4\xb8\xad\xe6\x96\x87'

完事之后，运行一个py（比如tb.py）文件，然后，神奇的事情发生了：

1. sys.stdin.encoding
2. 'cp936'
3. sys.stdout.encoding
4. 'cp936'
5. print '中文'
6. 濂冲＋
7. '中文'
8. '\xe4\xb8\xad\xe6\x96\x87'

至今无解。。。。。。

参考资料和博客：

http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html

http://blog.chinaunix.net/uid-200142-id-4461708.html

http://www.cnblogs.com/evening/archive/2012/04/19/2457440.html

http://blog.csdn.net/olanlanxiari/article/details/48201231

http://www.jb51.net/article/87739.htm

http://www.cnblogs.com/JohnABC/p/4015504.html

https://m.baidu.com/pu=sz@1321_2001/from=0/bd_page_type=1/ssid=0/uid=0/pu=sz%401321_2001%2Cta%40utouch_1_10.2_3_602/baiduid=F9234C37D7B29B954D4706B9B57F904E/w=0_10_unicode+gbk%E7%BC%96%E7%A0%81/t=wap/l=3/tc?ref=www_utouch&lid=13436452897767398859&order=3&vit=osres&tj=www_normal_3_0_10_title&m=8&srd=1&dict=20&title=%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3-%E5%AD%97%E7%AC%A6%E7%BC%96%E7%A0%81ASCII%2CGB2312%2CGBK%2CUnicode%2CUTF-8-...&sec=21874&di=38f964cdb7b434e5&bdenc=1&nsrc=IlPT2AEptyoA_yixCFOxXnANedT62v3IJBaOMmBXATq5953ybrWxBcNpZCPcMWmTHUOwdoS4ctlMcyju3mRUjMU4f4MscH9hbXjcbPXwehGB

https://m.baidu.com/pu=sz@1321_2001/from=0/bd_page_type=1/ssid=0/uid=0/pu=sz%401321_2001%2Cta%40utouch_1_10.2_3_602/baiduid=F9234C37D7B29B954D4706B9B57F904E/w=0_10_unicode+gbk%E7%BC%96%E7%A0%81/t=wap/l=3/tc?ref=www_utouch&lid=13436452897767398859&order=1&vit=osres&tj=www_normal_1_0_10_title&m=8&srd=1&dict=30&title=ASCIIUnicodeGBK%E5%92%8CUTF-8%E5%AD%97%E7%AC%A6%E7%BC%96%E7%A0%81%E7%9A%84%E5%8C%BA%E5%88%AB%E8%81%94..._%E5%8D%9A%E5%AE%A2%E5%9B%AD&sec=21874&di=265cf5a20e05fae9&bdenc=1&nsrc=IlPT2AEptyoA_yixCFOxXnANedT62v3IEQGG_ytK1DK6mlrte4viZQRASDfaR8qMH6DrvWz0sqdFtXLR_mUp7BJ2qrIwdzZz

http://www.cnblogs.com/work115/p/5924446.html

https://blog.ernest.me/post/python-setdefaultencoding-unicode-bytes