字符编码详解

忽如一夜春风来-

已于 2022-09-06 09:08:49 修改

阅读量223

点赞数

分类专栏： python 文章标签： pycharm ide python

于 2022-09-06 08:57:13 首次发布

本文链接：https://blog.csdn.net/weixin_46012855/article/details/126717319

版权

python 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1：知识储备

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

1.1：三大核心硬件

#1、软件运行前，软件的代码及其相关数据都是存放于硬盘中的

#2、任何软件的启动都是将数据从硬盘中读入内存，然后cpu从内存中取出指令并执行

#3、软件运行过程中产生的数据最先都是存放于内存中的，若想永久保存软件产生的数据，则需要将数据由内存写入硬盘

请添加图片描述

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

#阶段1、启动一个文件编辑器（文本编辑器如nodepad++，pycharm，word）

#阶段2、文件编辑器会将文件内容从硬盘读入内存

#阶段3、文本编辑器会将刚刚读入内存中的内容显示到屏幕上

1.3：Python解释器执行文件的流程

以python test.py为例，执行流程如下

#阶段1、启动python解释器，此时就相当于启动了一个文本编辑器

#阶段2、python解释器相当于文本编辑器，从硬盘上将test.py的内容读入到内存中

#阶段3、python解释器解释执行刚刚读入的内存的内容，开始识别python语法

1.4：总结

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

#1、相同点：前两个阶段二者完全一致，都是将硬盘中文件的内容读入内存，详解如下
python解释器是解释执行文件内容的，因而python解释器具备读py文件的功能，这一点与文本编辑器一样

#2、不同点：在阶段3时，针对内存中读入的内容处理方式不同，详解如下
文本编辑器将文件内容读入内存后，是为了显示或者编辑，根本不去理会python的语法，而python解释器将文件内容读入内存后，可不是为了给你瞅一眼python代码写的啥，而是为了执行python代码、会识别python语法）

2：字符编码介绍

2.1：什么是字符编码？

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

而计算机只能识别二进制数,详解如下

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

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

请添加图片描述

翻译的过程必须参照一个特定的标准，该标准称之为字符编码表，该表上存放的就是字符与数字一一对应的关系。

字符编码中的编码指的是翻译或者转换的意思，即将人能理解的字符翻译成计算机能识别的数字，即二进制数。

2.2：字符编码表的发展史（了解）

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

2.2.1：阶段一：一家独大

现代计算机起源于美国，所以最先考虑仅仅是让计算机识别英文字符，于是诞生了ASCII表

# ASCII表的特点:
    1、只有英文字符与数字的一一对应关系
    2、一个英文字符对应1Bytes，1Bytes=8bit(位)，8bit最多包含256个数字，可以对应256个字符，足够表示所有英文字符

其实二进制，也就是2的7次方128，也就是说7bit(位)就已经能够包绝大部分字符了，ASCII表也就127位，ASCII表用8bit的原因是考虑到后续可能有新的字符需要加入编码表中，所以另外128位是预留的。

请添加图片描述

2.2.2：阶段二：诸侯割据、天下大乱

请添加图片描述

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

# GBK表的特点：
    1、只有中文字符、英文字符与数字的一一对应关系
    2、一个英文字符对应1Bytes
       一个中文字符对应2Bytes   
       补充说明：
       1Bytes=8bit，8bit最多包含256个数字，可以对应256个字符，足够表示所有英文字符
       2Bytes=16bit，2的16次方最多包含65536个数字，可以对应65536个字符，足够表示所有中文字符

每个国家都各自的字符，为让计算机能够识别自己国家的字符外加英文字符，各个国家都制定了自己的字符编码表

# Shift_JIS表的特点：
    1、只有日文字符、英文字符与数字的一一对应关系

# Euc-kr表的特点：
    1、只有韩文字符、英文字符与数字的一一对应关系

此时,美国人用的计算机里使用字符编码标准是ASCII、中国人用的计算机里使用字符编码标准是GBK、日本人用的计算机里使用字符编码标准是Shift_JIS,如下图所示，

请添加图片描述

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

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

文本文件内容全都为字符，无论存取都是涉及到字符编码问题
#1、存文本文件
人类通过文本编辑器输入的字符会被转化成ASCII格式的二进制存放于内存中，如果需要永久保存，则直接将内存中的ASCII格式的二进制写入硬盘

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

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

2.2.3：阶段三：分久必合

请添加图片描述

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

