字符编码的历史
阶段一：现代计算机起源于美国，最早诞生也是基于英文考虑的ASCII
阶段二:为了满足中文，中国人定制了GBK
阶段三：各国有各国的标准，就会不可避免地出现冲突，结果就是，在多语言混合的文本中，显示出来会有乱码。于是产生了unicode，以及为了节省英文空间的utf-8。
#阶段一：现代计算机起源于美国，最早诞生也是基于英文考虑的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 所有程序，最终都要加载到内存，程序保存到硬盘不同的国家用不同的编码格式，但是到内存中我们为了兼容万国（计算机可以运行任何国家的程序原因在于此），统一且固定使用unicode，
2 这就是为何内存固定用unicode的原因，你可能会说兼容万国我可以用utf－8啊，可以，完全可以正常工作，之所以不用肯定是unicode比utf－8更高效啊（uicode固定用2个字节编码
3 ，utf－8则需要计算），但是unicode更浪费空间，没错，这就是用空间换时间的一种做法，而存放到硬盘，或者网络传输，都需要把unicode转成utf－8，
4 因为数据的传输，追求的是稳定，高效，数据量越小数据传输就越靠谱，于是都转成utf－8格式的，而不是unicode。
字符串转换的unicode
unicode------>encode(编码)-------->utf-8
utf-8---------->decode--------->unicode
文件从内存刷到硬盘的操作简称存文件
文件从硬盘读到内存的操作简称读文件
乱码：存文件时就已经乱码 或者 存文件时不乱码而读文件时乱码
总结：
无论是何种编辑器，要防止文件出现乱码（请一定注意，存放一段代码的文件也仅仅只是一个普通文件而已，此处指的是文件没有执行前，我们打开文件时出现的乱码）
核心法则就是，文件以什么编码保存的，就以什么编码方式打开
python相关的字符编码
python解释器
文件test.py以gbk格式保存，内容为： x='林' 无论是 python2 test.py 还是 python3 test.py 都会报错（因为python2默认ascii，python3默认utf-8） 除非在文件开头指定#coding:gbk
py文件开头的coding:utf-8
内存的编码使用unicode，不代表内存中全都是unicode， 在程序执行之前，内存中确实都是unicode,比如从文件中读取了一行x="egon",其中的x，等号，引号，地位都一样，都是普通字符而已，都是以unicode的格式存放于内存中的 但是程序在执行过程中，会申请内存（与程序代码所存在的内存是俩个空间）用来存放python的数据类型的值，而python的字符串类型又涉及到了字符的概念 比如x="egon",会被python解释器识别为字符串，会申请内存空间来存放字符串类型的值，至于该字符串类型的值被识别成何种编码存放，这就与python解释器的有关了，而python2与python3的字符串类型又有所不同。
内存编码unicode以及经过python执行后存储的非unicode
python2与python3字符串类型的区别
python2的两种字符串类型str和unicode
str类型
当python解释器执行到产生字符串的代码时（例如x='上'），会申请新的内存地址，然后将'上'编码成文件开头指定的编码格式
要想看x在内存中的真实格式，可以将其放入列表中再打印，而不要直接打印，因为直接print()会自动转换编码，这一点我们稍后再说。
#coding:gbk
x='上'
y='下'
print([x,y]) #['\xc9\xcf', '\xcf\xc2']
#\x代表16进制，此处是c9cf总共4位16进制数，一个16进制四4个比特位，4个16进制数则是16个比特位，即2个Bytes，这就证明了按照gbk编码中文用2Bytes print(type(x),type(y)) #(<type 'str'>, <type 'str'>)
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'] print(type(x),type(y)) #(<type 'unicode'>, <type 'unicode'>)
在python3 中也有两种字符串类型str和bytes
str是unicode
#coding:gbk
x='上' #当程序执行时，无需加u，'上'也会被以unicode形式保存新的内存空间中, print(type(x)) #<class 'str'> #x可以直接encode成任意编码格式
print(x.encode('gbk')) #b'\xc9\xcf'
print(type(x.encode('gbk'))) #<class 'bytes'>
python3是bytes类型，在python2中则是str类型
python2源码：
参考or转发
http://www.cnblogs.com/linhaifeng/articles/5950339.html