2019 08 08 字符编码，文件操作

字符编码

一、计算机基础

1. cpu: 控制程序的运行(从内存中取出文本编辑器的数据读入内存)
2. 内存: 运行程序(经cpu操作后,内存中含有文本编辑器的数据)
3. 硬盘: 存储数据(文本编辑器)

二、文本编辑器存取文件的原理

​ 计算机只认识 0和1

​ 文本编辑器的作用: 读写数据,保存数据

1. 打开编辑器就打开了启动了一个进程，是在内存中的，所以，用编辑器编写的内容也都是存放与内存中的，断电后数据丢失。

2. 要想永久保存，需要点击保存按钮：编辑器把内存的数据刷到了硬盘上。

3. 在我们编写一个py文件（没有执行），跟编写其他文件没有任何区别，都只是在编写一堆字符而已。

三、Python解释器执行py文件的原理

​ 具有文本编辑器的功能

​ 010101011001010 --> a = 1 # 5个很普通的字符 ,python解释器没有运行的时 候提供的 # 字符编码

​ 定义变量就要开辟内存空间存放变量,内存只认识 0和1 也就是说, a=1 --> 01010110101 需要一定的0和1表示他为字符串,python解释器运行的时候提供 的 # python2和3字符编码的区别

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

四、Python解释器与文件本编辑的异同

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

五、字符编码介绍

5.1 什么是字符编码

计算机要想工作必须通电,即用‘电’驱使计算机干活,也就是说‘电’的特性决定了计算机的特性。电的特性即高低电平(人类从逻辑上将二进制数1对应高电平,二进制数0对应低电平)，关于磁盘的磁特性也是同样的道理。结论：计算机只认识数字。

很明显，我们平时在使用计算机时，用的都是人类能读懂的字符（用高级语言编程的结果也无非是在文件内写了一堆字符），如何能让计算机读懂人类的字符？

必须经过一个过程：

• 字符 --------》翻译过程 -------》数字

总而言之，字符编码是将人类的字符编码成计算机能识别的数字，这种转换必须遵循一套固定的标准，该标准无非是人类字符与数字的对应关系，称之为字符编码表。

5.2 涉及到字符编码的两个场景

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

5.3 字符编码发展史与分类

计算机由美国人发明，最早的字符编码为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（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编码下继续工作。

5.4 内存为什么不用UTF-8呢？

说了那么一大堆，那为什么内存用Unicode，而不直接使用UTF-8呢？这样不就可以直接把代码从内存直接丢入硬盘了吗？出现这个问题的原因是硬盘中还躺了其他国家的代码，各个国家的代码的二进制还需要运行在计算机上使用，因此内存中必须使用Unicode的编码，因为Unicode能和硬盘中其他国家的二进制中的代码进行转换，但是UTF-8只是简化了代码的存储，它并不能与其他国家硬盘中的代码进行关系转换。总而言之只有Unicode编码才能运行其他国家硬盘中的代码，而UTF-8的代码无法进行该操作。

内存中还使用Unicode编码，是因为历史遗留问题造成的，但是因为现在写代码使用的都是UTF-8代码，所以以后内存中的代码都将变成UTF-8代码，并且以前遗留的各个国家的代码都将被淘汰，所以未来内存中使用的编码也将使用UTF-8编码替代Unicode编码。

5.5 字符编码之文本编辑器操作

5.6 乱码分析

首先明确概念

• 文件从内存刷到硬盘的操作简称存文件
• 文件从硬盘读到内存的操作简称读文件

乱码的两种情况：

• 乱码一：存文件时就已经乱码

存文件时，由于文件内有各个国家的文字，我们单以shiftjis去存，
本质上其他国家的文字由于在shiftjis中没有找到对应关系而导致存储失败。但当我们硬要存的时候，编辑并不会报错（难道你的编码错误，编辑器这个软件就跟着崩溃了吗？？？），但毫无疑问，不能存而硬存，肯定是乱存了，即存文件阶段就已经发生乱码，而当我们用shiftjis打开文件时，日文可以正常显示，而中文则乱码了。

• 乱码二：存文件时不乱码而读文件时乱码

存文件时用utf-8编码，保证兼容万国，不会乱码，而读文件时选择了错误的解码方式，比如gbk，则在读阶段发生乱码，读阶段发生乱码是可以解决的，选对正确的解码方式就ok了。

六、总结

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

• Unicode----->encode（编码）-------->gbk
• Unicode<--------decode（解码）<----------gbk

乱码的两种情况

