编码-转义2-mark

文本编辑器utf8

"一".encode("gbk")

保存："一"+utf8     保存为16进制的\xe4\xb8\x80，\x标识了这是utf8码

内存：\xe4\xb8\x80+utf8   "一"即\u4e00，\u标识了这是Unicode码

保存："一"即\u4e00   \xd2\xbb，\x标识了这是gbk码

所以，utf8码和gbk码都用\x标识，Unicode码用\u标识；而\x和\u本质上都表示二进制，只是标识的编码表不同，\u单独的表示Unicode码，而\x表示其他所有的编码

"一".encode("gbk").decode("Shift_JIS")

忽略此时的编码格式，仅当作16进制\xd2\xbb   在日本编码表中根据16进制，找到对应的字符"ﾒｻ"(通过查看Shift_JIS编码表，确实如此，\xd2对应着"ﾒ")

所以，本质上

encode：1.根据现有的16进制码+编码格式找到Unicode字符，2.根据Unicode字符找对应编码格式的16进制编码，Unicode是中转站

decode：根据现有的16进制编码(忽略编码格式)，在指定的编码表中寻找字符，不需要Unicode做中转，直接在指定的编码表中查找，一步到位

python命令行中，直接回车和print

命令行输入的时候本身也是个文本编辑器，所以回车会

转义：字母前加"\"来表示常见的那些不能显示的ASCII字符

即不增加现有字符的情况下，却想增加表示，即用现有的字符组合产生新的表示，即斜杠"\"+字符

\不表示其他的，专门用来转义其他已经存在的字符，以增加表示

有\a  \n \t 等

而这些表示有对应的字符串，\a用"\x07"这个整体的字符串来表示

即："\x07"来表示蜂鸣，但太长了谁记得住啊，所以不如用一个\a

而\n比较特殊，它没有对应的难记的字符串

\0yy，\xyy，\uyy比较特殊，需要后面跟其他的字符，而\a,\t直接表示了一个信息

，yy被标识为16进制，将16进制转为10进制，然后在编码表中查出对应的字符

首先区分输入和输出，直接输入的永远都是字符，不可能是字符的编码(在不用方法的情况下)

>>> "a"

>>> "\x07"

没有什么不同，都是字符串，只不过"\x07"看着'像'16进制而已，但它真的不是16进制

而print(字符串)，本身是个方法，方法即：对字符串做处理，返回处理后的字符串

而print最显著的功能就是，转义，识别转义字符，如\a，；本质是将代码信息翻译成人类的信息；字符串'\a'被翻译成一个蜂鸣声

输入b""表示执行编码，而输出的b""表示这是一个编码后的结果

编码

1.bytes，对字符串根据指定的编码格式进行编码，等价于.encode("编码格式")

bytes("我","utf8")，返回b'\xe6\x88\x91'

2.   b，bytes的特例，只支持ascii编码，所以也就不需要用函数的形式

b"ab"=="ab".encode("ascii")，返回True

输出：不表示成16进制的字符串，而是简写，直接写成b"a"，表示确实是个字节流，而二进制则是a对应的ascii码10进制转换成的二进制

>>> "我".encode()    返回b'\xe6\x88\x91'

>>> "a".encode()   返回b"a"

都是表示的字节流，只不过对于ascii码简写了

解码

1.没有类似于bytes的方法，对应的根据指定编码进行解码的方法

u，只支持unicode-escape的解码

decode("unicode-escape")

u"\u6211"返回"我"，而Unicode编码表中的\u6211对应字符"我"

字符集：普通字符(万国字符集)+加上转义字符

字符的编码：特别的，转义字符的编码，\a  \b都可以通过命令行看到，但\n和\t无论是命令行直接回车还是.encode()，都不显示，只显示b"\n"，但也仅仅是不显示而已，本质上是有16进制编码的

print("\a")是蜂鸣，\a是一个字符

print("\z")是\z，而\z是两个字符，即"\"和"z"

但是，python中是不允许"\"单独出现的；所以在命令行中输出\z时为\\z，指明这不是一个字符，而是两个字符

将特殊的转义字符作为单个字符并入字符集中，把转义和解码编码联系起来

命令行是做了显示处理的，才会出现不一致的情况(如：\a输出\a，但\z输出\\z)，是为了便于查看字符情况

unicode-escape与utf8/gbk没什么区别，都是字符编码格式，只不过是Unicode编码

特殊的转义1：\x  \0，而\0与\x等同，即"\x07"与"\007"

\转后面的一个字符
  \x 和\0转后面的两个字符

如："\xab"，表示a，b的16进制合起来在编码表中对应的字符，即'«'，而"\xab".encode()就是'«'.encode()

"\0ab"等同

所以"\a"与"\x07"是等同的，只不过用\x07的方式直观的显示了\a这个字符在编码表中的位置，第7个

这样的话，字符集又扩充了，"\x07"  "\xab"  "\007"  "\007"都是一个字符

但文件中的\其实是\\，所以\x07其实是\\x07

特殊的字符串2：\u440e，Unicode中的编码，转义后面4个字符，且这4个形成的字符串必须在Unicode编码表中存在；

\xyy，yy表示一个字节，而一个字节内是ascii码，所以不存在编码对应的字符不同的情况；

就是变相的给ascii字符都起了个别名

而\uyyyy，指明了必须在Unicode编码表中找对应的字符，更不存在什么问题了

所以在文件中如果\u后面的四个字符形成的字符串在Unicode编码中没有，就会报错

二进制写入，读取，不存在编码问题；是一个字节的写，一个字节的读

问题：

拿到的响应直接以二进制保存，二进制中有\u，但后面内容不对，所以在读的时候就错了

文件读取问题1：

\u的问题：utf/unicode-escape对ascii字符的处理是一致的，但对汉字不一致；

unicode-escape编码产生字节流，用utf8解码，英文及标点没问题，但遇到unicode码，utf8解决不了，

以文本编辑器打开查看的时候，默认就是用utf8打开的，所以Unicode码被按照Unicode编码表翻译过来，就以\u6211\u9978的形式显示处理

实际用utf8解码的时候也是一样，打印出来的是\u6211\u997这种形式

所以，根本还是编码和解码不同，如果有中间环节，那么拿到的文件用utf8读出来，里面就有\u6211\u9978这种形式

中间环节：

对unicode-escape编码的数据用utf8解码，然后用utf8编码保存，保存的实际是"\u6211\u9978".encode()，即b'\xe6\x88\x91\xe9\xa5\xb8'

我们拿到后用utf8解码，解出来自然是"\u6211\u997"这种字符串

文件读取问题2：

除了问题1以外

以wb写，用utf8读，出现\uxxx的问题

用pycharm打开，看右下角编码是什么，就用什么解

另外：

保存文件，肯定保存的编码后的，不存在直接存字符的，只不过open的时候指定了编码，才不用我们手动的.encode()；

wb是一个字节的写入，一个字节的读出解析，对于多个字节的如汉字，就会出错