python文件处理之编码字符

一、储备知识

引入

字符串类型、文本文件的内容都是由字符组成的，但凡涉及到字符的存取，都需要考虑字符编码的问题。

字符编码的这个知识点的特性就是理论多、结论少，下面就让们来一点点介绍他吧！

三大核心硬件

所有软件都是运行硬件之上的，与运行软件相关的三大核心硬件为CPU、内存、硬盘。我们需要明确三点：

1. 运行软件前，软件的代码及其相关数据都是存放于硬盘中的
2. 在任何软件的启动都是将数据从硬盘中读入内存，然后CPU从内存中取出指令并执行
3. 软件运行过程中产生的数据最先都是存放于内存中的，若想永久保存软件产生的数据，则需要将数据由内存写入硬盘。

文本编辑器读取文件内容的流程

1. 启动一个文件编辑器（文本编辑器如nodepad++，pycharm，word）
2. 文件编辑器会将文件的内容从硬盘读入内存
3. 文本编辑器会将刚刚读入内存的内容显示到屏幕上

python解释器执行文件的流程

1. 启动python解释器，此时就相当于启动了一个文本编辑器
2. python解释器相当于文本编辑器，从硬盘上将文本内容读入到内存中
3. python解释器解释执行刚刚读入内存的内容，开始识别python语法

总结

python解释器与文件文本编辑器的异同如下：

1. 相同点：前两个阶段二者完全一样，都是将硬盘中的文件的内容读入内存
   • python解释器会解释执行文件内容，因而python解释器具备读py文件的功能，这一点与文本编辑器一样
2. 不同点：阶段三时，针对内存读入的内容处理方式不同
   • 文本编辑器将文件读入内存后，是为了显示或者编辑，根本不理会python的语法，而python解释器将文件内容读入到内存后，可不是为了给你瞅一眼python代码写的啥，而是为了执行python代码、会识别python语法

二、字符编码介绍

什么是字符编码？

人类与计算机交互时，用的都是人类能读懂的字符，如中文字符、英文字符、日文字符等

而计算机只能识别二进制数。

• 二进制数即由0和1组成的数字，例如010010101010。计算机是基于电工作的，电的特性即高低电平，人类从逻辑层面将高电平对应为数字1,低电平对应为数字0，这直接决定了计算机可以识别的是由0和1组成的数字

毫无疑问，由人类的字符到计算机中的数字，必须经历一个过程，如下

• 文字符号=编码(翻译)===>数字
• 文字符号<====解码 (翻译)========数字

什么是字符编码表？

就是一张字符与数字对应的关系表

字符编码的发展历史（了解）

字符编码的发展经历了三个重要的阶段，如下

阶段一：一家独大（ASCII）

ASCII表的特点：

1. 只有英文字符与数字的一一对应关系
2. 一个英文字符对应1Bytes，1Bytes=8bit，8bit最多包含256个数字，可以对应256个字符，足够表示所有英文字符

阶段二：诸侯割据、天下大乱（ASCII、GBK、Shift-JIS）

为了让计算机能够识别中文和英文，中国人定制了GBK

GBK表的特点：

1. 只有中文字符、英文字符与数字的一一对应关系

2. 采用8位二进制数（1Bytes）对应一个英文字符，采用16位二进制数（2Bytes）对应一个中文字符。

   补充说明：

   • 1Bytes=8bit，8bit最多包含256个数字，可以对应256个字符，足够表示所有英文字符
   • 2Bytes=16bit，16bit最多包含65536个数字，可以对应65536个字符，足够表示所有中文字符

为让计算机能够识别自己国家的字符外加英文字符，各个国家都制定了自己的字符编码表。此时,美国人用的计算机里使用字符编码标准是ASCII、中国人用的计算机里使用字符编码标准是GBK、日本人用的计算机里使用字符编码标准是Shift_JIS

Shift_JIS表的特点：

1. 只有日文字符、英文字符与数字的一一对应关系

Euc-kr表的特点：

1. 只有韩文字符、英文字符与数字的一一对应关系

字符编码发展到了这个阶段，可以用一句话概括：诸侯割据、天下大乱，详解如下

图1中，文本编辑存取文件的原理如下

文本文件内容全都为字符，无论存取都是涉及到字符编码问题

1、存文本文件