中文的文本编辑器只认识中文,然后你输入了日文 --> 乱码 # encode 编码

文本编辑器存储了中文(文件),但是你用日本的编辑器打开这个文件 --> 乱码 # decode 解码

解决乱码

什么格式存储, 就什么格式读取 就不会乱码(牢记这句话)

windows电脑的记事本默认为gbk编码,除此之外其他的软件默认编码为utf8

python2和python3字符编码的区别

一、字符编码应用之python

1.1 执行python程序的三个阶段

Python test.py（我再强调一遍，执行test.py的第一步，一定是先将文件内容从硬盘读入到内存中）

test.py文件内容以gbk格式保存的，内容为：

• 阶段一：启动Python解释器
• 阶段二：Python解释器此时就是一个文本编辑器，负责打开文件test.py,即从硬盘中读取test.py的内容到内存中

此时，Python解释器会读取test.py的第一行内容，#coding:utf-8或＃-*-coding:utf-8-*-，以此决定以什么编码格式将代码读入内存，这一行就是设定Python解释器这个软件使用的编码格式。

可以用sys.getdefaultencoding()查看，如果不在Python文件指定头信息＃-*-coding:utf-8-*-，那就使用Python默认的编码格式。

import sys  sys.getdefaultencoding() 'utf-8'

Python2中默认使用ascii，Python3中默认使用utf-8。

改正：在test.py指定文件头，字符编码一定要为gbk。即更正为

#coding:gbk 你好啊

• 阶段三：读取已经加载到内存的代码（Unicode编码格式），然后执行，执行过程中可能会开辟新的内存空间，比如name="nick"

内存的编码使用Unicode，不代表内存中全都是Unicode，因为在程序执行之前，内存中确实都是Unicode,比如从文件中读取了一行name="nick"，其中的name、等号、引号的地位都一样，都是普通字符而已，都是以Unicode的格式存放于内存中的。

但是程序在执行过程中，会申请内存（与程序代码所存在的内存是俩个空间）用来存放Python的数据类型的值，而Python的字符串类型又涉及到了字符的概念。

比如name="nick",会被Python解释器识别为字符串，会申请内存空间来存放字符串类型的值，至于该字符串类型的值被识别成何种编码存放，这就与Python解释器的有关了，而Python2与Python3的字符串类型又有所不同。

二、Python2与Python3字符串类型的区别

2.1 Python2

在Python2中有两种字符串类型str和Unicode。

2.1.1 str类型

当Python解释器执行到产生字符串的代码时（例如x='上'），会申请新的内存地址，然后将'上'编码成文件开头指定的编码格式

因为直接print()会自动转换编码，我们使用encode()方法查看'上'的字符编码。

# 三、Python2中代码  # 四、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. 连续读到前两个括号内的首位标志位均为1，则构成一个中午字符：你
2. 读到第三个括号的首位标志为0，则该8bit代表一个英文字符：a
3. 连续读到后两个括号内的首位标志位均为1，则构成一个中午字符：好

也就是说，每个Bytes留给我们用来存真正值的有效位数只有7位，而在Unicode表中存放的只是这有效的7位，至于首位的标志位与具体的编码有关，即在Unicode中表示gbk的方式为：(7bit)+(7bit)+(7bit)+(7bit)+(7bit)

按照上图翻译的结果，我们可以去Unicode关于汉字的对应关系中去查：链接：https://pan.baidu.com/s/1dEV3RYp

可以看到“上”对应的gbk（G0代表的是gbk）编码就为494F，即我们得出的结果，而上对应的Unicode编码为4E0A，我们可以将gbk-->decode-->Unicode。

# 六、Python2中代码  # 七、coding:gbk  x = '上'.decode('gbk') y = '下'.decode('gbk') print([x, y])  # [u'\u4e0a', u'\u4e0b']

7.0.2 Unicode类型

当Python解释器执行到产生字符串的代码时（例如s=u'林'），会申请新的内存地址，然后将'林'以Unicode的格式存放到新的内存空间中，所以s只能encode，不能decode。

# 八、Python2中代码  # 九、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格式的数据来说，无论怎么打印，都不会乱码

Unicode这么好，不会乱码，那Python2为何还那么别扭，搞一个str出来呢？Python诞生之时，Unicode并未像今天这样普及，很明显，好的东西你能看得见，龟叔早就看见了，龟叔在Python3中将str直接存成Unicode，我们定义一个str，无需是否加u前缀，就是一个Unicode，屌不屌？

9.1 Python3

