第三篇：Python字符编码

#、打开编辑器就打开了启动了一个进程，是在内存中的，所以，用编辑器编写的内容也都是存放与内存中的，断电后数据丢失#、要想永久保存，需要点击保存按钮：编辑器把内存的数据刷到了硬盘上。#、在我们编写一个py文件（没有执行），跟编写其他文件没有任何区别，都只是在编写一堆字符而已。

#第一阶段：Python解释器启动，此时就相当于启动了一个文本编辑器#第二阶段：Python解释器相当于文本比那机器，去打开test.py文件，从硬盘上将test.py的文件内容读入到内存中（python的解释型，决定了解释器只关心文件内容，不关心文件后缀名）#第三阶段：Python解释器解释执行刚刚加载到内存中test.py的代码(ps:在该阶段，即真正执行代码时，才会识别Python的语法，执行文件内代码，当执行到name="egon"时，会开辟内存空间存放字符串"egon")

#、相同点：Python解释器是解释执行文件内容的，因而Python解释器具备读py文件的功能，这一点文本编辑器一样
#、不同点：文本编辑器将文件内容读入内存后，是为了显示或者编辑，根本不去理会Python的语法，而Python解释器将文件内容读入内存后，可不是为了给你瞅一眼Python代码写的啥，而是为了执行Python代码、会识别Python语法。

计算机要想工作必须通电,即用‘电’驱使计算机干活,也就是说‘电’的特性决定了计算机的特性。电的特性即高低电平(人类从逻辑上将二进制数1对应高电平,二进制数0对应低电平)，
关于磁盘的磁特性也是同样的道理。结论：计算机只认识数字很明显，我们平时在使用计算机时，用的都是人类能读懂的字符（用高级语言编程的结果也无非是在文件内写了一堆字符），如何能让计算机读懂人类的字符？必须经过一个过程：
#字符--------（翻译过程）------->数字 #这个过程实际就是一个字符如何对应一个特定数字的标准，这个标准称之为字符编码

#、一个python文件中的内容是由一堆字符组成的，存取均涉及到字符编码问题（python文件并未执行，前两个阶段均属于该范畴）#、python中的数据类型字符串是由一串字符组成的（python文件执行时，即第三个阶段）

计算机由美国人发明，最早的字符编码为ASCII，只规定了英文字母数字和一些特殊字符与数字的对应关系。最多只能用 位来表示（一个字节），即：** = ，所以，ASCII码最多只能表示 个符号

当然我们编程语言都用英文没问题，ASCII够用，但是在处理数据时，不同的国家有不同的语言，日本会在自己的程序中加入日文，中国人会加入中文。而要表示中文，单拿一个字节表表示一个汉子，是不可能表达完的(连小学生都认识两千多个汉字)，解决方法只有一个，就是一个字节用>8位2进制代表，位数越多，代表的变化就多，这样，就可以尽可能多的表达出不通的汉字所以中国人规定了自己的标准gb2312编码，规定了包含中文在内的字符－>数字的对应关系。日本人规定了自己的Shift_JIS编码韩国人规定了自己的Euc-kr编码（另外，韩国人说，计算机是他们发明的，要求世界统一用韩国编码，但世界人民没有搭理他们）这时候问题出现了，精通18国语言的小周同学谦虚的用8国语言写了一篇文档，那么这篇文档，按照哪国的标准，都会出现乱码（因为此刻的各种标准都只是规定了自己国家的文字在内的字符跟数字的对应关系，如果单纯采用一种国家的编码格式，那么其余国家语言的文字在解析时就会出现乱码）所以迫切需要一个世界的标准（能包含全世界的语言）于是unicode应运而生（韩国人表示不服，然后没有什么卵用）ascii用1个字节（8位二进制）代表一个字符unicode常用2个字节（16位二进制）代表一个字符，生僻字需要用4个字节例：字母x，用ascii表示是十进制的120，二进制0111 汉字中已经超出了ASCII编码的范围，用Unicode编码是十进制的20013，二进制的01001110 。字母x，用unicode表示二进制0000 ，所以unicode兼容ascii，也兼容万国，是世界的标准这时候乱码问题消失了，所有的文档我们都使用但是新问题出现了，如果我们的文档通篇都是英文，你用unicode会比ascii耗费多一倍的空间，在存储和传输上十分的低效本着节约的精神，又出现了把Unicode编码转化为“可变长编码”的UTF-8编码。UTF-8编码把一个Unicode字符根据不同的数字大小编码成1-6个字节，常用的英文字母被编码成1个字节，汉字通常是3个字节，只有很生僻的字符才会被编码成4-6个字节。如果你要传输的文本包含大量英文字符，用UTF-8编码就能节省空间： 

从上面的表格还可以发现，UTF-8编码有一个额外的好处，就是ASCII编码实际上可以被看成是UTF-8编码的一部分，所以，大量只支持ASCII编码的历史遗留软件可以在UTF-8编码下继续工作。

