关于python内open函数encoding编码问题

在学python3.7的open函数时，我发现在pycharm里新建一个file_name.txt文本文件，输入中文保存，再用open（file_name，\'r+\'）打开，再去读写时出现了一些小问题。利用Notepad和EditPlus进行多轮控制变量测试后，总结如下：

1、当原文件为utf8编码格式，且不包含中文，则对其进行读操作，正常；对其进行写操作（非中文），正常，文件编码格式不变；
当写入中文字符时，文件编码格式变为gbk，此时pycharm中的文件会将你输入的中文显示为16进制数，并会提示你用gbk编码reload文件。
2、当原文件为utf8编码格式，若包含中文，此时对其进行读操作，则可能报错UnicodeDecodeError，也可能不报错。是否报错跟中文内容有关。写入中文情况与1相同。

如，新建一个文件file4.txt,里面写入“你好”两个汉字保存，再打开：

   结果为：

为什么是 " 浣 犲 ソ " 这三个陌生的玩意呢？查看“你好”的16进制表示：

 

 

再查看" 浣 犲 ソ "的GBK编码16进制表示：

 

好像明白了：open函数用GBK编码规则解码了被UTF-8编码规则编码的file4.txt文件。前者用两个字节表示一个汉字而后者用三个。

可直接用python验证这一点：

 

把“你好”换成“中国”再试一次：报错了！

注意：E4是位置0，AD是位置2

这是因为汉字“中国”的编码第三四两个字节可能没有对应的GBK编码字符，从而导致出错。

 

 

解决方法：

申明open()函数的编码方式为\'utf-8\'，即encoding="utf-8" .

在读取文本文件的时候，如果open()函数没有声明他们如何编码，python3会选取代码所运行的计算机操作系统的默认编码作为open()函数的编码方式。

 windows10大陆区域为简体中文，可在cmd命令行输入“chcp”查看代码页：

或者：

而936代表的就是GBK简体中文。所以我的open()函数默认的编码为GBK。

 

 

 

 

但是改后对文件进行覆盖写（r+表示可读写，光标在文件开头），有时也会出错。

如：file4.txt文件输入中英混合的：hello中国

再对其进行覆盖写：

也会报错！分析一下：

hello中国的utf8 16进制表示为：

68 65 6C 6C 6F     E4 B8 AD    E5 9B BD

天青色的utf8 16进制表示为：

E5 A4 A9  E9 9D 92  E8 89 B2

覆盖写入天青色后变成：

E5 A4 A9  E9 9D 92  E8 89 B2  9B BD

还剩两个字节 9B BD找不到对应的字符，自然就报错了：

注意：报错之后文件由utf-8编码转为ASCII编码。

暂时还没找到解决办法，追加写或清空写不会出现这种报错。

 

 -----------------------------------------------------------------------华丽的分割线-----------------------------------------------------------------------------

 2021.09 更新

关于编码知识的补充：

　　所谓的Unicode编码其实是字符集和编码方式(utf8、utf16、utf32)以及其他属性的总称。Unicode标准把全球的字符用唯一的16进制编号表示出来，这个编号就叫“码点”或“码位”（Code Point），如U+708E表示汉字“炎”。所有码点共占21个bits（一开始占16个bits，2字节，后来不够用有所升级），范围是0 ~ 1 0000 1111 1111 1111 1111 ，即0x0~0x10FFFF，最多可表示1114111个。在最新的Unicode13.0版本中分配了14万多个码点。注意，在0x0~0x10FFFF范围内的任何值都是码点，但不是所有的码点都有对应的字符，如基本多语言平面中0xD800~0xDFFF这段范围就没有对应的字符，这里面是保留给utf-16编码的高位代理和低位代理。

 

　　码元（Code Unit，也称“代码单元”）是指一个已编码的文本中具有最短的比特组合的单元。对于UTF-8来说，码元是8比特长；对于UTF-16来说，码元是16比特长。

 