Python3中str都是Unicode编码的，所以Python3中的str类型的数据可以编码成其他字符编码的格式，编码的结果为bytes类型。

# coding:gbk x = '上'  # 当程序执行时，无需加u，'上'也会被以Unicode形式保存新的内存空间中,  print(f"type(x): {type(x)}")  # <class 'str'>  # x可以直接encode成任意编码格式 print(f"x.encode('gbk'): {x.encode('gbk')}")  # b'\xc9\xcf' print(f"type(x.encode('gbk')): {type(x.encode('gbk'))}")  # <class 'bytes'> type(x): <class 'str'> x.encode('gbk'): b'\xc9\xcf' type(x.encode('gbk')): <class 'bytes'>

很重要的一点是：看到Python3中x.encode('gbk') 的结果\xc9\xcf正是Python2中的str类型的值，而在Python3是bytes类型，在Python2中则是str类型。

文件的三种打开模式

件操作的基础模式有三种（默认的操作模式为r模式）：

• r模式为read
• w模式为write
• a模式为append

文件读写内容的格式有两种（默认的读写内容的模式为b模式）：

• t模式为text
• b模式为bytes

需要注意的是：t、b这两种模式均不能单独使用，都需要与r/w/a之一连用。

一、文件打开模式之r模式

r: read，只读模式，只能读不能写，文件不存在时报错。

f = open('32.txt', mode='r')  # 报错 f.write() f.close() # rt: read by text # windows的操作系统默认编码为gbk，因此需要使用utf8编码 f = open('32.txt', mode='rt', encoding='utf8') data = f.read() print(data) print(f"type(data): {type(data)}") f.close() aaa bbb ccc nick最帅吗 type(data): <class 'str'> # rb: read by bytes f = open('32.txt', mode='rb') data = f.read() print(data) print(f"type(data): {type(data)}") f.close() b'aaa\nbbb\nccc\nnick\xe6\x9c\x80\xe5\xb8\x85\xe5\x90\x97' type(data): <class 'bytes'>

f.read()读取文件指针会跑到文件的末端，如果再一次读取，读取的将是空格。

f = open('32.txt', mode='rt', encoding='utf8') data1 = f.read() data2 = f.read() print(f"data1: {data1}") print(f"data2: {data2}") f.close() data1: aaa bbb ccc nick最帅吗 data2: 

由于f.read()一次性读取文件的所有内容，如果文件非常大的话，可能会造成内存爆掉，即电脑卡死。因此可以使用f.readline()/f.readlines()读取文件内容。

# f.readline()/f.readlines() f = open('32.txt', mode='rt', encoding='utf8') print(f"f.readable(): {f.readable()}")  # 判断文件是否可读 data1 = f.readline() data2 = f.readlines() print(f"data1: {data1}") print(f"data2: {data2}") f.close() f.readable(): True data1: aaa  data2: ['bbb\n', 'ccc\n', 'nick最帅吗']

二、文件打开模式之w模式

w: 只能写，不能读，文件存在的时候回清空文件后再写入内容；文件不存在的时候会创建文件后写入内容。

# wt f = open('34w.txt', mode='wt', encoding='utf8') print(f"f.readable(): {f.readable()}") f.write('nick 真帅呀\n')  # '\n'是换行符 f.write('nick,nick, you drop, I drop.') f.write('nick 帅的我五体投地') f.flush()  # 立刻将文件内容从内存刷到硬盘 f.close() f.readable(): False # wb f = open('34a.txt', mode='wb') f.write('nick 帅的我五体投地'.encode('unicode_escape'))  # 编码成bytes类型 print(     f"type('nick 帅的我五体投地'.encode('unicode_escape')): {type('nick 帅的我五体投地'.encode('unicode_escape'))}") f.close() type('nick 帅的我五体投地'.encode('unicode_escape')): <class 'bytes'>

三、文件打开模式之a模式

a: 可以追加。文件存在，则在文件的末端写入内容；文件不存在的时候会创建文件后写入内容。

# at f = open('34a.txt', mode='at', encoding='utf8') print(f"f.readable(): {f.readable()}") f.write('nick 真帅呀\n')  # '\n'是换行符 f.write('nick,nick, you drop, I drop.') f.write('nick 帅的我五体投地') f.close() f.readable(): False

四、文件打开读取二进制

b模式是通用的模式，因为所有的文件在硬盘中都是以二进制的形式存储的，需要注意

来源：https://www.cnblogs.com/TMesh-python/p/11316999.html