标签：十进制 sci 逻辑 unicode编码 功能 type 错误 不能 系统调用
应用程序任何操作硬件的请求都是需要向操作系统发起系统调用,然后又操作系统去操作硬件。
打开文本编辑器就等于启动了一个进程，是在内存中的，所以，用编辑器编写的内容也都是存放在内存中的，断电后数据丢失。
要想永久保存，需要点击保存按钮：编辑器把内存的数据刷到硬盘上。
在我们编写一个py文件（没有执行），跟编写其他文件没有任何区别，都只是在编写一堆字符而已。
第一阶段：Python解释器启动，此时就相当于启动了一个文本编辑器。
第二阶段：Python解释器相当于文本编辑器，去打开test.py文件，从硬盘上将test.py的文件内容读入到内存中。
第三阶段：Python解释器解释执行刚刚加载到内存中test.py的代码。
相同点：Python解释器是解释执行文件内容的，因而python解释器具备读py文件的功能，这一点与文本编辑器一样。
不同点：文编编辑器将文件的内容读入内存后，是为了显示或者编辑，根本不去理会Python的语法，而Python解释器将文件内容读入内存后，可不是为了就给你瞅一眼Python代码写的啥，而是为了执行Python代码、会识别Python语法。
计算机要想工作必须通电，即用‘电’趋势计算机干活，也就是说‘电’的特性决定了计算机的特性。电的特性即高低电频（人类从逻辑上将二进制数1对高电频，二进制数0对应低电频），关于磁盘的磁特性也是同样的道理。
很明显，我们平时在使用计算机时，用的都是人类能读懂的字符，如何能让计算机读懂人类的字符？
必须经过一个过程：
字符--------》翻译过程---------》数字
总而言之，字符编码是将人类的字符编码成计算机所能识别的数字0和1，这中转换必须遵循一套固定的标准，该标准无非是人类字符与数字的对应关系，称之为字符编码表。
一个Python文件中的内容是由一堆的字符组成的，存取均涉及到字符编码的问题。（Python文件并未执行时，前两个阶段均属于该范畴）
Python中的数据类型字符串是由一串字符组成的。（Python文件执行时，即第三个阶段）
计算机时由美国人发明的，最早的字符编码为ASCLL，值规定了英文字母数字和一些特殊字符与数字的对应关系。最多只能用8位来表示（一个字节），即：2**8=256，所以ASCLL码最多只能表示256个符号。
当然我们编程语言都是用英文没问题，ASCLL够用，但是在处理数据时，不同的国家有不同的语言，就类似于中国人会加入中文一样。
但是要表示中，单拿一个字节表示一个汉字，是不可能表达完的，解决方法只有一个，就是一个字节用>8位2进制代表，位数越多，代表的变化就多，这样。就可以尽可能多的表达出不同的汉字。
所以中国人规定了自己的标准gb2312编码，规定了包含中文在内的字符与数字的对应关系。
这个时候问题出现了，如果单纯采用一种国家的编码格式，那么其余国家语言的文字在解析时就会出现乱码。所以迫切需要一个世界的标准于是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编码有一个而外的好处，就是ASCLL编码实际上可以被看成是UTF-8编码的一部分，所以大量的支持ASCLL编码的历史遗留软件都可以在UTF-8编码下工作。
内存为什么不用UTF-8呢？
出现这个问题的原因是硬盘中还躺了其他国家的代码，各个国家的代码的二进制还需要运行在计算机上使用，因此内存中必须使用Unicode的编码，因为Unicode能和硬盘中其他国家的二进制中的代码进行转换。总而言之只有Unicode编码才能运行其他国家硬盘中的代码，而UTF-8的代码无法进行该操作。
内存中还使用了Unicode编码，是因为历史遗留问题造成的，但是因为现在写代码使用的都是UTF-8代码，所以以后内存中的代码都将变成UTF-8代码，并且以前遗留的各个国家的代码都将被淘汰，所以未来内存中使用的编码也将使用UTF-8编码替代Unicode编码。
首先明确概念：
文件从内存刷到硬盘的操作简称存文件
文件从硬盘读到内存的操作简称读文件
乱码的两种情况：
乱码一：存文件是就乱码 ? 存文件时，由于文件内有各个国家的文字，我们单以shiftjis去存，本质上其他国家的文集由于在shiftjis中没有找到对应关系而导致存储失败。但当我们硬要存的时候，编辑并不会报错，但毫无疑问不能存而应存可定是乱存了，即存文件阶段就已经发生乱码，而当我们用shiftjis打开文件是，日问可以正常显示，而中文则乱码了。
乱码二：存文件是用UTF-8编码，保证兼容万国，不会乱码，而读文件时选择了错误的解码方式。比如gbk，则在读阶段发生乱码是可以解决的，选择正确的解码方式就ok了。
保证不乱码的核心法则就是，字符按照什么标准而编码的，就要按照什么标准解码，此处的标准指的就是字符编码。
在内存中写的所有字符，一视同仁，都是Unicode编码的，比如我们打开编辑器，输入一个‘你’，我们并不能说‘你’就是一个汉字，此时他仅仅只是一个符号，该符号可能很多国家都在使用，根据我们使用的输入法不同这个字的样式可能也不太一样。
只有在我们往硬盘保存或者基于网络传输时，才能确定”你“到底是一个汉字，还是一个日本字，这就是Unicode转换成其他编码格式的过程了。简而言之，就是内存中固定使用的就是Uncidoe编码，我们唯一能改变的就是存储到硬盘时使用的编码。
Unicode----->encode（编码）-------->gbk
Unicode<--------decode（解码）<----------gbk
标签：十进制 sci 逻辑 unicode编码 功能 type 错误 不能 系统调用
原文地址：https://www.cnblogs.com/jincoco/p/10938251.html