#1. 存在所有语言中的所有字符与数字的一一对应关系,即兼容万国字符

#2. 与传统的字符编码的二进制数都有对应关系，详解如下

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

请添加图片描述

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

# 英文字符可以被ASCII识别
文本编辑器：英文字符--->内存：unciode格式的数字--->硬盘：ASCII格式的数字

# 中文字符、英文字符可以被GBK识别
文本编辑器：中文字符、英文字符--->内存：unicode格式的数字--->硬盘：gbk格式的数字

# 日文字符、英文字符可以被shift-JIS识别
文本编辑器：日文字符、英文字符--->内存：unicode格式的数字--->硬盘：shift-JIS格式的数字

2.4：编码与解码

由字符转换成内存中的unicode，以及由unicode转换成其他编码的过程，都称为编码encode。
简单理解顺序就是从编辑器》内存》硬盘

请添加图片描述

由内存中的unicode转换成字符，以及由其他编码转换成unicode的过程，都称为解码decode
简单理解顺序就是从硬盘》内存》编辑器

请添加图片描述

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

编码/解码流程图：

请添加图片描述

2.5：utf-8的由来

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

#多国字符—√—》内存（unicode格式的二进制）——X—》硬盘（GBK格式的二进制）

#多国字符—√—》内存（unicode格式的二进制）——X—》硬盘（Shift_JIS格式的二进制）

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

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

# 多国字符—√—》内存（unicode格式的二进制）——√—》硬盘（utf-8格式的二进制）

请添加图片描述

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

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

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

2.6：总结：

2.6.1：历史

第一阶段：

	第一个字符编码是ASCII只能支持英文了一些其他符号，由美国制定的，因为第一台计算机也是在美国诞生的。那时候只有ASCII格式，所以一家独大，所有计算机使用的都是ASCII格式的字符编码

第二阶段：

   	很多国家也开始使用计算机，发现ASCII格式无法支持它们自己本国的字符，所以就都自己去制定了自己的字符编码，比如中国的GBK(只支持中文、英文)、日本的Shift_JIS(只支持日文、英文)，这里提一嘴，几乎所有其他国家的字符编码至少都是支持英文的。
   	
	这时候就导致了，使用GBK格式的计算机无法使用日文，使用Shift_JIS格式无法使用中文，各国自己制定的字符编码互不兼容，只能与英语兼容，这就导致比如中国卖电脑给日本，发现中国的电脑是GBK格式，日本人将日文打到编辑器变成乱码。

第三阶段：

	因为多国字符编码互不兼容的问题，于是国际标准化组织(ISO)制定了一个通用的字符编码unicode。unicode字符编码可以支持多国的字符，既支持中文也日文，这解决了多个国家的字符编码兼容性问题。但又有一个问题，那就是其他国家当时很多程序在硬盘中都是使用自己本国制定的字符编码格式编码后的二进制数据，比如中国的GBK，于是被逼无奈unicode又能够兼容其他国家制定的字符编码。
	 
	 如果在文本编辑器中使用GBK格式输入中文会将中文编码成unicode格式的二进制数存放在内存当中，一旦Ctrl+s保存后，会将内存中的unicode格式的二进制数据编码成GBK格式的二进制数据存放在硬盘当中。那如果你编辑器使用GBK结果输入一个日文，这个时候这个日文在内存中是可以使用unicode字符编码的，因为unicode支持多国的字符，但如果Ctrl+s保存后，就会将unicode的二进制数据在编码成GBK格式的二进制数据存放在硬盘当中，此时问题就出现了，虽然内存中unicode能够支持日文，但编码成 unicode格式后的二进制数据只是在内存当中，早晚需要放入硬盘中，保存时就会出现问题，GBK不支持日文，所以数据被存乱了，数据也就无了，所以读的时候就是乱码。
	 
	 有人有疑问，既然GBK能够解码成 unicode，Shift-JIS也能解码成 unicode，那能通过内存中的unicode互相转换吗，将GBK解码成Shift-JIS，很遗憾想法是好的，结果是不能，因为要清楚，GBK字符编码的二进制和Shift-JIS字符编码的二进制数据原本就不能互相解码，如果是英文，这是没问题的，因为GBK和Shift-JIS都支持英文。那当需要读取磁盘中以GBK字符编码 编码的二进制数据存放在内存中，会必须将GBK字符编码进行一个解码转成unicode字符编码二进制数，在将内存中的unicode二进制数据再解码展现人类的字符。
    
    最后还有一个人有疑问，那为什么硬盘和内存不直接都使用unicode呢？这样连转都不用转了，更加方便，当需要注意unicode不管你是中文字符还是英文字符还是日语字符，他都是以2Bytes存放的，我们的英文其实就只需要1Bytes存放，结果却使用了2Bytes存放，这就导致硬盘的浪费，但这不是最致命的，最主要的是I/O速度，在读取和存入的时候时间肯定也会增加。于是后面又出现了utf-8来解决这个问题。

