1. 在Python中使用中文
在Python中有两种默认的字符串：str和unicode。在Python中一定要注意区分“Unicode字符串”和“unicode对象”的区别。后面所有的“unicode字符串”指的都是python里的“unicode对象”。
事实上在Python中并没有“Unicode字符串”这样的东西，只有“unicode”对象。一个传统意义上的unicode字符串完全可以用str对象表示。只是这时候它仅仅是一个字节流，除非解码为unicode对象，没有任何实际的意义。
我们用“哈哈”在多个平台上测试，其中“哈”对应的不同编码是：
1． UNICODE (UTF8-16)，
C854；
2． UTF-8， E59388；
3． GBK， B9FE。
1.1
Windows控制台
下面是在windows控制台的运行结果：
可以看出在控制台，中文字符的编码是GBK而不是UTF-16。将字符串s（GBK编码）使用decode进行解码后，可以得到同等的unicode对象。
注意：可以在控制台打印ss并不代表它可以直接被序列化，比如：
向文件直接输出ss会抛出同样的异常。在处理unicode中文字符串的时候，必须首先对它调用encode函数，转换成其它编码输出。这一点对各个环境都一样。
总结：在Python中，“str”对象就是一个字节数组，至于里面的内容是不是一个合法的字符串，以及这个字符串采用什么编码（gbk, utf-8,
unicode）都不重要。这些内容需要用户自己记录和判断。这些的限制也同样适用于“unicode”对象。要记住“unicode”对象中的内容可绝对不一定就是合法的unicode字符串，我们很快就会看到这种情况。
总结：在windows的控制台上，支持gbk编码的str对象和unicode编码的unicode对象。
1.2
Windows
IDLE（在Shell上运行）
在windows下的IDLE中，运行效果和windows控制台不完全一致：
可以看出，对于不使用“u”作标识的字符串，IDLE把其中的中文字符进行GBK编码。但是对于使用“u”的unicode字符串，IDLE居然一样是用了GBK编码，不同的是，这时候每一个字符都是unicode（对象）字符！！此时len(ss)
= 4。
这样产生了一个神奇的问题，现在的ss无法在IDLE中正常显示。而且我也没有办法把ss转换成正常的编码！比如采用下面的方法：
这有可能是因为IDLE本地化做得不够好，对中文的支持有问题。建议在IDLE的SHELL中，不要使用u“中文“