文本编辑器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是一个字节的写入，一个字节的读出解析，对于多个字节的如汉字，就会出错