2.6.2：utf-8

	utf-8也可以支持多国字符，输入一个中文时，还在内存中使用unicode字符编码，Ctrl+s保存后在将unicode字符编码 编码成utf8字符编码的二进制数据存放在硬盘中。utf-8和unicode不一样，他已经给英文、中文等不同字符制定了不同存储大小，比如中文使用3个Bytes，英文则使1个Bytes，所以存储大小并不是固定的而是根据字符类型来决定的，这就解决了unicode编码存储大小固定导致I/O慢的问题。
    utf-8字符编码能够解决unicode字符编码I/O慢问题，那为何内存不直接和硬盘一样使用unicode字符编码？原因是目前可能还有一些程序、或者一些数据在硬盘中是以自己国家制定的字符编码二进制存放的，假设是GBK，如果内存使用utf-8就会导致无法与GBK编译的二进制进行转换，因为utf-8并不兼容其他国家制定的字符编码，而是将其他国家的字符重新指定了一个规则。而unicode字符编码是既兼容其他国家的字符编码，也可以支持utf-8，而刚好utf-8啥国家的字符都支持，所以是可以互相转换的。
    字符编码未来的发展内存一定是会由unicode转向utf-8的，统一标准，现在还不行，需要先让以前其他国家自己制定的字符编码慢慢淘汰，没人在使用这些老的字符编码来存放程序到硬盘中，全都使用utf-8编码来存放，这个时候内存才可以将unicode字符编码替换成utf-8字符编码。其实兜兜转转又变成了一家独大，只不过这个一家独大的字符编码是一个万国都可以字符都可以兼容的字符编码。

3：字符编码的应用

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

#1、内存中固定使用unicode无论输入任何字符都不会发生乱码

#2、我们能够修改的是存/取硬盘的字符编码方式，如果字符编码设置不正确将会出现乱码问题。乱码问题分为两种：存乱了，读乱了

#2.1 存乱了：如果用户输入的内容中包含中文和日文字符，如果单纯以shift_JIS存，日文可以正常写入硬盘，而由于中文字符在shift_jis中没有找到对应关系而导致存乱了

#2.2 读乱了：如果硬盘中的数据是shift_JIS格式存储的，采GBK格式读入内存就读乱了

总结：

#1. 保证存的时候不乱：在由内存写入硬盘时，必须将编码格式设置为支持所输入字符的编码格式
#2. 保证读的时候不乱：在由硬盘读入内存时，必须采用与写入硬盘时相同的编码格式

3.1 文本编辑器nodpad++存取文本文件

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

3.1.1：存乱了：

1、创建一个新文本，输入中文和日文，将utf-8编码换成日文的Shift-JIS字符编码，然后Ctrl+s保存

保存后发现中文并没有乱码的原因是因为现在这个数据在硬盘和内存中都有，现在读取到的是在内存当中，unicode支持中文和日文，所以不会乱码，当我们关闭文本，重新打开后，变成Shift-JIS解码成unicode的时候就会发现乱码了。

请添加图片描述

2、关闭文本，重新使用notepad++打开

重新打开后可以看到是中文变成了一个问号，这个是乱码了，这个时候数据是已经无了，已经变成了一些没用的数据了，就算以GBK字符编码来解码也木得用

3.1.2：读乱了：

1、默认是utf-8存和读，输入中文Ctrl+s保存

默认notepad++的字符编码是utf-8既可以存也可以读

请添加图片描述

2、保存后将字符编码在改成GBK

中文原本是存放在内存中字符编码unicode，后保存到磁盘编码成utf-8。

当读取的时候，需要解码，从硬盘中由utf-8解码成unicode放入内存，再由unicode解码成认类能看懂的字符在notepad++中

这里我们却设置成了GBK来解码一个用utf-8字符编码的文本，这肯定是有问题的，因为GBK和utf-8压根就不兼容，GBK不认识utf-8的二进制，所以乱码了。

请添加图片描述

3、重新将编码换成utf-8