人类通过文本编辑器输入的字符会被转化成ASCII格式的二进制存放于内存中，如果需要永久保存，则直接将内存中的ASCII格式的二进制写入硬盘

2、读文本文件
直接将硬盘中的ASCII格式的二进制读入内存，然后通过ASCII表反解成英文字符

图2图3都是相同的过程，此时无论是存还是取由于采用的字符编码表一样，所以肯定不会出现乱码问题，但问题是在美国人用的计算机里只能输入英文字符，而在中国人用的计算机里只能输入中文字符和英文字符…,毫无疑问我们希望计算机允许我们输入万国字符均可识别、不乱码，而现阶段计算机采用的字符编码ASCII、GBK、Shift_JIS都无法识别万国字符，所以我们必须定制一个兼容万国字符的编码表，请看阶段三

阶段三：分久必和unicode

unicode于1990年开始研发，1994年正式公布，具备两大特点：

1. 存在所有语言中的所有字符与数字的一一对应关系,即兼容万国字符
2. 与传统的字符编码的二进制数都有对应关系，采用16位二进制数（2Bytes）对应一个字符（注意：2个字节无论是对英文还是中文都是对于1个字符），个别生僻字采用4Byets、8Bytes。详解如下

很多地方或老的系统、应用软件仍会采用各种各样传统的编码，这是历史遗留问题。此处需要强调：软件是存放于硬盘的，而运行软件是要将软件加载到内存的，面对硬盘中存放的各种传统编码的软件，想让我们的计算机能够将它们全都正常运行而不出现乱码，内存中必须有一种兼容万国的编码，并且该编码需要与其他编码有相对应的映射/转换关系，这就是unicode的第二大特点产生的缘由

文本编辑器输入任何字符都是最新存在于内存中，是unicode编码的，存放于硬盘中，则可以转换成任意其他编码，只要该编码可以支持相应的字符

英文字符可以被ASCII识别

• 英文字符—>unciode格式的数字—>ASCII格式的数字

中文字符、英文字符可以被GBK识别

• 中文字符、英文字符—>unicode格式的数字—>gbk格式的数字

日文字符、英文字符可以被shift-JIS识别

• 日文字符、英文字符—>unicode格式的数字—>shift-JIS格式的数字

总结，为什么说unicde是过渡版本？

1. 对应万国码
2. 最重要的是，也就是说，目前unicode主要是争对于老的版本的兼容性，老版本的硬盘中的编码格式慢慢没了，它就没有意义了，这个时候内存就可以使用utf-8了。

编码与解码（重点）

**编码：**由字符转换成内存中的unicode，以及由unicode转换成其他编码的过程，都称为编码encode

**解码：**由内存中的unicode转换成字符，以及由其他编码转换成unicode的过程，都称为解码decode

在诸多文件类型中，只有文本文件的内存是由字符组成的，因而文本文件的存取也涉及到字符编码的问题

utf-8的由来

特点：采用8位二进制数（1Bytes)对应一个英文字符，采用24位二进制数（3Bytes）对应一个中文字符。

注意：如果保存到硬盘的是GBK格式二进制，当初用户输入的字符只能是中文或英文，同理如果保存到硬盘的是Shift_JIS格式二进制，当初用户输入的字符只能是日文或英文……如果我们输入的字符中包含多国字符，那么该如何处理？

多国字符—淘小欣—》内存（unicode格式的二进制）——淘小欣—》硬盘（GBK格式的二进制）

多国字符—淘小欣—》内存（unicode格式的二进制）——欣をからかう—》硬盘（Shift_JIS格式的二进制）

多国字符—淘小欣—》内存（unicode格式的二进制）——淘小欣—》硬盘（???格式的二进制）

理论上是可以将内存中unicode格式的二进制直接存放于硬盘中的，但由于unicode固定使用两个字节来存储一个字符，如果多国字符中包含大量的英文字符时，使用unicode格式存放会额外占用一倍空间（英文字符其实只需要用一个字节存放即可），然而空间占用并不是最致命的问题，**最致命地是当我们由内存写入硬盘时会额外耗费一倍的时间，**所以将内存中的unicode二进制写入硬盘或者基于网络传输时必须将其转换成一种精简的格式，这种格式即utf-8（全称Unicode Transformation Format，即unicode的转换格式）

那为何内存中不直接utf-8呢？

