Python 关于 encode与decode 中文乱码问题

字符串在Python内部的表示是unicode编码，因此，在做编码转换时，通常需要以unicode作为中间编码，即先将其他编码的字符串解码（decode）成unicode，再从unicode编码（encode）成另一种编码。

decode的作用是将其他编码的字符串转换成unicode编码，如str1.decode('gb2312')，表示将gb2312编码的字符串str1转换成unicode编码。

encode的作用是将unicode编码转换成其他编码的字符串，如str2.encode('gb2312')，表示将unicode编码的字符串str2转换成gb2312编码。

因此，转码的时候一定要先搞明白，字符串str是什么编码，然后decode成unicode，然后再encode成其他编码

代码中字符串的默认编码与代码文件本身的编码一致。

如：s='中文'

如果是在utf8的文件中，该字符串就是utf8编码，如果是在gb2312的文件中，则其编码为gb2312。这种情况下，要进行编码转换，都需 要先用decode方法将其转换成unicode编码，再使用encode方法将其转换成其他编码。通常，在没有指定特定的编码方式时，都是使用的系统默 认编码创建的代码文件。

如果字符串是这样定义：s=u'中文'

则该字符串的编码就被指定为unicode了，即python的内部编码，而与代码文件本身的编码无关。因此，对于这种情况做编码转换，只需要直接使用encode方法将其转换成指定编码即可。

如果一个字符串已经是unicode了，再进行解码则将出错，因此通常要对其编码方式是否为unicode进行判断：

isinstance(s, unicode) #用来判断是否为unicode

用非unicode编码形式的str来encode会报错

如何获得系统的默认编码？

#!/usr/bin/env python
#coding=utf-8
import sys
print sys.getdefaultencoding()

该段程序在英文WindowsXP上输出为：ascii

在某些IDE中，字符串的输出总是出现乱码，甚至错误，其实是由于IDE的结果输出控制台自身不能显示字符串的编码，而不是程序本身的问题。

如在UliPad中运行如下代码：

s=u"中文"
print s

会提示：UnicodeEncodeError: 'ascii' codec
can't encode characters in position 0-1: ordinal not in
range(128)。这是因为UliPad在英文WindowsXP上的控制台信息输出窗口是按照ascii编码输出的（英文系统的默认编码是
ascii），而上面代码中的字符串是Unicode编码的，所以输出时产生了错误。

将最后一句改为：print s.encode('gb2312')

则能正确输出“中文”两个字。

若最后一句改为：print s.encode('utf8')

则输出：\xe4\xb8\xad\xe6\x96\x87，这是控制台信息输出窗口按照ascii编码输出utf8编码的字符串的结果。

unicode(str,'gb2312')与str.decode('gb2312')是一样的，都是将gb2312编码的str转为unicode编码

使用str.__class__可以查看str的编码形式

>>>>>
groups.google.com/group/python-cn/browse_thread/thread/be4e4e0d4c3272dd
-----
python是个容易出现编码问题的语言。所以，我按照我的理解写下下面这些文字。 
=首先，要了解几个概念。= 
*字节：计算机数据的表示。8位二进制。可以表示无符号整数：0-255。下文，用“字节流”表示“字节”组成的串。 
*字符：英文字符“abc”，或者中文字符“你我他”。字符本身不知道如何在计算机中保存。下文中，会避免使用“字符串”这个词，而用“文本”来表 
示“字符”组成的串。 
*编码（动词）：按照某种规则（这个规则称为：编码（名词））将“文本”转换为“字节流”。（在python中：unicode变成str） 
*解码（动词）：将“字节流”按照某种规则转换成“文本”。（在python中：str变成unicode） 
**实际上，任何东西在计算机中表示，都需要编码。例如，视频要编码然后保存在文件中，播放的时候需要解码才能观看。 
unicode：unicode定义了，一个“字符”和一个“数字”的对应，但是并没有规定这个“数字”在计算机中怎么保存。（就像在C中，一个整数既 
可以是int，也可以是short。unicode没有规定用int还是用short来表示一个“字符”） 
utf8：unicode实现。它使用unicode定义的“字符”“数字”映射，进而规定了，如何在计算机中保存这个数字。其它的utf16等都是 
unicode实现。 
gbk：类似utf8这样的“编码”。但是它没有使用unicode定义的“字符”“数字”映射，而是使用了另一套的映射方法。而且，它还定义了如何在 
计算机中保存。

=python中的encode，decode方法= 
首先，要知道encode是 unicode转换成str。decode是str转换成unicode。 
下文中，u代表unicode类型的变量，s代表str类型的变量。 
u.encode('...')基本上总是能成功的，只要你填写了正确的编码。就像任何文件都可以压缩成zip文件。 
s.decode('...')经常是会出错的，因为str是什么“编码”取决于上下文，当你解码的时候需要确保s是用什么编码的。就像，打开zip文 
件的时候，你要确保它确实是zip文件，而不仅仅是伪造了扩展名的zip文件。 
u.decode(),s.encode()不建议使用，s.encode相当于s.decode().encode()首先用默认编码（一般是 
ascii）转换成unicode在进行encode。

=关于#coding=utf8= 
当你在py文件的第一行中，写了这句话，并确实按照这个编码保存了文本的话，那么这句话有以下几个功能。 
1.使得词法分析器能正常运作，对于注释中的中文不报错了。 
2.对于u"中文"这样literal string能知道两个引号中的内容是utf8编码的，然后能正确转换成unicode 
3."中文"对于这样的literal string你会知道，这中间的内容是utf8编码，然后就可以正确转换成其它编码或unicode了。

