字符编码
字符（储存信息的东西）
编码： 01010101010 --》 键盘
字符编码是将人类的字符编码成计算机能识别的数字，这种转换必须遵循一套固定的标准，该标准无非是人类字符与数字的对应关系，称之为字符编码表。
文本编辑器储存信息的过程
- 打开编辑器就打开了启动了一个进程，是在内存中的，所以，用编辑器编写的内容也都是存放与内存中的，断电后数据丢失。
- 要想永久保存，需要点击保存按钮：编辑器把内存的数据刷到了硬盘上。
- 在我们编写一个py文件（没有执行），跟编写其他文件没有任何区别，都只是在编写一堆字符而已。
文本编辑器 --》 写文本 --》 存储信息
显示屏（内存） --》（转换）硬盘
字符编码的发展史以及分类
ASCII(美国)
# acill编码的转换关系的方法
print(chr(65))
print(ord('a'))
gb2312编码（中国）
Shift_JIS编码 日本
Euc-kr编码 韩国
unicode编码
早期，各个国家只能使用各个国家的计算机 --》 天下大势分久必合，合久必分
迫切需要一个世界的标准（能包含全世界的语言）于是Unicode应运而生
ascii用1个字节（8位二进制）代表一个字符；Unicode常用2个字节（16位二进制）代表一个字符，生僻字需要用4个字节。
例：字母x，用ascii表示是十进制的120，二进制0111 1000。
汉字中已经超出了ASCII编码的范围，用Unicode编码是十进制的20013，二进制的01001110 00101101。
字母x，用Unicode表示二进制0000 0000 0111 1000，所以Unicode兼容ascii，也兼容万国，是世界的标准。
utf-8（Unicode Transformation Format-8）编码
乱码问题消失了，所有的文档我们都使用但是新问题出现了，如果我们的文档通篇都是英文，你用Unicode会比ascii耗费多一倍的空间，在存储和传输上十分的低效。
本着节约的精神，又出现了把Unicode编码转化为“可变长编码”的UTF-8（Unicode Transformation Format-8）编码。UTF-8编码把一个Unicode字符根据不同的数字大小编码成1-6个字节，常用的英文字母被编码成1个字节，汉字通常是3个字节，只有很生僻的字符才会被编码成4-6个字节。如果你要传输的文本包含大量英文字符，用UTF-8编码就能节省空间：
| 字符 | ASCII | Unicode | UTF-8 |
|---|---|---|---|
| A | 01000001 | 00000000 01000001 | 01000001 |
| 中 | x | 01001110 00101101 | 11100100 10111000 10101101 |
从上面的表格还可以发现，UTF-8编码有一个额外的好处，就是ASCII编码实际上可以被看成是UTF-8编码的一部分，所以，大量只支持ASCII编码的历史遗留软件可以在UTF-8编码下继续工作。
现在所有的电脑都是这样的 --》 内存中unicode取，存用utf8存（硬盘），全世界的人写代码/写文件都是用utf8
内存为什么不用UTF-8呢？
出现这个问题的原因是硬盘中还躺了其他国家的代码，各个国家的代码的二进制还需要运行在计算机上使用，因此内存中必须使用Unicode的编码，因为Unicode能和硬盘中其他国家的二进制中的代码进行转换，但是UTF-8只是简化了代码的存储，它并不能与其他国家硬盘中的代码进行关系转换。总而言之只有Unicode编码才能运行其他国家硬盘中的代码，而UTF-8的代码无法进行该操作。
内存中还使用Unicode编码，是因为历史遗留问题造成的，但是因为现在写代码使用的都是UTF-8代码，所以以后内存中的代码都将变成UTF-8代码，并且以前遗留的各个国家的代码都将被淘汰，所以未来内存中使用的编码也将使用UTF-8编码替代Unicode编码。
utf8和gb2312/fuck都没有转换关系，因此内存都要用unicode
未来迟早有一天，内存要用utf8
gb2312和gbk的区别
先能用就行，不常用的词+繁体字
gb2312 --》 常用词
gbk --》 所有字
windows系统的记事本默认编码 是 gbk，除此之外都是utf8
乱码分析
用什么编码写，就用什么编码读
写用utf8，存用utf8，读用gbk--》乱码
存文件时不乱码而读文件时乱码
存文件时用utf-8编码，保证兼容万国，不会乱码，而读文件时选择了错误的解码方式，比如gbk，则在读阶段发生乱码，读阶段发生乱码是可以解决的，选对正确的解码方式就ok了
写用utf8，存用gbk，--》乱码 （ 不会发生）
除非你找日文编码，放入中文 の（中文的一个符号，不是日文的“的”）
存文件时就已经乱码
但当我们硬要存的时候，编辑并不会报错（pychram编辑器自动转换），但毫无疑问，不能存而硬存，肯定是乱存了，即存文件阶段就已经发生乱码
编码和解码
unicode编码---》（编码） utf8 从内存到硬盘
utf8 --》（解码） unicode 从硬盘到内存
现在内存只有unicode编码
解决乱码法则
- 保证不乱码的核心法则就是，字符按照什么标准而编码的，就要按照什么标准解码，此处的标准指的就是字符编码。
- 在内存中写的所有字符，一视同仁，都是Unicode编码。我们唯一能改变的就是存储到硬盘时使用的编码。
python解释器（文本编辑器）解释python代码的流程
- python解释器相当于文本编辑器，把代码读入python解释器 --》 字符编码 -》 python2默认是ascill，python3默认utf8 --》 上coding头
中文 # gbk编码的中文加
- 识别代码 --》print有意义 --》 语法问题
# coding:gbk # 告诉python解释器用gbk去完成第一步，读入字符
中文
- 产生结果 --》 跑到终端--》字符编码
终端有一个特性：你的电脑是什么编码，就按照什么编码的来，windows终端是gbk
python2和python3的编码区别
python2
python2有两种存储变量的形式，第一种：unicode；第二种：按照coding头来的
假设python2用utf8存储x='中文',当你print(x)的时候，终端接收gbk的变量x，但是windows终端编码是utf8，会乱码
假设python2用unicode存储，终端接受的是unicode，不会乱码
# coding:gbk
lt1 = '中文' # utf存储的
# lt1 = ['中文'] # []让他不用终端的编码转化，显示01010101001
print lt1 # ['xe4xb8xadxe6x96x87']
lt2 = u'中文' # u'中文'让他变成unicode # 早期用python2定义中文，必须得加上u，让他变成unicode存储
# lt2 = [u'中文']
print lt2 # '中文'
python3
python3只有一种存储变量的形式，unicode
python3用unicode存储，终端接收的是unicode，widonws终端编码是utf还是gbk不重要，不会乱码
lt1 = '中文' # == u'中文'
print(lt1)