文本编辑器utf8
"一".encode("gbk")
保存："一"+utf8 保存为16进制的xe4xb8x80，x标识了这是utf8码
内存：xe4xb8x80+utf8 "一"即u4e00，u标识了这是Unicode码
保存："一"即u4e00 xd2xbb，x标识了这是gbk码
所以，utf8码和gbk码都用x标识，Unicode码用u标识；而x和u本质上都表示二进制，只是标识的编码表不同，u单独的表示Unicode码，而x表示其他所有的编码
"一".encode("gbk").decode("Shift_JIS")
忽略此时的编码格式，仅当作16进制xd2xbb 在日本编码表中根据16进制，找到对应的字符"ﾒｻ"(通过查看Shift_JIS编码表，确实如此，xd2对应着"ﾒ")
所以，本质上
encode：1.根据现有的16进制码+编码格式找到Unicode字符，2.根据Unicode字符找对应编码格式的16进制编码，Unicode是中转站
decode：根据现有的16进制编码(忽略编码格式)，在指定的编码表中寻找字符，不需要Unicode做中转，直接在指定的编码表中查找，一步到位
python命令行中，直接回车和print
命令行输入的时候本身也是个文本编辑器，所以回车会
转义：字母前加""来表示常见的那些不能显示的ASCII字符
即不增加现有字符的情况下，却想增加表示，即用现有的字符组合产生新的表示，即斜杠""+字符
不表示其他的，专门用来转义其他已经存在的字符，以增加表示
有a
等
而这些表示有对应的字符串，a用"x07"这个整体的字符串来表示
即："x07"来表示蜂鸣，但太长了谁记得住啊，所以不如用一个a
而
比较特殊，它没有对应的难记的字符串
yy，xyy，uyy比较特殊，需要后面跟其他的字符，而a, 直接表示了一个信息
，yy被标识为16进制，将16进制转为10进制，然后在编码表中查出对应的字符
首先区分输入和输出，直接输入的永远都是字符，不可能是字符的编码(在不用方法的情况下)
>>> "a"
>>> "x07"
没有什么不同，都是字符串，只不过"x07"看着'像'16进制而已，但它真的不是16进制
而print(字符串)，本身是个方法，方法即：对字符串做处理，返回处理后的字符串
而print最显著的功能就是，转义，识别转义字符，如a，；本质是将代码信息翻译成人类的信息；字符串'a'被翻译成一个蜂鸣声
输入b""表示执行编码，而输出的b""表示这是一个编码后的结果
编码
1.bytes，对字符串根据指定的编码格式进行编码，等价于.encode("编码格式")
bytes("我","utf8")，返回b'xe6x88x91'
2. b，bytes的特例，只支持ascii编码，所以也就不需要用函数的形式
b"ab"=="ab".encode("ascii")，返回True
输出：不表示成16进制的字符串，而是简写，直接写成b"a"，表示确实是个字节流，而二进制则是a对应的ascii码10进制转换成的二进制
>>> "我".encode() 返回b'xe6x88x91'
>>> "a".encode() 返回b"a"
都是表示的字节流，只不过对于ascii码简写了
解码
1.没有类似于bytes的方法，对应的根据指定编码进行解码的方法
u，只支持unicode-escape的解码
decode("unicode-escape")
u"u6211"返回"我"，而Unicode编码表中的u6211对应字符"我"
字符集：普通字符(万国字符集)+加上转义字符
字符的编码：特别的，转义字符的编码，a 都可以通过命令行看到，但
和 无论是命令行直接回车还是.encode()，都不显示，只显示b"
"，但也仅仅是不显示而已，本质上是有16进制编码的
print("a")是蜂鸣，a是一个字符
print("z")是z，而z是两个字符，即""和"z"
但是，python中是不允许""单独出现的；所以在命令行中输出z时为\z，指明这不是一个字符，而是两个字符
将特殊的转义字符作为单个字符并入字符集中，把转义和解码编码联系起来
命令行是做了显示处理的，才会出现不一致的情况(如：a输出a，但z输出\z)，是为了便于查看字符情况
unicode-escape与utf8/gbk没什么区别，都是字符编码格式，只不过是Unicode编码
特殊的转义1：x ，而 与x等同，即"x07"与" 07"
转后面的一个字符
x 和 转后面的两个字符
如："xab"，表示a，b的16进制合起来在编码表中对应的字符，即'«'，而"xab".encode()就是'«'.encode()
" ab"等同
所以"a"与"x07"是等同的，只不过用x07的方式直观的显示了a这个字符在编码表中的位置，第7个
这样的话，字符集又扩充了，"x07" "xab" " 07" " 07"都是一个字符
但文件中的其实是\，所以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编码表翻译过来，就以u6211u9978的形式显示处理
实际用utf8解码的时候也是一样，打印出来的是u6211u997这种形式
所以，根本还是编码和解码不同，如果有中间环节，那么拿到的文件用utf8读出来，里面就有u6211u9978这种形式
中间环节：
对unicode-escape编码的数据用utf8解码，然后用utf8编码保存，保存的实际是"u6211u9978".encode()，即b'xe6x88x91xe9xa5xb8'
我们拿到后用utf8解码，解出来自然是"u6211u997"这种字符串
文件读取问题2：
除了问题1以外
以wb写，用utf8读，出现uxxx的问题
用pycharm打开，看右下角编码是什么，就用什么解
另外：
保存文件，肯定保存的编码后的，不存在直接存字符的，只不过open的时候指定了编码，才不用我们手动的.encode()；
wb是一个字节的写入，一个字节的读出解析，对于多个字节的如汉字，就会出错