utf-8是针对Unicode的可变长度字符编码：一个英文字符占1Bytes，一个中文字符占3Bytes，生僻字用更多的Bytes存储

unicode更像是一个过渡版本，我们新开发的软件或文件存入硬盘都采用utf-8格式，等过去几十年，所有老编码的文件都淘汰掉之后，会出现一个令人开心的场景，即硬盘里放的都是utf-8格式，此时unicode便可以退出历史舞台，内存里也改用utf-8，天下重新归于统一

总结字符编码：

字符编码对应字符关系：

• ASCLL:只采用1个字节对应一个英文字符
• GBK:采用1个字节对应一个英文字符，采用2个字节对应一个中文字符。
• unicode：采用2个字节对应一个字符，生僻字采用4个字节、8个字节。(注意：无论是英文还是中文，都是采用2个字符)
• utf-8：采用1个字节对应一个英文字符，采用3个字节对应一个中文字符。

目前内存使用的编码：Unicode

• 注意：unicode兼容万国码，与万国字符都有对应关系。

• unicode有2个作用：

  1.兼容万国字符

  2.兼容万国字符编码表对应关系（unicode妥协于此，也就是它目前存在的主要作用）

目前硬盘中使用的编码：utf-8、GBK、Shift-JIS

内存固定使用的Unicode，我们可以改变的是存入硬盘采用的格式

• 英文+汉字（文本编辑器）=》Unicode（内存）=》GBK（硬盘）
• 英文+日文（文本编辑器）=》Unicode（内存）=》shift-jis（硬盘）
• 万国字符（文本编辑器）=》Unicode（内存）==》utf-8（硬盘）

注意：字符编码之间不可以进行转换。列如：GBK不能转成ASCII，因为这两种字符表的对应关系不一样。但是字符编码之间可以使用unicode作为中间介质，可以进行读写操作。

字符编码的应用

我们学习字符编码就是为了存取字符时不发生乱码问题：

1. 内存中固定使用unicode无论输入任何字符都不会发生乱码
2. 我们能够修改的是存/取硬盘的编码方式，如果编码设置不正确将会出现乱码问题。乱码问题分为两种：存乱了，读乱了
3. 存乱了：如果用户输入的内容中包含中文和日文字符，如果单纯以shift_JIS存，日文可以正常写入硬盘，而由于中文字符在shift_jis中没有找到对应关系而导致存乱了
4. 读乱了：如果硬盘中的数据是shift_JIS格式存储的，采GBK格式读入内存就读乱了

总结文件存、取乱码问题：

保证存的时候不乱：

• 致命性：存乱了具有致命性，也就是说当你存文件使用的是日文，而你使用GBK存入硬盘，这个时候你的硬盘并没有对应这种编码格式，这个时候当你保存存入硬盘重新打开文件，文件内容直接损坏了，数据也就不存在了。
• 解决：在由内存写入硬盘时，你的文件中的字符，必须与存入硬盘所指定的编码格式有所对应。（比如：你使用GBK存入硬盘，但是你文件中输入字符是日文，这就不行。因为GBK只支持中文和英文字符。）

保证读的时候不乱

• 致命性：取乱了并不一定致命，你当初用什么格式存的，那么你就用什么格式取就可以。
• 解决：在由硬盘读入内存时，文件用什么编码格式存入硬盘的，就应该用什么编码格式读入内存。

文本编辑器nodpad++存取文本文件实例

文件编辑器存取都是文本文件，而文本文件中包含的内容全为全为字符，所以文本文件都涉及到字符编码的问题。

以下步骤表示存文本时的乱码

• **步骤：**先不写内容,修改字符编码,复制内容（にほんご、嘿嘿嘿嘿你看不见我、English）,保存到桌面,关闭,打开,把文件拖进去。
• 当你存文件时使用的字符是日文，而你使用GB2312存入硬盘，这个时候你的硬盘并没有对应的这种编码格式，这个时候当你保存存入硬盘重新打开文件，文件内容直接损坏了，数据也就不存在了。如图：

• 现在我用ctrl+s保存，重新打开文件，如图显示：

以下步骤表示取文本时的乱码

python 解释器执行文件的前两个阶段

