一 了解字符编码的知识储备

一 计算机基础知识

二 文本编辑器存取文件的原理(nodepad++，pycharm，word)

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

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

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

三 python解释器执行py文件的原理 ，例如python test.py

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

#第二阶段：python解释器相当于文本编辑器，去打开test.py文件，从硬盘上将test.py的文件内容读入到内存中(小复习：python的解释性，决定了解释器只关心文件内容，不关心文件后缀名)

#第三阶段：python解释器解释执行刚刚加载到内存中test.py的代码( ps：在该阶段，即真正执行代码时，才会识别python的语法，执行文件内代码，当执行到name="egon"时,会开辟内存空间存放字符串"egon")

四 总结python解释器与文件本编辑的异同

#1、相同点：python解释器是解释执行文件内容的，因而python解释器具备读py文件的功能，这一点与文本编辑器一样

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

二 字符编码介绍

一 什么是字符编码

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

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

必须经过一个过程：

#字符--------(翻译过程)------->数字

#这个过程实际就是一个字符如何对应一个特定数字的标准，这个标准称之为字符编码

二 以下两个场景下涉及到字符编码的问题：

#1、一个python文件中的内容是由一堆字符组成的，存取均涉及到字符编码问题(python文件并未执行，前两个阶段均属于该范畴)

#2、python中的数据类型字符串是由一串字符组成的(python文件执行时，即第三个阶段)

三 字符编码的发展史与分类

python2解释器在加载 .py 文件中的代码时，会对内容进行编码(默认ascill),而python3对内容进行编码的默认为utf-8。

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

注意：ASCII开始规定一个字节使用7位二进制位来表示，即：2**7 = 128，后来预留了一位，故ASCII的第一位均为0

Bin(二进制)

Oct(八进制)

Dec(十进制)

Hex(十六进制)

缩写/字符

解释

0000 0000

0

0

00

NUL(null)

空字符

0000 0001

1

1

01

SOH(start of headline)

标题开始

0000 0010

2

2

02

STX (start of text)

正文开始

0000 0011

3

3

03

ETX (end of text)

正文结束

0000 0100

4

4

04

EOT (end of transmission)

传输结束

0000 0101

5

5

05

ENQ (enquiry)

请求

0000 0110

6

6

06

ACK (acknowledge)

收到通知

0000 0111

7

7

07

BEL (bell)

响铃

0000 1000

10

8

08

BS (backspace)

退格

0000 1001

11

9

09

HT (horizontal tab)

水平制表符

0000 1010

12

10

0A

LF (NL line feed, new line)

换行键

0000 1011

13

11

0B

VT (vertical tab)

垂直制表符

0000 1100

14

12

0C

FF (NP form feed, new page)

换页键

0000 1101

15

13

0D

CR (carriage return)

回车键

0000 1110

16

14

0E

SO (shift out)

不用切换

0000 1111

17

15

0F

SI (shift in)

启用切换

0001 0000

20

16

10

DLE (data link escape)

数据链路转义

0001 0001

21

17

11

DC1 (device control 1)

设备控制1

0001 0010

22

18

12

DC2 (device control 2)

设备控制2

0001 0011

23

19

13

DC3 (device control 3)

设备控制3

0001 0100

24

20

14

DC4 (device control 4)

设备控制4

0001 0101

25

21

15

NAK (negative acknowledge)

拒绝接收

0001 0110

26

22

16

SYN (synchronous idle)

同步空闲

0001 0111

27

23

17

ETB (end of trans. block)

结束传输块

0001 1000

30

24

18

CAN (cancel)

取消

0001 1001

31

25

19

EM (end of medium)

媒介结束

0001 1010

32

26

1A

SUB (substitute)

代替

0001 1011

33

27

1B

ESC (escape)

换码(溢出)

0001 1100

34

28

1C

FS (file separator)

文件分隔符

0001 1101

35

29

1D

GS (group separator)

分组符

0001 1110

36

30

1E

RS (record separator)

