Question

Python2.7 中文字符编码，使用Unicode时，选择什么编码格式

Answer 1

关于编码和乱码的问题，我简单讲一下。
通常问这类问题的人是混淆了若干个不同的概念，并且他们自己也没有意识到自己混淆了这些概念的。
终端显示字符的编码（windows下终端是cmd，linux下是各种terminal，远程登录是putty或者xshell）
shell环境的编码。比如中文版windows用的是gbk（向下兼容gb2312），大多数linux发行版使用的是utf-8（LANG=zh_CN.UTF-8）。
文本文件的编码。这个通常取决于你的编辑器，而且有的编辑器支持多种编码的话，你可以在文本开头位置指定编辑器使用特定编码。比如# -*- coding: utf8 -*-，vim看到这行会默认将这个脚本认定为utf-8兼容编码格式。
应用程序的内部编码。一个字符串，作为数据只是一个字节数组，但是作为字符的数组，就有一个解析方式。java和python的内部字符编码是utf-16，python和java都支持用不同的编码来对字节数组进行decode来得到字符数组。

拿题主的问题来解释一下。
我在ubuntu kylin中文环境下默认terminal中做了同样的实验，但是结果和题主恰好相反：

看见没有？
题主和我都没有说谎，这是为什么呢？
因为
unicode("汉字","gb2312")

这坨代码的含义实际上是：将这里显示的这坨看上去像“汉字”的东西，用gb2312解码，转换为unicode字符串。unicode("汉字","utf-8")类似，只不过是用utf-8解码，转成unicode字符串。
（注：这里涉及到两个概念——unicode字符集和utf-8编码——很多时候会用混淆，一个字符集表示一堆符号，而一种编码是用二进制表示这个字符集的一种编码方式。同样是unicode字符集，可以有utf-8、utf-16、utf-32等等编码方式。）
那这里显示的看上去像“汉字”的，tmd的到底是个什么东西？
如果是在我的环境下，也就是linux utf-8环境下一个utf-8显示终端，能显示成“汉字”的这坨东西，它实际上是以utf-8编码的“汉”字和“字”字两个unicode字符。它们的真实字符值就是u'\u6c49\u5b57'（内码），可以用"汉字".encode("hex")来查看当前终端下(utf-8编码值）的十六进制码。

。所以我的命令是，
。所以我的命令是，将'e6b189e5ad97'这坨字节数组，转换为unicode的字符数组。——结果毫无难度，没有错误，因为它本来就是utf-8编码，所以能够正常作为unicode字符解码。
但是unicode("汉字", "gb2312")就不一样了，这个命令等同于“将'e6b189e5ad97'这坨东西，用gb2312编码方式来解码成字符”，但是实际上由于编码空间并不兼容，使用gb2312编码方式无法解码这么一坨奇葩的数据，所以葛屁了。
在题主的环境下，因为系统终端和默认文件编码都是GBK，所以这个数实际上是

这个实际上是gbk(兼容gb2312)的字符“汉字”的真实字节数组。
这个实际上是gbk(兼容gb2312)的字符“汉字”的真实字节数组。
所以对这坨数据做unicode("汉字","utf8")会失败——因为不管你怎么想，虽然看上去是一样，但是实际上不是同一坨东西啊！
题主现在弄了一个文件，在开始加上了
# -*- coding: utf8 -*-
这下编辑器看到了，知道这文件是utf-8的了。所以编辑器对读入的一坨坨字节用utf-8来解码，对于输出到磁盘的汉字也用utf-8来编码。所以你在文件里面看到的看上去像“汉字”的东西，就和第一种情况下想同了，当然代码就跑得通。
顺便说一下，如果编辑器无视行首这行编码声明，或者编辑器无法支持utf-8格式，那么你弄好的文件在那个编辑器下就会显示乱码，多么简单的道理啊。

所以，要能够正常的显示中文（或者其他什么乱七八糟奇葩的多字节文字），以下条件缺一不可：

终端和环境的编码一致（本机通常是一致的，不一致常常出现在远程登录）；如果不一致就需要有编辑器或者文本阅读器做一个兼容两者的转换。
编辑器能够认识文本编码
系统拥有能显示这种字符的字体。

这也就是我为什么一直反对在程序文本中使用除ascii之外的所有编码字符的原因。环境太复杂了，绕开问题远比解决问题轻松。