一 了解字符编码知识储备
文本编辑器存取文件的原理（nodepad++，pycharm，word）
#1、打开编辑器就打开了启动了一个进程，是在内存中的，所以，用编辑器编写的内容也都是存放与内存中的，断电后数据丢失 #2、要想永久保存，需要点击保存按钮：编辑器把内存的数据刷到了硬盘上。 #3、在我们编写一个py文件（没有执行），跟编写其他文件没有任何区别，都只是在编写一堆字符而已。
python解释器执行py文件的原理 ，例如python test.py
#第一阶段：python解释器启动，此时就相当于启动了一个文本编辑器 #第二阶段：python解释器相当于文本编辑器，去打开test.py文件，从硬盘上将test.py的文件内容读入到内存中(小复习：pyhon的解释性，决定了解释器只关心文件内容，不关心文件后缀名) #第三阶段：python解释器解释执行刚刚加载到内存中test.py的代码( ps：在该阶段，即真正执行代码时，才会识别python的语法，执行文件内代码，当执行到name="egon"时,会开辟内存
空间存放字符串"egon")
总结python解释器与文件本编辑的异同
#1、相同点：python解释器是解释执行文件内容的，因而python解释器具备读py文件的功能，这一点与文本编辑器一样 #2、不同点：文本编辑器将文件内容读入内存后，是为了显示或者编辑，根本不去理会python的语法，而python解释器将文件内容读入内存后，可不是为了给你瞅一眼python
代码写的啥，而是为了执行python代码、会识别python语法。
二 字符编码介绍
什么是字符编码
计算机要想工作必须通电,即用‘电’驱使计算机干活,也就是说‘电’的特性决定了计算机的特性。电的特性即高低电平(人类从逻辑上将二进制数1对应高电平,二进制数0对应低电平)，
关于磁盘的磁特性也是同样的道理。结论：计算机只认识数字 很明显，我们平时在使用计算机时，用的都是人类能读懂的字符（用高级语言编程的结果也无非是在文件内写了一堆字符），如何能让计算机读懂人类的字符？ 必须经过一个过程： #字符--------（翻译过程）------->数字 #这个过程实际就是一个字符如何对应一个特定数字的标准，这个标准称之为字符编码
字符编码发展
#阶段一：现代计算机起源于美国，最早诞生也是基于英文考虑的ASCII ASCII:一个Bytes代表一个字符（英文字符/键盘上的所有其他字符），1Bytes=8bit，8bit可以表示0-2**8-1种变化，即可以表示256个字符 ASCII最初只用了后七位，127个数字，已经完全能够代表键盘上所有的字符了（英文字符/键盘的所有其他字符），后来为了将拉丁文也编码进了ASCII表，将最高位也占用了 #阶段二:为了满足中文和英文，中国人定制了GBK GBK:2Bytes代表一个中文字符，1Bytes表示一个英文字符 为了满足其他国家，各个国家纷纷定制了自己的编码 日本把日文编到Shift_JIS里，韩国把韩文编到Euc-kr里 #阶段三：各国有各国的标准，就会不可避免地出现冲突，结果就是，在多语言混合的文本中，显示出来会有乱码。如何解决这个问题呢？？？ #！！！！！！！！！！！！非常重要！！！！！！！！！！！！ 说白了乱码问题的本质就是不统一，如果我们能统一全世界，规定全世界只能使用一种文字符号，然后统一使用一种编码，那么乱码问题将不复存在， ps：就像当年秦始皇统一中国一样，书同文车同轨，所有的麻烦事全部解决 很明显，上述的假设是不可能成立的。很多地方或老的系统、应用软件仍会采用各种各样的编码，这是历史遗留问题。于是我们必须找出一种解决方案或者说编码方案，需要同时满足： #1、能够兼容万国字符 #2、与全世界所有的字符编码都有映射关系，这样就可以转换成任意国家的字符编码 这就是unicode（定长）， 统一用2Bytes代表一个字符， 虽然2**16-1=65535，但unicode却可以存放100w+个字符，因为unicode存放了与其他编码的映射关系，准确地说unicode
并不是一种严格意义上的字符编码表，下载pdf来查看unicode的详情： 链接：https://pan.baidu.com/s/1dEV3RYp 很明显对于通篇都是英文的文本来说，unicode的式无疑是多了一倍的存储空间（二进制最终都是以电或者磁的方式存储到存储介质中的） 于是产生了UTF-8（可变长，全称Unicode Transformation Format），对英文字符只用1Bytes表示，对中文字符用3Bytes，对其他生僻字用更多的Bytes去存 #总结：内存中统一采用unicode，浪费空间来换取可以转换成任意编码（不乱码），硬盘可以采用各种编码，如utf-8，保证存放于硬盘或者基于网络传输的数据量很小，提高传输效率与稳定性。 ！！！重点！！！
乱码出现的情况
首先明确概念 #1、文件从内存刷到硬盘的操作简称存文件 #2、文件从硬盘读到内存的操作简称读文件 乱码的两种情况： #乱码一：存文件时就已经乱码 存文件时，由于文件内有各个国家的文字，我们单以shiftjis去存， 本质上其他国家的文字由于在shiftjis中没有找到对应关系而导致存储失败 但当我们硬要存的时候，编辑并不会报错（难道你的编码错误，编辑器这个软件就跟着崩溃了吗？？？），但毫无疑问，不能存而硬存，肯定是乱存了，即存文件阶段就已经发生乱码 而当我们用shiftjis打开文件时，日文可以正常显示，而中文则乱码了 #用open模拟编辑器的过程 可以用open函数的write可以测试，f=open('a.txt','w',encodig='shift_jis' f.write('你瞅啥 何を見て ') #'你瞅啥'因为在shiftjis中没有找到对应关系而无法保存成功，只存'何を見て '可以成功 #以任何编码打开文件a.txt都会出现其余两个无法正常显示的问题 f=open('a.txt','wb') f.write('何を見て '.encode('shift_jis')) f.write('你愁啥 '.encode('gbk')) f.write('你愁啥 '.encode('utf-8')) f.close() #乱码二：存文件时不乱码而读文件时乱码 存文件时用utf-8编码，保证兼容万国，不会乱码，而读文件时选择了错误的解码方式，比如gbk，则在读阶段发生乱码，读阶段发生乱码是可以解决的，选对正确的解码方式就ok了， ！！！乱码分析！！！
！！！总结非常重要的两点！！！
#1、保证不乱吗的核心法则就是，字符按照什么标准而编码的，就要按照什么标准解码，此处的标准指的就是字符编码 #2、在内存中写的所有字符，一视同仁，都是unicode编码，比如我们打开编辑器，输入一个“你”，我们并不能说“你”就是一个汉字，此
时它仅仅只是一个符号，该符号可能很多国家都在使用，根据我们使用的输入法不同这个字的样式可能也不太一样。只有在我们往硬盘保存或者
基于网络传输时，才能确定”你“到底是一个汉字，还是一个日本字，这就是unicode转换成其他编码格式的过程了
unicode----->encode-------->utf-8 内存中是unicode编码，存到硬盘上面去是编码
utf-8-------->decode---------->unicode 从硬盘读到内存中是解码。
以何种方式编码，就要用何种方式解码才不会出现乱码
例子: 模拟文件编码和解码
#定义一个unicode字符，看作是内存中的数据
>>> s = u"上" >>> type(s) <type 'unicode'> >>>
#对 s 编码得到e，e就可以看作是硬盘上的数据了 >>> e=s.encode('utf8') >>> type(e) <type 'str'> >>>
#对e 用utf8解码，成功得到对应的unicode >>> e.decode('utf8') u'u4e0a' >>> >>>
#对 e 用gbk解码报错，应为编码和解码的方式不一样导致，编码用的是utf8，解码用的是gbk >>> e.decode('gbk') Traceback (most recent call last): File "<input>", line 1, in <module> e.decode('gbk') UnicodeDecodeError: 'gbk' codec can't decode byte 0x8a in position 2: incomplete multibyte sequence
unicode类型
当python解释器执行到产生字符串的代码时（例如s=u'林'），会申请新的内存地址，然后将'林'以unicode的格式存放到新的内存空间中，所以s只能encode，不能decode
#coding:gbk x=u'上' #等同于 x='上'.decode('gbk') y=u'下' #等同于 y='下'.decode('gbk') print([x,y]) #[u'u4e0a', u'u4e0b']
对于unicode格式的数据来说，无论怎么打印，都不会乱码.因为unicode可以转换成任意编码.
py2默认ASCII码，py3默认的utf8，可以通过如下方式查询
import sys print(sys.getdefaultencoding())
大家还记得这个声明吗？
#coding:utf8
是的，这就是因为如果py2解释器去执行一个utf8编码的文件，就会以默认地ASCII去解码utf8，一旦程序中有中文，自然就解码错误了，所以我们在文件开头位置声明 #coding:utf8，其实就是告诉解释器，你不要以默认的编码方式去解码这个文件，而是以utf8来解码。而py3的解释器因为默认utf8编码，所以就方便很多了。
常见的编码问题
cmd下的乱码问题
hello.py
#coding:utf8 print ('哈哈')
文件保存时的编码也为utf8。
思考：为什么在IDE下用2或3执行都没问题，在cmd.exe下3正确，2乱码呢？
我们在win下的终端即cmd.exe去执行，大家注意，cmd.exe本身也一个软件；当我们python2 hello.py时，python2解释器(默认ASCII编码)去按声明的utf8编码文件，而文件又是utf8保存的，所以没问题；问题出在当我们print'路川'时，解释器这边正常执行，也不会报错，只是print的内容会传递给cmd.exe用来显示，而在py2里这个内容就是utf8编码的字节数据，可这个软件默认的编码解码方式是GBK，所以cmd.exe用GBK的解码方式去解码utf8自然会乱码。
py3正确的原因是传递给cmd的是unicode数据，cmd.exe可以识别内容，所以显示没问题。
明白原理了，修改就有很多方式，比如：
print (u'路川')
open()中的编码问题
创建一个hello文本，保存成utf8：
哈哈啊啊哈哈，哦哦哦哦
同目录下创建一个index.py
f=open('hello') print(f.read())
为什么 在linux下，结果正常：苑昊，在win下，乱码：鑻戞槉（py3解释器）？
因为你的win的操作系统安装时是默认的gbk编码，而linux操作系统默认的是utf8编码；
当执行open函数时，调用的是操作系统打开文件，操作系统用默认的gbk编码去解码utf8的文件，自然乱码。
解决办法：
f=open('hello',encoding='utf8') print(f.read())
如果你的文件保存的是gbk编码，在win 下就不用指定encoding了。
另外，如果你的win上不需要指定给操作系统encoding='utf8'，那就是你安装时就是默认的utf8编码或者已经通过命令修改成了utf8编码。
注意：open这个函数在py2里和py3中是不同的，py3中有了一个encoding＝None参数。
参考：http://www.cnblogs.com/luchuangao/articles/6658017.html#_label0
http://www.cnblogs.com/linhaifeng/articles/5950339.html