字符编码、文件处理

字符编码

因为计算机的工作是肯定需要电，人类就在逻辑上将二进制数1对应高电平，二进制数0对应低电平，所以计算机只能认识数字。但是我们在平时使用计算机的时候使用的都是我们人类自己可以读懂得语言，为了让计算机也可以读懂人类可以读懂的语言必须要经历一段过程：将字符翻译成数字   这个过程实际就是一个字符如何对应一个特定数字的标准，这个标准称之为字符编码

字符编码的发展以及分类

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

 

当然我们编程语言都用英文没问题，ASCII够用，但是在处理数据时，不同的国家有不同的语言，日本人会在自己的程序中加入日文，中国人会加入中文。

 

而要表示中文，单拿一个字节表表示一个汉子，是不可能表达完的(连小学生都认识两千多个汉字)，解决方法只有一个，就是一个字节用>8位2进制代表，位数越多，代表的变化就多，这样，就可以尽可能多的表达出不通的汉字

 

所以中国人规定了自己的标准gb2312编码，规定了包含中文在内的字符－>数字的对应关系。

 

日本人规定了自己的Shift_JIS编码

 

韩国人规定了自己的Euc-kr编码（另外，韩国人说，计算机是他们发明的，要求世界统一用韩国编码，但世界人民没有搭理他们）

  

这时候问题出现了，精通18国语言的小周同学谦虚的用8国语言写了一篇文档，那么这篇文档，按照哪国的标准，都会出现乱码（因为此刻的各种标准都只是规定了自己国家的文字在内的字符跟数字的对应关系，如果单纯采用一种国家的编码格式，那么其余国家语言的文字在解析时就会出现乱码）

 

所以迫切需要一个世界的标准（能包含全世界的语言）于是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，也兼容万国，是世界的标准

 

这时候乱码问题消失了，所有的文档我们都使用但是新问题出现了，如果我们的文档通篇都是英文，你用unicode会比ascii耗费多一倍的空间，在存储和传输上十分的低效

本着节约的精神，又出现了把Unicode编码转化为“可变长编码”的UTF-8编码。UTF-8编码把一个Unicode字符根据不同的数字大小编码成1-6个字节，常用的英文字母被编码成1个字节，汉字通常是3个字节，只有很生僻的字符才会被编码成4-6个字节。如果你要传输的文本包含大量英文字符，用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、保证不乱吗的核心法则就是，字符按照什么标准而编码的，就要按照什么标准解码，此处的标准指的就是字符编码

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

 

文件处理

 我们平时操作计算机最常用的操作就是对于文件的使用，若是我们想要将文件完全保存下来就必须jinag将其保存到硬盘之中。对于文件的处理也是分为三个部分：

第一步：打开文件

f=open(r'文件路径', mode='打开文件的模式',encoding='字符编码')  # 默认打开文件的模式为r，r代表只读，t代表文本文件

第二步：读\写

date=f.read()　

第三步：关闭文件

f.close()   #回收系统的资源

 重要内容

打开一个文件包含两部分资源：操作系统级打开的文件+应用程序的变量。在操作完毕一个文件时，必须把与该文件的这两部分资源一个不落地回收，回收方法为：
1、f.close() #回收操作系统级打开的文件
2、del f #回收应用程序级的变量

其中del f一定要发生在f.close()之后，否则就会导致操作系统打开的文件还没有关闭，白白占用资源，
而python自动的垃圾回收机制决定了我们无需考虑del f，这就要求我们，在操作完毕文件后，一定要记住f.close()

虽然我这么说，但是很多同学还是会很不要脸地忘记f.close(),对于这些不长脑子的同学，我们推荐傻瓜式操作方式：使用with关键字来帮我们管理上下文
with open('a.txt','w') as f:
    pass
 
with open('a.txt','r') as read_f,open('b.txt','w') as write_f:
    data=read_f.read()
    write_f.write(data)

回收资源

 

f=open(...)是由操作系统打开文件，那么如果我们没有为open指定编码，那么打开文件的默认编码很明显是操作系统说了算了，操作系统会用自己的默认编码去打开文件，在windows下是gbk，在linux下是utf-8。
这就用到了上节课讲的字符编码的知识：若要保证不乱码，文件以什么方式存的，就要以什么方式打开。

f=open('a.txt','r',encoding='utf-8')

指定字符编码

 

操作文件的模式：r、w、a

r：（只读模式）

1、默认打开文件　

2、文件不存在，报错

 

w：（只写模式）　

1、文件存在时清空

2、文件不存在，则创建空文档

 

a：（只追加写模式）

1、文件不存在，创建空文档

2、文件存在，光标直接到文件末尾

操作文件的方法：

f.read() #读取所有内容,光标移动到文件末尾
f.readline() #读取一行内容,光标移动到第二行首部
f.readlines() #读取每一行内容,存放于列表中

　

f.write('1111\n222\n') #针对文本模式的写,需要自己写换行符
f.writelines(['333\n','444\n']) #文件模式