将解码方式转换成了utf-8的方式就能成功解码以utf-8的方式存放的文本了。

请添加图片描述

3.1.3：总结：

# 文本用什么字符编码存的就必须用什么字符编码取
# 以上是解决了notepad++的执行过程前两个阶段不乱码的问题。

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

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

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

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

解释器会先用默认的字符编码方式读取文件的首行内容，由于首行是纯英文组成，而任何字符编码方式都可以识别英文字符。
读取到#coding后接下来的代码就会以conding声明的字符编码来执行下面的代码。

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

设置文件头的作用是保证运行python程序的前两个阶段不乱码，经过前两个阶段后py文件的内容都会以unicode格式存放于内存中。

在经历第三个阶段时开始识别python语法，当遇到特定的语法name = ‘上’ 字符类型（代码本身也都全都是unicode格式存的）时，需要申请内存空间来存储字符串’上’，这就又涉及到应该以什么字符编码存储‘上’的问题了。

字符类型指的是数字、浮点、字符、列表、元组、字典、集合都算，区分开来的就是图片、视频那种格式，字符类型(str)，也就是说它们在内存(unicode)中也是字符类型。Python解释器代码中区分其他类型的方法就是Python会从内存中取出str类型，在根据里面的值自动转换成对应的类型，比如数字，就会转成int或者float类型），有一个eval内置函数就是干这事的。

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

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

# coding:utf-8
x = '上' # x的值为untf-8格式的二进制
print(x) 
# 打印操作是将x的值，即utf-8格式的二进制交给终端，当终端收到后发现并不是unicode（只有unicode才与字符有对应关系），所以终端会执行操作：内存utf-8二进制---解码-->内存unicode格式的二进制，解码的过程终端(pycharm、cmd)会采用自己默认的编码格式，而在pycharm的终端默认编码为utf-8、windows下的cmd终端的默认编码为gbk，这就导致cmd终端会认为x中的字符类型的值是gbk类型的编码格式二进制，所以该打印操作在pycharm中显示正常，而在windows下的cmd中则乱码

# 在windows下的cmd中运行效果如下
C:\Users\Administrator>python2 E:\aaa.py
涓

python2后推出了一种补救措施，就是在字符串类型前加u，则会将字符串类型强制存储unicode在内存中，这就与python3保持一致了，对于unicode格式无论丢给任何终端进行打印，都可以直接对应字符不会出现乱码问题，因为已经是unicode编码了，所有字符编码都支持unicode编码格式，就变成了python3哪种

# coding:utf-8
x = u'上' # 即便文件头为utf-8，x的值依然存成unicode

3.4：字符串encode编码与decode解码的使用

Python2 模拟unicode和转成其他编码格式互相转换

# 1、unicode格式------编码encode-------->其它编码格式
>>> x='上' 
# 在python3在'上'被存成unicode的字符编码到内存中
>>> res=x.encode('utf-8')   #《==将内存中的unicode编码格式转换成了utf-8格式来存放到硬盘当中
>>> res,type(res) 
(b'\xe4\xb8\x8a', <class 'bytes'>)
# unicode编码成了utf-8格式，而编码的结果为bytes类型，可以当作直接当作二进制去使用。


# 2、其它编码格式------解码decode-------->unicode格式
>>> res.decode('utf-8')   #《==用的什么编码，就需要用什么解码，这个动作其实就是从硬盘中将utf-8编码格式转换成unicode编码格式放在内存中。
'上'

###编码、解码这种手动指定的方式通常用于与老平台对接，可能老平台中编写的代码只能识别utf-8字符编码或者其他的字符编码，这就需要encode将其改为对应的字符编码。
###另外就是我们在读内存中的值的时候，内存中的值肯定会转成unicode格式，而在使用print(x)取得时候，按理来说取出来的应该是unicode格式的数字，这个是因为python解释器在里面优化了，也就是说在读取unicode格式的数字时，会直接转换成对应认类可读的值。

3.5：如何解决python2乱码问题

#coding: 与文件存得字符编码一致

3.6：如何解决python3乱码问题

#config: 与文件存得字符编码一致

x=u"上"

3.7：pycharm中的模板问题

请添加图片描述

可以手动设置模板，这样每次创建py文件的时候就会自动生成这些东西了，这里注释中的是一些描述和变量，这个不重要，重要的是最上面两个