！！！重点！！！

基于目前的现状，内存中的编码固定就是unicode，我们唯一可变的就是硬盘的上对应的字符编码。
此时你可能会觉得，那如果我们以后开发软时统一都用unicode编码，那么不就都统一了吗，关于统一这一点你的思路是没错的，但我们不可会使用unicode编码来编写程序的文件，因为在通篇都是英文的情况下，耗费的空间几乎会多出一倍，这样在软件读入内存或写入磁盘时，都会徒增IO次数，从而降低程序的执行效率。因而我们以后在编写程序的文件时应该统一使用一个更为精准的字符编码utf-（用1Bytes存英文，3Bytes存中文），再次强调，内存中的编码固定使用unicode。
、在存入磁盘时，需要将unicode转成一种更为精准的格式，utf-:全称Unicode Transformation Format，将数据量控制到最精简、在读入内存时，需要将utf-8转成unicode
所以我们需要明确：内存中用unicode是为了兼容万国软件，即便是硬盘中有各国编码编写的软件，unicode也有相对应的映射关系，但在现在的开发中，程序员普遍使用utf-8编码了，估计在将来的某一天等所有老的软件都淘汰掉了情况下，就可以变成：内存utf-<->硬盘utf-8的形式了。

首先明确概念
#、文件从内存刷到硬盘的操作简称存文件
#、文件从硬盘读到内存的操作简称读文件乱码的两种情况：
#乱码一：存文件时就已经乱码
存文件时，由于文件内有各个国家的文字，我们单以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了，

#reload与convert的区别：pycharm非常强大，提供了自动帮我们convert转换的功能，即将字符按照正确的格式转换要自己探究字符编码的本质，还是不要用这个我们选择reload，即按照某种编码重新加载文件

文件test.py以gbk格式保存，内容为：x='林'无论是python2 test.py还是python3 test.py都会报错（因为python2默认ascii，python3默认utf-）除非在文件开头指定#coding:gbk

#、保证不乱吗的核心法则就是，字符按照什么标准而编码的，就要按照什么标准解码，此处的标准指的就是字符编码#、在内存中写的所有字符，一视同仁，都是unicode编码，比如我们打开编辑器，输入一个“你”，我们并不能说“你”就是一个汉字，此时它仅仅只是一个符号，该符号可能很多国家都在使用，根据我们使用的输入法不同这个字的样式可能也不太一样。只有在我们往硬盘保存或者基于网络传输时，才能确定”你“到底是一个汉字，还是一个日本字，这就是unicode转换成其他编码格式的过程了

#补充：浏览网页的时候，服务器会把动态生成的Unicode内容转换为UTF-8再传输到浏览器如果服务端encode的编码格式是utf-， 客户端内存中收到的也是utf-8编码的结果。

此时，python解释器会读取test.py的第一行内容，#coding:utf-，来决定以什么编码格式来读入内存，这一行就是来设定python解释器这个软件的编码使用的编码格式这个编码，可以用sys.getdefaultencoding()查看，如果不在python文件指定头信息＃-*-coding:utf--*-,那就使用默认的python2中默认使用ascii，python3中默认使用utf-

#coding:gbk
你好啊

内存的编码使用unicode，不代表内存中全都是unicode，在程序执行之前，内存中确实都是unicode,比如从文件中读取了一行x="egon",其中的x，等号，引号，地位都一样，都是普通字符而已，都是以unicode的格式存放于内存中的但是程序在执行过程中，会申请内存（与程序代码所存在的内存是俩个空间）用来存放python的数据类型的值，而python的字符串类型又涉及到了字符的概念比如x="egon",会被python解释器识别为字符串，会申请内存空间来存放字符串类型的值，至于该字符串类型的值被识别成何种编码存放，这就与python解释器的有关了，而python2与python3的字符串类型又有所不同。

#coding:gbk
x='上'
y='下'
print([x,y]) #['\xc9\xcf', '\xcf\xc2']
#\x代表16进制，此处是c9cf总共4位16进制数，一个16进制四4个比特位，4个16进制数则是16个比特位，即2个Bytes，这就证明了按照gbk编码中文用2Bytesprint(type(x),type(y)) #(<type 'str'>, <type 'str'>)

x=‘你a好’
转成gbk格式二进制位
8bit+8bit+8bit+8bit+8bit=(+7bit)+(+7bit)+(+7bit)+(+7bit)+(+7bit)

#连续读到前两个括号内的首位标志位均为1，则构成一个中午字符：你#读到第三个括号的首位标志为0，则该8bit代表一个英文字符：a#连续读到后两个括号内的首位标志位均为1，则构成一个中午字符：好

(7bit)+(7bit)+(7bit)+(7bit)+(7bit)

#coding:gbk
x='上'.decode('gbk')
y='下'.decode('gbk')
print([x,y]) #[u'\u4e0a', u'\u4e0b']

#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'>)

#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'>