最近在socket中遇到了一个偶现bug，那就是与websocket建立连接后，进行数据传输后，在linux平台的终端下用
socket_read()读取出来后，再用echo
打印出来的就是乱码。因为我做的只是一个数据中转，而另一端的C++则是用字节判断，而不是用字符串判断，而浏览器端的编码是utf-8，不知道为何会这样。这个问题在这个项目于结束后，终于有时间来纠结这个问题。当然，在一起的纠结的还有python的编码。这次就先说一说python的编码问题。
python编码问题的继续
之前的一篇文章对一些基本的python编码问题做了比较表面的解释，有兴趣的可以点击这里去看一下我对python编码的基础理解。好了，下面先提出我碰到的问题。
一个需要细思的例子
# windows 10 powershell
>>> u'知乎'
u'\u77e5\u4e4e'
>>> u'知乎'.encode('utf-8')
'\xe7\x9f\xa5\xe4\xb9\x8e'
>>> u'知乎'.encode('gbk')
'\xd6\xaa\xba\xf5'
>>> '知乎' #这个地方的编码被power shelll自己处理了
'\xd6\xaa\xba\xf5'
# sublime 3 REPL python
>>> u'知乎'
u'\u77e5\u4e4e'
>>> u'知乎'.encode('utf-8')
'\xe7\x9f\xa5\xe4\xb9\x8e'
>>> u'知乎'.encode('gbk')
'\xd6\xaa\xba\xf5'
>>> '知乎' #这个地方的编码被REPL自己处理了
'\xe7\x9f\xa5\xe4\xb9\x8e'
在上面两个例子的最后一行，可以看出在不同的shell下，这两个汉字的说明在解释器解释这个汉字字符串的时候是不同的。这个问题在stackoverflow,上有很好的解释。
解释 进度1
在进一步进行解释前，需要对 python 中的 '' 和 u'' 进行详细的解释，在这个例子中我们就以 鐭ヤ箮 这个词来进行解释。
#windows 10 powershell
>>>import sys
>>>sys.stdout.encoding
'cp936'
>>>'a'
'a'
>>>'鐭ヤ箮'
'\xe7\x9f\xa5\xe4\xb9\x8e'
>>> u'鐭ヤ箮'
u'\u942d\u30e4\u7bae'
>>>u'\u942d\u30e4\u7bae'.encode('ascii')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)
>>>u'\u0047'.encode('ascii')
G上面的这个例子，如果仔细思考的话，是可以引申出很多问题的。
第一个问题，汉字这个汉字是如何显示到屏幕上的，解释器又是如何处理这个汉字的，才使得最后解析出来的是一个点阵获取码。首先无论是怎样的方式输出的汉字（复制粘贴也好，直接用输入法也好），机器最终都是以点阵获取码(就是一段特殊的16进制数字)的形式去调用所拥有的点阵库，点阵库中的每一个汉字有他自己的特殊的点阵方式。当然这里的是点阵字库而不是矢量字库。
第二个问题是如果说python2中默认的编码方式是ascii，那么非英文字符按理来说是不能编码的 呀（因为ascii中只有英文字符）。其实这个说法本身是没有错的，而非英文字符还是要显示的，这个时候python就对这些非英文字符进行了不规范的处理，它会使用sys.stdout.encoding所显示的编码方案对当前显示的汉字进行编码，然后将这个汉字编码后的存储码输出而来。
第三个问题是 u'' 进行了什么样的处理。这个问题和第二个问题还是很有联系的，首先 u'' 在 python2 中表示的是对应字符的 unicode 码的形式，至于过程，则是使用当前的终端的编码方案对字符进行（decode）解码，然后再将解码后的所对应的 unicode 码显示出来。也就是说，u'' 这种形式，其实已经对字符进行了解码，所以如果采用 ascii 这种编码方案对超出编码范围的字符进行编码的话，是会出现上面所示的错误的。
解释 进度2
#the code below is under a file.py
#coding: utf-8
import sys
ed = sys.stdout.encoding
print '知乎'.decode('utf-8').encode(ed)在进度1中，对python解释器对"", u""进行了比较详细的解释，我想大概也能解释了为什么有时候即使在文件头又coding:xxx这样的声明还是会出现各种各样的乱码。之所以会出现这样的乱码是因为在不同的终端下，ed是不一样的，而文件的编码保存方式却又是固定的，我觉得这样的设计不能说坏，但是至少现在来看确实不算是好的设计，在python3中到是在这方面进行了很大程度的改进，我觉得在这方面实现起来确实还不错。
回到话题，上面的这个文件，无论你在哪个平台下运行他都会呈现它原本的汉字。相反如果用下面这个样子的东西去测试，你也许就会发现所出出现的问题了。
print '知乎'尾声
python2的编码问题其实早已经出现好久，一开始我只是解决了乱码的问题，后来在各种终端下测试的时候，发现了这样那样的问题，我觉得这真的还是蛮胃疼的，每次都得直接google错误，真的不是一个长久之计，遂花时间研究了一下编码。每次重新研究一次，总是会得到新的体验。
编码这个范畴真的还是蛮大的，有幸能在早期纠结于此。
pep-0263
这样的声明#coding: utf-8的意义，于此。
This PEP proposes to introduce a syntax to declare the encoding of
a Python source file. The encoding information is then used by the Python parser to interpret the file using the given encoding. Most notably this enhances the interpretation of Unicode literals in the source code and makes it possible to write Unicode literals using e.g. UTF-8 directly in an Unicode aware editor.