• 执行py文件的前两个阶段就是python解释器读文本文件的过程，与文本编辑读文本文件的前两个阶段没人任何区别，要保证读不乱码，则必须将python解释器读文件时采用的编码方式设置为文件当初写入硬盘时的编码格式，如果没有设置，python解释器则会用默认的编码方式，在``python3``中默认为``utf-8，在python2中默认为ASCII，我们可以通过指定文件头来修改默认的编码。

• 在文件首行写入包含#号在内的以下内容

  # coding: 当初文件写入硬盘时采用的编码格式
  

• 解释器会先用默认的编码方式读取文件的首行内容，由于首行是纯英文组成，而任何编码方式都可以识别英文字符。

总结：

• python 3默认编码方式：utf-8
• python 2默认编码方式：ASCll
• 为什么要指定解码文件头？
  • 如果你使用的是python3解释器，当python3解释器读取文件时（python3 D:test.py），如果没有指定解码文件头，python3解释器会使用它默认的utf-8的编码对照表去对应test.py这个存放在硬盘的二进制文件。当你存入硬盘的时候时使用GBK编码对照表的二进制形式去存入硬盘的，那么如果这个时候含有中文字符（中文字符在GBK中对应的是2个字节， utf-8对应的中文是3个字节）那么这个时候读取该文件时，就乱码了。
  • 如果你使的是python2解释器，当python2解释器读取文件时（python2 D:test.py），如果没有指定解码文件头，python2解释器会使用它默认的ASCII的编码对照表去对应test.py这个存放在硬盘的二进制文件，而我们所知ASCII只对应着英文字符。当你存入硬盘的时候使用GBK编码对照表的二进制形式去存入硬盘的，那么这个时候如果你的文件中含有中文字符（中文字符在GBK中对应的是2个字节， 而ASCII都没有中文字符的对应只会按照1个字节形式从二进制转换成ASCII码），那么这个时候读取该文件时，就乱码了。
• **解决读取文件时乱码问题:**在文件顶行写上# coding: 当初文件写入硬盘时采用的编码格式 或者使用右?边这种花里胡哨的的玩法 # -*- coding: 当初文件写入硬盘时采用的编码格式 -*-。
• 区分读取文件头和读取文件内容的编码：
  • 读取文件头时：使用的是python解释器默认的编码
  • 读取文件内容时：使用的是文件头部指定的编码格式
  • 为什么读取文件头的时候不会乱码呢？我们需要知道无论是python2解释器还是python3解释器读取文件时，它们默认的英文编码字节对应都是一样的。（ASCII码对应英文字符1个字节，utf-8码对应英文字符也是一个字节）
• 保证python程序前两个阶段不乱码的核心：
  • 你的文本编辑器默认是用什么编码格式存入硬盘的，你就需要指定什么格式的头部解码格式。（比如：你文本编辑器是用utf-8存，那么你就指定头部：#coding:utf-8）

python 解释器执行文件的第三个阶段

设置文件头的作用是保证运行python程序的前两个阶段不乱码，经过前两个阶段后py文件的内容都会以unicode格式存放于内存中。在经历第三个阶段时开始识别python语法，当遇到特定的语法name = ‘上’（代码本身也都全都是unicode格式存的）时，需要申请内存空间来存储字符串’上’，这就又涉及到应该以什么编码存储‘上’的问题了。

在Python3中，字符串类的值都是使用unicode格式来存储

由于Python2的盛行是早于unicode的，因此在Python2中是按照文件头指定的编码来存储字符串类型的值的（如果文件头中没有指定编码，那么解释器会按照它自己默认的编码方式来存储‘上’），所以，这就有可能导致乱码问题

python 2解释语法阶段（第三阶段）导致乱码问题

① 文件头指定gbk、使用pycharm终端(utf-8)

• Unicode关于汉字对应关系表PDF下载链接：点我前往下载

# coding: gbk
# python2中默认ASCII码，上面需要为其指定存入硬盘格式相同的编码格式

x = "上"
print([x], type(x))  # (['\xc9\xcf'], <type 'str'>) 提示：python2中要把x放在列表中打印，才会显示编码格式。直接放到print中，会像下面一样，会进行一个字符转换的处理。