#!/usr/bin/env python3.8

	它在windows中没啥用，它是用在linux上的，我们在linux平台中执行一个python文件，需要调用python解释器来执行，于是就需要指定python解释器绝对路径去执行file.py，但有些人觉得太麻烦，就直接使用./file.py这样执行，这样执行的话就会导致操作系统不知道这个file.py文件用哪一个解释器来执行的。我们这时候就可以在file.py文件中先声明好python解释器程序的绝对路径，操作系统就知道找哪个解释器了。
    上面这种方法也有一个弊端，如果不晓得python解释器在哪个路径就会很麻烦，于是我们可以使用env，env可以显示出python解释器程序的完整路径，上图中就是借用了env，这样就不需要担心找不到python解释器了

# -*- coding:utf-8 -*-

	声明字符编码格式，这个和我们前面不太一样，左右都加了一个-*-，这其实是花里胡哨，这样也可以，只不过生效的还是#coding:utf-8

4：Windows7与Windows10

最后解释一下Windows7和Windows10之间默认采用哪种字符编码格式读解码/写编码。

Windows7

# 默认Windows7的记事本使用ANSI字符编码格式，注意ANSI字符编码并不是ASCII字符编码，而是GBK字符编码，ANSI字符编码格式是比较独特的，只有Windows平台有这种
# 其实日本、韩国、美国、中国所有Windows7默认使用的字符编码就是ANSI，难道ANSI也是万国字符编码？其实不然
# ANSI不能说它是具体某一个字符编码格式，而是先当与一个别名，我们中国的Windows操作系统的电脑中，ANSI就是GBK，而日本的Windows操作系统的电脑中，ANSI就是Shift-JIS，在美国，ANSI就是ASCII。
# 其实啊，ASCII本质就是一个显示作用，真正的字符编码其实就是各国自己指定的字符编码格式。
# Windows7 默认的字符编码格式就是GBK格式，可以在cmd中输入chcp就能看到936，这个代码就是GBK的代码。【提一嘴，utf8的代码是65001】

# 有人在Windows7中保存文件字符编码格式的时候使用的是utf-8格式，但打开的时候不还是没有乱码吗，gbk难道能够解码utf-8编码的二进制？\
	#其实这个问题，我们操作系统确实使用的是gbk字符编码，但要注意，你使用的是什么打开的，你使用的是记事本程序、或者notepad++程序，解码是由这些文本编辑器来完     成的，有了文本编辑器就不需要Windows操作系统来解码了，现在很多文本编辑器很智能【除了Windows自带的编辑器】，会检测你文件中使用的数据是什么格式的字符编码格式就会转成什么格式的解码格式，最后解码成unicode格式存入内存中，最后子从内存中unicode解码成认类可读的格式，也就是我们看到的字符串。
   	# 如果想要实验，可以打开powershell，使用cat命令去查看，powershell也是使用Windows10自己的gbk格式，去读取用windows10自带的文本编辑器保存的文件肯定会乱码，因为自带的文本编辑器保存是utf8编码的格式，gbk无法解码utf8的数据，所以会乱码，但如果在windows7当中，这一操作不会影响，因为windows7自带的文本编辑器默认用的就是ANSI编码，该编码前面介绍过了就不再介绍了。

请添加图片描述

Windows10

# 默认Windows10使用的记事本字符编码是utf-8，这个没啥好讲的，前面都讲过
# Windows10 默认的字符编码格式也是GBK格式，可以在cmd中输入chcp就能看到936，这个代码就是GBK的代码。

这里提一嘴，为什么要强调windows7和windows10它们的编码/解码格式，因为后面学到文件处理的时候，用的可不是notepad++、记事本这些文本编辑器来解码，而是真真正正使用操作系统自己的字符编码来解码，图中就会出现问题，这里先保留一下。

5：坑壁操作

请添加图片描述

上面这一步千万不要做，你在pycharm的时候可能会用到os.system这个工具，这个工具的作用就是用来执行cmd中的命令，将显示结果打印到pycharm中，这个时候就需要尤为注意，命令最终是在cmd中执行的，在cmd中执行也就意味着cmd使用gbk打开的，这不仅是cmd的字符编码格式，也就是Windows的，os.system这一操作相当于把cmd输出的结果在输出到pycharm中，而这是数据是gbk格式得，但pycharm默认使用的是utf8，utf8可不能解码gbk格式得字符，所以就会乱码。

有些人为了解决上面的问题，可能就会尝试这一操作，这一操作在Windows中可能会导致你pycharm无法启动！！！亲身经历！！！