记录分隔符

0001 1111

37

31

1F

US (unit separator)

单元分隔符

0010 0000

40

32

20

(space)

空格

0010 0001

41

33

21

!

叹号

0010 0010

42

34

22

"

双引号

0010 0011

43

35

23

#

井号

0010 0100

44

36

24

$

美元符

0010 0101

45

37

25

%

百分号

0010 0110

46

38

26

&

和号

0010 0111

47

39

27

'

闭单引号

0010 1000

50

40

28

(

开括号

0010 1001

51

41

29

)

闭括号

0010 1010

52

42

2A

*

星号

0010 1011

53

43

2B

+

加号

0010 1100

54

44

2C

,

逗号

0010 1101

55

45

2D

-

减号/破折号

0010 1110

56

46

2E

.

句号

00101111

57

47

2F

/

斜杠

00110000

60

48

30

0

数字0

00110001

61

49

31

1

数字1

00110010

62

50

32

2

数字2

00110011

63

51

33

3

数字3

00110100

64

52

34

4

数字4

00110101

65

53

35

5

数字5

00110110

66

54

36

6

数字6

00110111

67

55

37

7

数字7

00111000

70

56

38

8

数字8

00111001

71

57

39

9

数字9

00111010

72

58

3A

:

冒号

00111011

73

59

3B

;

分号

00111100

74

60

3C

<

小于

00111101

75

61

3D

=

等号

00111110

76

62

3E

>

大于

00111111

77

63

3F

?

问号

01000000

100

64

40

@

电子邮件符号

01000001

101

65

41

A

大写字母A

01000010

102

66

42

B

大写字母B

01000011

103

67

43

C

大写字母C

01000100

104

68

44

D

大写字母D

01000101

105

69

45

E

大写字母E

01000110

106

70

46

F

大写字母F

01000111

107

71

47

G

大写字母G

01001000

110

72

48

H

大写字母H

01001001

111

73

49

I

大写字母I

01001010

112

74

4A

J

大写字母J

01001011

113

75

4B

K

大写字母K

01001100

114

76

4C

L

大写字母L

01001101

115

77

4D

M

大写字母M

01001110

116

78

4E

N

大写字母N

01001111

117

79

4F

O

大写字母O

01010000

120

80

50

P

大写字母P

01010001

121

81

51

Q

大写字母Q

01010010

122

82

52

R

大写字母R

01010011

123

83

53

S

大写字母S

01010100

124

84

54

T

大写字母T

01010101

125

85

55

U

大写字母U

01010110

126

86

56

V

大写字母V

01010111

127

87

57

W

大写字母W

01011000

130

88

58

X

大写字母X

01011001

131

89

59

Y

大写字母Y

01011010

132

90

5A

Z

大写字母Z

01011011

133

91

5B

[

开方括号

01011100

134

92

5C

\

反斜杠

01011101

135

93

5D

]

闭方括号

01011110

136

94

5E

^

脱字符

01011111

137

95

5F

_

下划线

01100000

140

96

60

