在文件读写及字符操作时，我们经常会出现下面这几种错误：
TypeError: write() argument must be str, not bytes
AttributeError: 'URLError' object has no attribute 'code'
UnicodeEncodeError: 'gbk' codec can't encode character '\xa0' inposition 5747: illegal multibyte sequence
这些错误一看就是编码问题， 本篇博文总结一下Python3文件读写及字符操作中的编码。
2 编码发展史 （1）ASCII编码
众所周知，计算机只能处理0和1，任何符号都转换为0和1的序列才能处理。计算机中8个位（bit）作为一个字节，所以1个字节能产生2的8次方个0和1的不同组合，也就是说1个字节做多能表示256种字符。ASCII编码就是用1个字节来存储字符，计算机最初是美国人发明的，他们的符号不多，所以还将8个0和1序列中的第一位固定为0，ASCII只能表示127个字符。
（2）GB2312编码
美国佬的符号不多，所以ASCII编码够用，但是其他国家就不行了，每个国家符号数量都不一样，就各自指定了自己的编码。例如我们中国就制定了GB2312编码。GB2312编码用2个字节表示一个字符。
（3）Unicode编码
每个国家都用自己的编码，编码一朵就容易乱套，也没法交流，所以需要一种编码把各个国家的编码都囊括进去，这就是Unicode编码的由来。所以，Unicode也被称为万国码。Unicode编码也用2个字节存储一个字符。
（4）utf-8编码
Unicode编码解决了编码不能通用的问题，但是却容易浪费内存，尤其是在存储英文的时候，例如一个字符“A”，ASCII编码只需要1个字节就够，但是Unicode编码必须要用2个字节。为了解决这一问题，就有了utf-8编码。 utf-8编码把存储英文依旧用一个字节，汉字就3个字节。特别是生僻的编程4-6字节，如果传输大量英文，utf-8作用就很明显了。
utf-8编码进行存储时有极大地优势，但是当读取到计算机内存时却不大合适，因为utf-8编码是变长的，不方便寻址和索引，所以在计算机内存中，还是转化为Unicode编码合适些。这就可以解释为什么每次读取文本时，要将编码转化为Unicode编码，而将内存中的字符写入文件存储时，要将编码转化为utf-8了。
在Python3中，文本总是为Unicode编码，在类型上为str类，也就是说Python编译器只会把Unicode编码下的二进制流显示为我们可识别的符号。二进制流在Python中也有一个专门的类用于表示这种二进制序列，那就是bytes（在Python中这个二进制序列显示为16进制，但本质还是二进制）。一个str在不同的编码下就可以转化为不同的bytes（二进制流），反之，要将bytes转化为可识别的str就必须用对应的编码，否则就会报错。
用人类语言类比一下：我们要表达“Linux公社 ”这件事物（str），公社翻译为各个国家的文字后有各不相同的表示，中文表示为“公社”，英文表示为“commune”，这就是“公社”这个str在不同编码写的表示。但官方只认中文（Pythonstr只认Unicode编码），所以就必须把“commune”用英语（编码）的表示方式转化为中文的“公社”（Unicode编码），官方才会显示知道是公社这件事。
>>> s = 'Linux公社 '
>>> type(s)
<class 'str'>
>>> s1 = s.encode(encoding='utf-8')
>>> type(s1)
<class 'bytes'>
>>> s1
b'Linux\xe5\x85\xac\xe7\xa4\xbe '
>>> s2 = s.encode(encoding='gb2312')
>>> type(s2)
<class 'bytes'>
>>> s2
b'Linux\xb9\xab\xc9\xe7 '
>>> s1.decode('utf-8')
'Linux公社 '
>>> s2.decode('gb2312')
'Linux公社 '
>>>
在python 3 中字符是以Unicode的形式存储的，当然这里所说的存储是指存储在计算机内存当中，如果是存储在硬盘里，Python 3的字符是以bytes形式存储，也就是说如果要将字符写入硬盘，就必须对字符进行encode。对上面这段话再解释一下，如果要将str写入文件，如果以‘w’模式写入，则要求写入的内容必须是str类型；如果以‘wb’形式写入，则要求写入的内容必须是bytes类型。文章开头出现的集中错误，就是因为写入模式与写入内容的数据类型不匹配造成的。