print(x)        # ��
'''
上面为什么执行print(x)操作会乱码，显示成：��？
    打印操作就是将x的值，也就是把gbk格式的二进制（'\xc9\xcf'）交给终端（因为我们文件头指定gbk，所以定义变量时变量的值存入内存中使用的就是gbk编码），当终端接收到以后，发现并不是unicode（只有unicode才与字符有对应关系），但是终端任然会指定操作：gbk --> 解码 --> unicode格式的二进制，解码的过程终端会默认采用自己终端默认的编码。（pycharm的终端默认是utf-8格式，windows中的终端默认是gbk格式），所以该打印操作在pycharm中显示不正常，而在windows命令终端中显示正常。
    
   
    补充：为什么unicode与gbk编码对照表中是'\x49\x4f',而我们终端打印是'\xc9\xcf'？
    我们得从gbk编码的设计者开始说起，gbk对应英文我们知道是1个Bytes（8个进制位），对应中文是2个Bytes(16个二进制位)。
    那么我们想文件是躺在硬盘中对吧，在硬盘中它们全部都是0101啊，你又怎么知道，什么时候读取16个二进制，什么时候是读取8个二进制呢？而设计者们就发明了标识位，用来标识一次性读取二进制位的个数。
    那么怎么读取呢？我们知道1个字节是由8个0101组成，在区分到底是读取16个还是8个的时候，我们在起始位置时就开始判断。如果是该标识位是0，那么读取的就是一个英文字符，一共8个二进制（1bit+7bit=1Bytes）。如果该标识位是1，那么读取的就是一个中文字符，一共16个二进制（1bit+15bit=2Bytes）.通过这种每次读取每次标识，完成了完美的区分中英文字符的对照关系。
'''

• unicode关于汉字的对应关系表截图：?

• 终端打印中‘上’\xc9\xcf 与 unicode中‘上’的正真实数据\x49\x4f 转换关系图：?

② 文件头指定gbk、使用windows终端(gbk)

③ 解决python2中str类型打印终端不乱码

• **前言：**python2中字符串有2种类型。一种str类型：x='上'，一种unicode类型：x=u'上'。
• **保证python2得的字符串类型不乱码：**我们要在字符串前面加小u。加小u在python2中是把这个字符串强制转换成unicode编码。（拓展补充：如果你的字符串中只包含数字或者字母，是可以不必要加小u）。
• **python3中为什么只有字符串类型，要不要加小u？**python3中字符串前面帮我们默认加了小u，我们加不加都是一样，并不影响使用。

4、字符串encode编码与decode解码的使用

x = '上'  # python3中str类型默认前面就加了小u转成unicode，也就是说上默认在python3中在内存中存成了unicode格式我们把上看成unicode就可以了。（这里其实是由字符转换成unicode格式，这叫编码）

res = x.encode("gbk")  # 作用：1、使用encode指定gbk编码由内存写入硬盘。2、基于网络传输及存储。3、有可能要与老平台python2对接，直接unicode交给python2不行，我们这个时候就需要直接编码以后就可以直接丢给对方，对放就可以做相应的处理。{上面我们讲了编码解码的概念，上面说由unicode转换成其它编码格式gbk（GBK）这叫编码。由unicode转成了gbk。}
print(res)  # b'\xc9\xcf'

print(res.decode('gbk'))    # 使用decode指定gbk解码由内存读入硬盘由unicode对应字符显示。{由上面我们讲了编码解码的概念，上面说由其它编码格式gbk（GBK）转换成unicode这叫解码。}

# 注意：你使用什么格式编码的，你就得因该用什么格式解码。

5. 利用bytes解码与str编码

data = 'hello world'

# 字符串转二进制
data_bytes = bytes(data, encoding='utf-8')
print(data_bytes)  # b'hello world'

# 二进制转字符串
data = str(data_bytes, encoding='utf-8')
print(data)  # hello world

三、小结

补充：字符编码只适合用文本文件。并不支持图片，视频等格式。

如何解决python2乱码问题？

1. 指定文件头：#coding：与文件存的编码格式一致
2. 在字符串前面加小u：x=u"上"

如何解决python3乱码问题?

1. 指定文件头：#coding：与文件存的编码格式一致

项目文件头2种写法（注意：只在你的执行主文件中添加即可，因为子文件最终还是会被调到主文件中执行。）:

1. 普通青年写法：#coding：与文件存的编码格式一致
2. 花里胡哨的写法：-*- #coding：与文件存的编码格式一致 -*-