`

开单引号

01100001

141

97

61

a

小写字母a

01100010

142

98

62

b

小写字母b

01100011

143

99

63

c

小写字母c

01100100

144

100

64

d

小写字母d

01100101

145

101

65

e

小写字母e

01100110

146

102

66

f

小写字母f

01100111

147

103

67

g

小写字母g

01101000

150

104

68

h

小写字母h

01101001

151

105

69

i

小写字母i

01101010

152

106

6A

j

小写字母j

01101011

153

107

6B

k

小写字母k

01101100

154

108

6C

l

小写字母l

01101101

155

109

6D

m

小写字母m

01101110

156

110

6E

n

小写字母n

01101111

157

111

6F

o

小写字母o

01110000

160

112

70

p

小写字母p

01110001

161

113

71

q

小写字母q

01110010

162

114

72

r

小写字母r

01110011

163

115

73

s

小写字母s

01110100

164

116

74

t

小写字母t

01110101

165

117

75

u

小写字母u

01110110

166

118

76

v

小写字母v

01110111

167

119

77

w

小写字母w

01111000

170

120

78

x

小写字母x

01111001

171

121

79

y

小写字母y

01111010

172

122

7A

z

小写字母z

01111011

173

123

7B

{

开花括号

01111100

174

124

7C

|

垂线

01111101

175

125

7D

}

闭花括号

01111110

176

126

7E

~

波浪号

01111111

177

127

7F

DEL (delete)

删除

显然ASCII码无法将世界上的各种文字和符号全部表示(汉字大概有10万个)。

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

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

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

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

所以，就需要新出一种可以代表所有字符和符号的编码，即：Unicode

Unicode(统一码、万国码、单一码)是一种在计算机上使用的字符编码。Unicode 是为了解决传统的字符编码方案的局限而产生的：

创建初期：规定使用16位二进制位表示一个字符，即一个字符由2个字节表示：即：2 **16 = 65536，

升级：规定使用32位二进制位表示一个字符，即一个字符由4个字节表示：即：2 **32 = 4294967296，

但是：字母等8位就够了，用32位表示就造成了大量资源浪费。

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

本着节约的精神，又出现了把Unicode编码转化为“可变长编码”的UTF-8编码。UTF-8编码把一个Unicode字符根据不同的数字大小编码成1-6个字节，常用的英文字母被编码成1个字节，汉字通常是3个字节，只有很生僻的字符才会被编码成4-6个字节。如果你要传输的文本包含大量英文字符，用UTF-8编码就能节省空间：

字符ASCIIUnicodeUTF-8

A

01000001

00000000 01000001

01000001

中

x

01001110 00101101

11100100 10111000 10101101

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

内存中统一采用unicode，浪费空间来换取可以转换成任意编码(不乱码)，硬盘可以采用各种编码，如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，保证存放于硬盘或者基于网络传输的数据量很小，提高传输效率与稳定性。

View Code

基于目前的现状，内存中的编码固定就是unicode，我们唯一可变的就是硬盘的上对应的字符编码。

此时你可能会觉得，那如果我们以后开发软时统一都用unicode编码，那么不就都统一了吗，关于统一这一点你的思路是没错的，但我们不可会使用unicode编码来编写程序的文件，因为在通篇都是英文的情况下，耗费的空间几乎会多出一倍，这样在软件读入内存或写入磁盘时，都会徒增IO次数，从而降低程序的执行效率。因而我们以后在编写程序的文件时应该统一使用一个更为精准的字符编码utf-8(用1Bytes存英文，3Bytes存中文)，再次强调，内存中的编码固定使用unicode。

1、在存入磁盘时，需要将unicode转成一种更为精准的格式，utf-8:全称Unicode Transformation Format，将数据量控制到最精简

2、在读入内存时，需要将utf-8转成unicode

所以我们需要明确：内存中用unicode是为了兼容万国软件，即便是硬盘中有各国编码编写的软件，unicode也有相对应的映射关系，但在现在的开发中，程序员普遍使用utf-8编码了，估计在将来的某一天等所有老的软件都淘汰掉了情况下，就可以变成：内存utf-8硬盘utf-8的形式了。

三 字符编码应用之文件编辑器

3.1 文本编辑器之nodpad++

首先明确概念#1、文件从内存刷到硬盘的操作简称存文件#2、文件从硬盘读到内存的操作简称读文件

乱码的两种情况：#乱码一：存文件时就已经乱码

存文件时，由于文件内有各个国家的文字，我们单以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了，

！！！乱码分析！！！

乱码分析

3.2 文本编辑器之pycharm

以utf-8格式打开(选择reload)

#reload与convert的区别：

pycharm非常强大，提供了自动帮我们convert转换的功能，即将字符按照正确的格式转换

要自己探究字符编码的本质，还是不要用这个

我们选择reload，即按照某种编码重新加载文件

pycharm中：reload与convert的区别

reload与convert的区别

3.3 文本编辑器之python解释器

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

x='林'

无论是

python2 test.py

还是

python3 test.py

都会报错(因为python2默认ascii，python3默认utf-8)

除非在文件开头指定#coding:gbk

3.4 总结

！！！总结非常重要的两点！！！

#1、保证不乱吗的核心法则就是，字符按照什么标准而编码的，就要按照什么标准解码，此处的标准指的就是字符编码

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

unicode----->encode-------->utf-8

utf-8-------->decode---------->unicode

#补充：

浏览网页的时候，服务器会把动态生成的Unicode内容转换为UTF-8再传输到浏览器

如果服务端encode的编码格式是utf-8， 客户端内存中收到的也是utf-8编码的结果。

四 字符编码应用之python

4.1 执行python程序的三个阶段

python test.py   (我再强调一遍，执行test.py的第一步，一定是先将文件内容读入到内存中)

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

阶段一：启动python解释器

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

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

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

python2中默认使用ascii，python3中默认使用utf-8

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

#coding:gbk

你好啊

阶段三：读取已经加载到内存的代码(unicode编码格式)，然后执行，执行过程中可能会开辟新的内存空间，比如x="egon"

内存的编码使用unicode，不代表内存中全都是unicode，

在程序执行之前，内存中确实都是unicode,比如从文件中读取了一行x="egon",其中的x，等号，引号，地位都一样，都是普通字符而已，都是以unicode的格式存放于内存中的

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

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

4.2 python2与python3字符串类型的区别

一 在python2中有两种字符串类型str和unicode

str类型

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

要想看x在内存中的真实格式，可以将其放入列表中再打印，而不要直接打印，因为直接print()会自动转换编码，这一点我们稍后再说。

#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)) #(, )

理解字符编码的关键！！！

内存中的数据通常用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，则构成一个中午字符：你

#读到第三个括号的首位标志为0，则该8bit代表一个英文字符：a

#连续读到后两个括号内的首位标志位均为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

#coding:gbk

x='上'.decode('gbk')

y='下'.decode('gbk')

print([x,y]) #[u'\u4e0a', u'\u4e0b']

unicode类型

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

#coding:gbk

x=u'上' #等同于 x='上'.decode('gbk')

y=u'下' #等同于 y='下'.decode('gbk')

print([x,y]) #[u'\u4e0a', u'\u4e0b']

print(type(x),type(y)) #(, )

打印到终端

对于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，屌不屌？

二 在python3 中也有两种字符串类型str和bytes

str是unicode

#coding:gbk

x='上' #当程序执行时，无需加u，'上'也会被以unicode形式保存新的内存空间中,

print(type(x)) #

#x可以直接encode成任意编码格式

print(x.encode('gbk')) #b'\xc9\xcf'

print(type(x.encode('gbk'))) #

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

python2中的str类型就是python3的bytes类型

链接：http://www.cnblogs.com/linhaifeng/articles/5950339.html

总结：

我们在pycharm中写上x="中"是，在内存中编码方式时unicode，在pycharm自动保存到硬盘中，保存时按照我们指定的编码方式(gbk, utf-8)，编码为bytes类型，存储；

python解释器在执行过程中，首先是把该py文件加载到内存中，此过程中会从硬盘中读取bytes类型，通过存储时的编码方式(gbk, utf-8)，解码为汉字 中，然后在编码为unicode在内存中操作；

在执行过程中，遇到x="中"赋值操作时，会申请开辟一块内存，存储"中"，此时的存储类型就与解释器有关了，在python3中，字符串默认时unicode类型，所以存储时也是以unicode编码'中'存储对应的字节；在python2中，字符串前面不加u，就是str类型，也就是python3中的bytes类型，那么申请的内存中就会以我们存储时指定的编码方式编码的对应的bytes的类型存储了(这种方式存储在打印到终端时，会有可能出错，终端打印时采用终端的编码方式，而python3存储时是unicode类型，就可以任意转换了，不会出错)。