一、计算机基础知识
二、文本编辑器存取文件的原理（nodepad++，pycharm，word）
#1、打开编辑器就打开了启动了一个进程，是在内存中的，所以，用编辑器编写的内容也都是存放与内存中的，断电后数据丢失
#2、要想永久保存，需要点击保存按钮：编辑器把内存的数据刷到了硬盘上。
#3、在我们编写一个py文件（没有执行），跟编写其他文件没有任何区别，都只是在编写一堆字符而已。
三、python解释器执行py文件的原理 ，例如python test.py
总共分三个执行阶段：
第一阶段：Python解释器启动，此时就相当于启动了一个文本编辑器
第二阶段：Python解释器相当于文本编辑器，去打开test.py文件，从硬盘上将test.py 的文件内容读到内存中（小复习：Python的解释性，决定了解释器只关心文件内容，不关心文件名后缀名）
第三阶段：Python解释器执行刚刚加载到内存中的test.py的代码（ps:在该阶段，即真正执行代码时，才会识别Python的语法，执行文件内代码,当执行到name='parker'时，会开辟内存空间存放字符串‘parker’）
四 总结python解释器与文件本编辑的异同
#1、相同点：Python解释器是执行文件内容的，因而python解释器具备读py文件的功能，这一点与文本编辑器一样
#2、不同点：文本编辑器将文件内容读到内存后，是为了显示或者编辑，根本不会去理Python的语法，而Python解释器将文件内容读入内存后，可不是为了给你瞅一眼Python代码写的是啥，而是为了执行Python代码、会识别Python语法。
字符编码介绍
一、什么是字符编码
计算机要想工作必须通电,即用‘电’驱使计算机干活,也就是说‘电’的特性决定了计算机的特性。电的特性即高低电平(人类从逻辑上将二进制数1对应高电平,二进制数0对应低电平)，关于磁盘的磁特性也是同样的道理。结论：计算机只认识数字
很明显，我们平时在使用计算机时，用的都是人类能读懂的字符（用高级语言编程的结果也无非是在文件内写了一堆字符），如何能让计算机读懂人类的字符？
必须经过一个过程：
#字符--------（翻译过程）------->数字
#这个过程实际就是一个字符如何对应一个特定数字的标准，这个标准称之为字符编码
二、以下两个场景涉及到字符编码问题：
#1、一个Python文件中的内容是有一对字符组成的，存取涉及到字符编码问题（Python文件没执行，前两个阶段均属于该范畴）
#2、Python中的数据类型字符串是由一串字符组成的（Python文件执行时，即第三个阶段）
总结字符编码的发展可分为三个阶段（重要）
#阶段一：现代计算机起源于美国，最早诞生也是基于英文考虑的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，保证存放于硬盘或者基于网络传输的数据量很小，提高传输效率与稳定性。
三、字符编码应用之文件编辑器
3.1 文本编辑器值notepad++
乱码分析
首先明确概念
1、文件从内存刷到硬盘的操作简称存文件
2、文件从硬盘读到内存的操作简称读文件
乱码的两种情况：
乱码一：存文件时就已经乱码
存文件时，由于文件内有各个国家的文字，我们单以shiftjis去存，
本质上其他国家的文字由于在shiftjis中没有找到对应关系而导致存储失败
但当我们硬要存的时候，编辑并不会报错（难道你的编码错误，编辑器这个软件就跟着崩溃了吗？？？），但毫无疑问，不能存而硬存，肯定是乱存了，即存文件阶段就已经发生乱码
而当我们用shiftjis打开文件时，日文可以正常显示，而中文则乱码了
用open模拟编辑器的过程
可以用open函数的write可以测试，f=open('a.txt','w',encodig='shift_jis'
f.write('你瞅啥\n何を見て\n') #'你瞅啥'因为在shiftjis中没有找到对应关系而无法保存成功，只存'何を見て\n'可以成功
以任何编码打开文件a.txt都会出现其余两个无法正常显示的问题
f=open('a.txt','wb')
f.write('何を見て\n'.encode('shift_jis'))
f.write('你愁啥\n'.encode('gbk'))
f.write('你愁啥\n'.encode('utf-8'))
f.close()
乱码二：存文件时不乱码而读文件时乱码
存文件时用utf-8编码，保证兼容万国，不会乱码，而读文件时选择了错误的解码方式，比如gbk，则在读阶段发生乱码，读阶段发生乱码是可以解决的，选对正确的解码方式就ok了。
3.2 文本编辑器之pycharm
以utf-8格式打开（选择reload）
pycharm中convert 和reload 的区别
#reload与convert的区别：
pycharm非常强大，提供了自动帮我们convert转换的功能，即将字符按照正确的格式转换
要自己探究字符编码的本质，还是不要用这个
我们选择reload，即按照某种编码重新加载文件
pycharm中：reload与convert的区别
3.3 文本编辑器之python解释器
文件test.py以gbk格式保存，内容为：
x='林'
无论是
python2 test.py
还是
python3 test.py
都会报错（因为python2默认ascii，python3默认utf-8）
除非在文件开头指定#coding:gbk
总结
！！！非常重要的两点！！！
1、保证不乱吗的核心法则就是，字符按照什么标准而编码的，就要按照什么标准解码，此处的标准指的就是字符编码
2、在内存中写的所有字符，一视同仁，都是unicode编码，比如我们打开编辑器，输入一个“你”，我们并不能说“你”就是一个汉字，此时它仅仅只是一个符号，该符号可能很多国家都在使用，根据我们使用的输入法不同这个字的样式可能也不太一样。只有在我们往硬盘保存或者基于网络传输时，才能确定”你“到底是一个汉字，还是一个日本字，这就是unicode转换成其他编码格式的过程了
unicode----->encode-------->utf-8
utf-8-------->decode---------->unicode
#补充
浏览网页的时候，服务器会把动态生成的Unicode内容转换为UTF-8再传输到浏览器
如果服务端encode的编码格式是utf-8， 客户端内存中收到的也是utf-8编码的结果。
四 字符编码应用之python
python test.py（再强调一遍，执行test.py的第一步，一定是先将文件内容读入到内存中）
test.py文件内容以GBK格式保存的，内容为：
阶段一：启动Python解释器
阶段二：Python解释器此时就是一个文本编辑器，负责打开文件test.py，即从硬盘中读取test.py的内容到内存中。
取test.py的内容到内存中
此时，python解释器会读取test.py的第一行内容，#coding:utf-8，来决定以什么编码格式来读入内存，这一行就是来设定python解释器这个软件的编码使用的编码格式这个编码，
可以用sys.getdefaultencoding()查看，如果不在python文件指定头信息＃-*-coding:utf-8-*-,那就使用默认的
python2中默认使用ascii，python3中默认使用utf-8
改正：在test.py指定文件头，字符编码一定要为gbk,
#coding: gbk
阶段三：读取已经加载到内存的代码（Unicode编码格式），然后执行，执行过程中可能会开辟新的内存空间，比如x = 'parker'
内存的编码使用unicode，不代表内存中全都是unicode，
在程序执行之前，内存中确实都是unicode,比如从文件中读取了一行x="egon",其中的x，等号，引号，地位都一样，都是普通字符而已，都是以unicode的格式存放于内存中的
但是程序在执行过程中，会申请内存（与程序代码所存在的内存是俩个空间）用来存放python的数据类型的值，而python的字符串类型又涉及到了字符的概念
比如x="egon",会被python解释器识别为字符串，会申请内存空间来存放字符串类型的值，至于该字符串类型的值被识别成何种编码存放，这就与python解释器的有关了，而python2与python3的字符串类型又有所不同。
python2 与Python3字符串类型区别
一、在Python2中有两种字符串类型str和Unicode
Str类型
当Python解释器执行到产生字符串的代码时（例如x = 'code'），会申请新的内存地址，然后将‘code’编码成文件开头指定的编码格式
要想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'>)
理解字符编码的关键！！！
内存中的数据常用16进制表示，2位16进制数据代表一个字节，如\xc9，代表两位16进制，一个字节
gbk存中文需要2个bytes，而英文则需要1个bytes，它是如何做到的？
gbk会在每个bytes，即8位bit的第一个位作为标志位，标志位为1则表示是中文字符，如果标志位为0则表示为英文字符
x=‘你a好’
转成gbk格式二进制位
8bit+8bit+8bit+8bit+8bit=(1+7bit)+(1+7bit)+(0+7bit)+(1+7bit)+(1+7bit)
这样计算机按照从左往右的顺序读：
#连续读到前两个括号内的首位标志位均为1，则构成一个中午字符：你
#读到第三个括号的首位标志为0，则该8bit代表一个英文字符：a
#连续读到后两个括号内的首位标志位均为1，则构成一个中午字符：好
也就是说，每个Bytes留给我们用来存真正值的有效位数只有7位，而在unicode表中存放的只是这有效的7位，至于首位的标志位与具体的编码有关，即在unicode中表示gbk的方式为：
(7bit)+(7bit)+(7bit)+(7bit)+(7bit)
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'>)
打印到终端
对于print需要特别说明的是：
当程序执行时，比如
x='上' #gbk下，字符串存放为\xc9\xcf
print(x) #这一步是将x指向的那块新的内存空间（非代码所在的内存空间）中的内存，打印到终端，按理说应该是存的什么就打印什么,但打印\xc9\xcf，对一些不熟知python编码的程序员，立马就懵逼了，所以龟叔自作主张，在print(x)时，使用终端的编码格式，将内存中的\xc9\xcf转成字符显示，此时就需要终端编码必须为gbk，否则无法正常显示原内容：上
对于Unicode格式的数据来说，无论怎么打印，都不会乱码
很明显，在Python2 中，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中x.encode('gbk') 的结果\xc9\xcf正是python2中的str类型的值,而在python3是bytes类型，在python2中则是str类型
于是我有一个大胆的推测：python2中的str类型就是python3的bytes类型，于是我查看python2的str()源码，发现
