又编解码错误？一怒之下我把编解码的问题连根拔起！！！
文章目录
寻找同道
运行代码的时候，最烦的就是代码逻辑都好好的，然后出现了编解码错误的报错。
我就纳闷儿了，我就做个测试，你错误就错误呗，你倒是跟我说这个逻辑行不行得通啊，我才不想管你是不是解不了码。
一怒之下，我决定写这么一篇博客，纪录一下每次遇到的不同的编解码问题，以及这一切的背后，到底是什么在捣鬼。
大家有这方面的困惑或者经验都可以打在评论区，我们一起讨论讨论、 之后我再整理进这篇文章中。 所以可以先收藏一下，早晚用得上。
问题解决专栏
1、我遇到了这么一个问题：
UnicodeEncodeError: 'gbk' codec can't encode character '\xb6' in position 3264: illegal multibyte sequence这个问题经常性的遇到啊。
于是就有了以下解决方案：
- 方案一：
在文章开头处写上：
#coding:utf-8这行的意思是：告诉解释器，我这段代码所涉及到的一切数据都是由utf-8编码的，你到时候就用utf-8给我解码就行了。
本来呢，这是个比较好的方法，也屡试不爽，但是今天它还就失败了。
于是就有了方案二。
- 方案二：
代码里加上这一行，再把确实的模块包进来，也是屡试不爽。
sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='gbk') # 改变标准输出的默认编码- 方案三： 在函数调用中加上“encoding = ‘utf-8’”，但是呢，由于不是所有函数都支持这个参数，所以就看运气、
那么我们该如何应对这突如其来的编码事故？方法一如果不奏效，你让我被方法二的代码？显然不现实。那怎么办，打开我这篇博客？浪不浪费时间。
我想，从编辑器或者解释器出发，彻底解放这个问题！！！
有哪些常用编码集？
ANSI编码： 没听说过吧，我也没听说过，但是之前用R语言做时间序列分析的时候被这个编码集坑惨了。 具体记不得了，解决方法有：将文件用文本编辑器打开，另存的时候选择编码集，选‘utf-8’。
ASCII码： 这个就不陌生了吧？在ANSI的基础上进行了修改，把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字了。
GB2312： GB2312 是对 ASCII 的中文扩展。 规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（称之为高字节）从0xA1用到0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。
在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的“全角”字符，而原来在127号以下的那些就叫"半角"字符了。于是就把这种汉字方案叫做 “GB2312”。
GBK： 汉字太多了，上面那个很快就被发现了局限性。 那怎么办？再加呗。
扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。
GB18030： 后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。 在这个标准里，最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里，因此他们写的程序为了支持中文处理，必须要注意字串里的每一个字节的值，如果这个值是大于127的，那么就认为一个双字节字符集里的字符出现了。
UNICODE编码： 当时各个国家都像中国这样搞出一套自己的编码标准，结果互相之间谁也不懂谁的编码，谁也不支持别人的编码。
一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它 UCS, 俗称 UNICODE。
无论是半角的英文字母，还是全角的汉字，它们都是统一的“一个字符”！同时，也都是统一的“两个字节”
UTF-8和UTF-16： UNICODE 来到时，一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，顾名思义，UTF8就是每次8个位传输数据，而UTF16就是每次16个位。
pycharm一劳永逸大法
好了，不讲那么多废话了，放大招吧：
腾讯云开发者