没有写完，先码那么多字，以后再来补充，这里不是wiki，太麻烦了。

>>>>>
>>>>>
=Python编码和Windows控制台= 
我发现，很多初学者出错的地方都在print语句，这牵涉到控制台的输出。我不了解linux，所以只说控制台的。 
首先，Windows的控制台确实是unicode（utf16_le编码）的，或者更准确的说使用字符为单位输出文本的。 
但是，程序的执行是可以被重定向到文件的，而文件的单位是“字节”。 
所以，对于C运行时的函数printf之类的，输出必须有一个编码，把文本转换成字节。可能是为了兼容95，98， 
没有使用unicode的编码，而是mbcs（不是gbk之类的）。 
windows的mbcs，也就是ansi，它会在不同语言的windows中使用不同的编码，在中文的windows中就是gb系列的编码。 
这造成了同一个文本，在不同语言的windows中是不兼容的。 
现在我们知道了，如果你要在windows的控制台中输出文本，它的编码一定要是“mbcs”。 
对于python的unicode变量，使用print输出的话，会使用sys.getfilesystemencoding()返回的编码，把它变成str。 
如果是一个utf8编码str变量，那么就需要 print s.decode('utf8').encode('mbcs') 
最后，对于str变量，file文件读取的内容，urllib得到的网络上的内容，都是以“字节”形式的。 
它们如果确实是一段“文本”，比如你想print出来看看。那么你必须知道它们的编码。然后decode成unicode。 
如何知道它们的编码： 
1.事先约定。（比如这个文本文件就是你自己用utf8编码保存的） 
2.协议。（python文件第一行的#coding=utf8，html中的等） 
2.猜。

>>>>>

> 这个非常好，但还不是很明白 
> 将“文本”转换为“字节流”。（在python中：unicode变成str）

"最后，对于str变量，file文件读取的内容，urllib得到的网络上的内容，都是以“字节”形式的。" 
虽然文件或者网页是文本的,但是在保存或者传输时已经被编码成bytes了,所以用"rb"打开的file和从socket读取的流是基于字节的. 
"它们如果确实是一段“文本”，比如你想print出来看看。那么你必须知道它们的编码。然后decode成unicode。" 
这里的加引号的"文本",其实还是字节流(bytes),而不是真正的文本(unicode),只是说明我们知道他是可以解码成文本的. 
在解码的时候,如果是基于约定的,那就可以直接从指定地方读取如BOM或者python文件的指定coding或者网页的meta,就可以正确解码, 
但是现在很多文件/网页虽然指定了编码,但是文件格式实际却使用了其他的编码(比如py文件指定了coding=utf8,但是你还是可以保存成ansi--记事本的默认编码),这种情况下真实的编码就需要去猜了 
解码了的文本只存在运行环境中,如果你需要打印/保存/输出给数据库/网络传递,就又需要一次编码过程,这个编码与上面的编码没有关系,只是依赖于你的选择,但是这个编码也不是可以随便选择的,因为编码后的bytes如果又需要传递给其他人/环境,那么如果你的编码也不遵循约定,又给下一个人/环境造成了困扰,于是递归之~~~~ 
>>>>>

> 主要有一条非常容易误解：

> 一般人会认为Unicode（广义）统一了编码，其实不然。Unicode不是唯一的编码，而一大堆编码的统称。但是Windows下Unicode 
> （狭义）一般特指UCS2，也就是UTF-16/LE

unicode作为字符集(ucs)是唯一的,编码方案(utf)才是有很多种

>>>>>
将字符与字节的概念区分开来是很重要的。Java 一直就是这样，Python也开始这么做了，Ruby 貌似还在混乱当中。
>>>>>
>>>>>
我也说两句。我对编码的研究相对比较深一些。因为工作中也经常遇到乱码，于是在05年，对编码专门做过研究，并在公司刊物上发过文章，最后形成了一个教材，每年在公司给新员工都讲一遍。于是项目中遇到乱码的问题就能很快的定位并解决了。 
理论上，从一个字符到具体的编码，会经过以下几个概念。 
字符集（Abstract character repertoire） 
编码字符集（Coded character set） 
字符编码方式（Character encoding form） 
字符编码方案（Character encoding scheme ） 
字符集：就算一堆抽象的字符，如所有中文。字符集的定义是抽象的，与计算机无关。 
编码字符集：是一个从整数集子集到字符集抽象元素的映射。即给抽象的字符编上数字。如gb2312中的定义的字符，每个字符都有个整数和它对应。一个整数只对应着一个字符。反过来，则不一定是。这里所说的映射关系，是数学意义上的映射关系。编码字符集也是与计算机无关的。unicode字符集也在这一层。 
字符编码方式：这个开始与计算机有关了。编码字符集的编码点在计算机里的具体表现形式。通俗的说，意思就是怎么样才能将字符所对应的整数的放进计算机内存，或文件、或网络中。于是，不同人有不同的实现方式，所谓的万码奔腾，就是指这个。gb2312，utf-8,utf-16,utf-32等都在这一层。 
字符编码方案：这个更加与计算机密切相关。具体是与操作系统密切相关。主要是解决大小字节序的问题。对于UTF-16和UTF-32 
编码，Unicode都支持big-endian 和 little-endian两种编码方案。 
一般来说，我们所说的编码，都在第三层完成。具体到一个软件系统中，则很复杂。 
浏览器－apache－tomcat（包括tomcat内部的jsp编码、编译，文件读取）－数据库之间，只要存在数据交互，就有可能发生编码不一致，如果在读取数据时，没有正确的decode和encode，出现乱码就是家常便饭了。