　　Unicode将每16位二进制数表示的范围作为一个平面，第一个平面称为基本多语言平面，用于与常用字符对应，其范围是 0000 0000 0000 0000 ~ 1111 1111 1111 1111，用十六进制表示为 0x0000 ~ 0xFFFF ；剩余十六个平面称为辅助平面，与一些辅助字符对应，如中日韩表意文字，emoji表情，甲骨文等。

 

　　Unicode没有规定具体怎么将存储到计算机硬盘中。而UTF-8就是具体编码的体现，是将码点按8比特长码元转化为01010101字节序列的一套编码规则。

 

　　其实当初我看到这句话的时候我是有点疑惑的！我们经常说Unicode编码，那我们为什么不能直接将Unicode字符集里与字符对应的码点以字节序列的形式存到计算机里面呢？就像ASCII编码那样直接用数字65来存储大写字母“A"?

 

　　其实可以，那就是utf-32编码。因为Unicode字符集里的码点总共才占了21比特位，我用3字节24比特位去存绰绰有余，但是考虑到CPU的寄存器位数是2的n次方，所以直接用4字节32比特位来存。但这对于原本只需一个字节的英文或数字字符现在都要四个字节，其中三个字节都填充了0，占用内存太大，实在是浪费资源。后来用utf-16，用两个字节或四个字节来存储，不定长的，或者用ucs-2定长的2字节来存储，都不太令人满意，其中还涉及到字节序的问题。几经折腾还是觉得utf-8比较香。

 

　　UTF-8 是一种不定长的Unicode 编码方式，一个字符可能占用1个字节，也有可能占用2,3,4 个字节。

　　Unicode字符集里的码点转化成utf-8编码的多字节序列过程：

　　1. 单字节的字符，字节的第一位设为0，如英文字母，UTF-8码只占用一个字节，和ASCII码完全相同；

　　2. n个字节的字符(n>1)，如中文汉字，第一个字节的前n位设为1，第n+1位设为0，后面字节的前两位都设为10，这n个字节的其余空位填充该字符unicode码，高位用0补足。

　　U+ 0000 ~ U+ 007F: 　　0XXXXXXX

　　U+ 0080 ~ U+ 07FF: 　　110XXXXX 10XXXXXX

　　U+ 0800 ~ U+ FFFF: 　　1110XXXX 10XXXXXX 10XXXXXX

　　U+10000 ~ U+10FFFF: 　11110XXX 10XXXXXX 10XXXXXX 10XXXXXX

UTF-8 解码规则也很简单。如果一个字节的第一位是0，则这个字节单独就表示一个字符；如果第一位是1，则连续有多少个1，就表示当前字符占用多少个字节。

 

举个栗子，如:汉字里的“汉”字的Unicode编码16进制表示为：U+6C49（它占两个字节，6C是一个字节，49是一个字节。一个字节占8比特位，6是第一个八位的前4位0110），写成二进制是: 0110 1100 0100 1001。因为0x6C49在0x0800-0xFFFF之间， 使用3字节模板: 1110xxxx 10xxxxxx 10xxxxxx。我们只需要将 0110 1100 0100 1001 这个二进制数依次代替模板中的x,得到:

11100110 10110001 10001001, 转为16进制即E6 B1 89。这个就是被存到计算机中的字节序列。

 

查看字符编码的网站地址：http://www.mytju.com/classcode/tools/encode_utf8.asp

UTF-8编码有很多优点：

1、存储文本文件到计算机硬盘节省存储空间

2、传输字符串数据时，节省宽带

3、编码是变长的，很好的兼容了ASCII

4、容错能力强悍。哪怕字节序列损坏，它也能够跳过损坏部分，进而正确解码后面的字符。

但是21-bits的code point与8-bits为一个code unit的字节序列之间的转换需要更多系统开销。编码速度相对要慢一些。

utf-8虽然国际通行，但是用三个字节表示一个汉字还是有点浪费空间。如果在简体中文环境下，使用gbk编码比utf-8更香。gbk是变长编码，占1个或者2个字节，1个字节时与ASCII码完全相同。