python2.x中处理中文,是一件头疼的事情。网上写这方面的文章,测次不齐,而且都会有点错误,所以在这里打算自己总结一篇文章。
我也会在以后学习中,不断的修改此篇博客。
这里假设读者已有与编码相关的基础知识,本文不再再次介绍,包括什么是utf-8,什么是unicode,它们之间有什么关系。
str与字节码
首先,我们完全不谈unicode。
1
|
s
=
"人生苦短"
|
s是个字符串,它本身存储的就是字节码。那么这个字节码是什么格式的?
如果这段代码是在解释器上输入的,那么这个s的格式就是解释器的编码格式,对于windows的cmd而言,就是gbk。
如果将段代码是保存后才执行的,比如存储为utf-8,那么在解释器载入这段程序的时候,就会将s初始化为utf-8编码。
unicode与str
我们知道unicode是一种编码标准,具体的实现标准可能是utf-8,utf-16,gbk ……
python 在内部使用两个字节来存储一个unicode,使用unicode对象而不是str的好处,就是unicode方便于跨平台。
你可以用如下两种方式定义一个unicode:
1
2
|
s1
=
u
"人生苦短"
s2
=
unicode
(
"人生苦短"
,
"utf-8"
)
|
encode与decode
在python中的编码解码是这样的:
所以我们可以写这样的代码:
1
2
3
4
5
6
7
8
9
|
# -*- coding:utf-8 -*-
su
=
"人生苦短"
# : su是一个utf-8格式的字节串
u
=
s
.
decode
(
"utf-8"
)
# : s被解码为unicode对象,赋给u
sg
=
u
.
encode
(
"gbk"
)
# : u被编码为gbk格式的字节串,赋给sg
print
sg
# 打印sg
|
但是事实情况要比这个复杂,比如看如下代码:
1
2
|
s
=
"人生苦短"
s
.
encode
(
'gbk'
)
|
看!str也能编码,(事实上unicode对象也能解码,但是意义不大)
这样为什么可以?看上图的编码流程的箭头,你就能想到原理,当对str进行编码时,会先用默认编码将自己解码为unicode,然后在将unicode编码为你指定编码。
这就引出了python2.x中在处理中文时,大多数出现错误的原因所在:python的默认编码,defaultencoding是ascii
看这个例子:
1
2
3
|
# -*- coding: utf-8 -*-
s
=
"人生苦短"
s
.
encode
(
'gbk'
)
|
上面的代码会报错,错误信息:UnicodeDecodeError: ‘ascii’ codec can’t decode byte ……
因为你没有指定defaultencoding,所以它其实在做这样的事情:
1
2
3
|
# -*- coding: utf-8 -*-
s
=
"人生苦短"
s
.
decode
(
'ascii'
)
.
encode
(
'gbk'
)
|
设置defaultencoding
设置defaultencoding的代码如下:
1
2
|
reload
(
sys
)
sys
.
setdefaultencoding
(
'utf-8'
)
|
如果你在python中进行编码和解码的时候,不指定编码方式,那么python就会使用defaultencoding。
比如上一节例子中将str编码为另一种格式,就会使用defaultencoding。
1
|
s
.
encode
(
"utf-8"
)
等价于
s
.
decode
(
defaultencoding
)
.
encode
(
"utf-8"
)
|
再比如你使用str创建unicode对象时,如果不说明这个str的编码格式,那么程序也会使用defaultencoding。
1
|
u
=
unicode
(
"人生苦短"
)
等价于
u
=
unicode
(
"人生苦短"
,
defaultencoding
)
|
默认的defaultcoding:ascii是许多错误的原因,所以早早的设置defaultencoding是一个好习惯。
文件头声明编码的作用。
这要感谢这篇博客关于python文件头部分知识的讲解。
顶部的:# -*- coding: utf-8 -*-目前看来有三个作用。
- 如果代码中有中文注释,就需要此声明
- 比较高级的编辑器(比如我的emacs),会根据头部声明,将此作为代码文件的格式。
- 程序会通过头部声明,解码初始化 u”人生苦短”,这样的unicode对象,(所以头部声明和代码的存储格式要一致)
关于requests库
requests是一个很实用的Python HTTP客户端库,编写爬虫和测试服务器响应数据时经常会用到。
其中的Request对象在访问服务器后会返回一个Response对象,这个对象将返回的Http响应字节码保存到content属性中。
但是如果你访问另一个属性text时,会返回一个unicode对象,乱码问题就会常常发成在这里。
因为Response对象会通过另一个属性encoding来将字节码编码成unicode,而这个encoding属性居然是responses自己猜出来的。
官方文档:
text
Content of the response, in unicode.If Response.encoding is None, encoding will be guessed using chardet.
The encoding of the response content is determined based solely on HTTP headers, following RFC 2616 to the letter. If you can take advantage of non-HTTP knowledge to make a better guess at the encoding, you should set r.encoding appropriately before accessing this property.
所以要么你直接使用content(字节码),要么记得把encoding设置正确,比如我获取了一段gbk编码的网页,就需要以下方法才能得到正确的unicode。
1
2
3
4
5
6
|
import
requests
url
=
"http://xxx.xxx.xxx"
response
=
requests
.
get
(
url
)
response
.
encoding
=
'gbk'
print
response
.
text
|
不仅仅要原理,更要使用方法!
如果是早期的我写博客,那么我一定会写这样的例子:
如果现在的文件编码为gbk,然后文件头为:# -*- coding: utf-8 -*-,再将默认编码设置为xxx,那么如下程序的结果会是……
这就类似于,当年学c的时候,用各种优先级,结合性,指针来展示自己水平的代码。
实际上这些根本就不实用,谁会在真正的工作中写这样的代码呢?我在这里想谈谈实用的处理中文的python方法。
基本设置
主动设置defaultencoding。(默认的是ascii)
代码文件的保存格式要与文件头部的# coding:xxx一致
如果是中文,程序内部尽量使用unicode,而不用str
关于打印
你在打印str的时候,实际就是直接将字节流发送给shell。如果你的字节流编码格式与shell的编码格式不相同,就会乱码。
而你在打印unicode的时候,系统自动将其编码为shell的编码格式,是不会出现乱码的。
程序内外要统一
如果说程序内部要保证只用unicode,那么在从外部读如字节流的时候,一定要将这些字节流转化为unicode,在后面的代码中去处理unicode,而不是str。
1
2
3
4
5
|
with
open
(
"test"
)
as
f
:
for
i
in
f
:
# 将读入的utf-8字节流进行解码
u
=
i
.
decode
(
'utf-8'
)
.
.
.
.
|
如果把连接程序内外的这段数据流比喻成通道的的话,那么与其将通道开为字节流,读入后进行解码,不如直接将通道开为unicode的。
1
2
3
4
5
|
# 使用codecs直接开unicode通道
file
=
codecs
.
open
(
"test"
,
"r"
,
"utf-8"
)
for
i
in
file
:
print
type
(
i
)
# i的类型是unicode的
|