在历史的长河里，产生了媛媛不止我们前面提到的那些编码方式，还有很多。
对于我们中国来说，在GBK之前还有GB2312，它是对ASCII码表的中文扩展，当时咱们还没那么富裕，三个字节对我们来说太奢侈了，所以GB2312只是用两个字节，给常用的汉字进行了编码。
紧接着台湾的同胞一看，这明显是不让我们写繁体字了，于是他们也自己弄了一个繁体字编码，叫大五码（Big-5）。
然后在GBK之后，由于少数民族也需要用电脑了，于是又扩展成了GB18030，还有当时很多没有流行起来的编码方式，我就不一一赘述了。
现在只是我们国家都有那么多种编码标准，更不用说其他国家了。
这就是我们经常遇到乱码问题的原因。
因为你打开的方式不对，你用什么方式保存的文件，打开的时候，就要按对应的编码来反解成Unicode才会正常显示，不然就会是一团乱码。
现在内存里固定都是Unicode，我们是没办法选择的，但是我们往硬盘里存数据的时候，是可以选择存GBK或者其他编码的。
但是如果我们现在存文件，还是指定GBK或者其他老的编码方式来存的话，这就是一种图步，我们不应该这么做，理论上来说，我们应该直接把Unicode格式的二进制数据存到硬盘。
为什么说是理论上呢？
因为Unicode简单粗暴，都是用两个字节来表示一个字符，个别生僻的字符会用更多，如果我这个文件里就是包含了各个国家的字符，那这样就没问题。
但是如果我这个文件99%都是英文的话，这个Unicode会有什么问题呢？是不是会多占一倍的空间啊！本来我八位就足够了，你要给我用16位。
但是这个浪费空间的问题不是致命的，现在的存储越来越便宜了，真正致命的是IO问题。
我们现在来想，到底是读写100兆的文件IO次数多，还是读写50兆的文件IO次数多呢？
所以真正影响这个问题是IO增多的问题。
这个IO问题我们之前最开始 的时候也提过，后面我会专门开两篇温江讲硬盘的IO操作，这里就不多介绍了。
所以本着这个原则，我们应该将Unicode，在原有的基础上进行精简，这时候有同学就会问，为什么不能一开始设计Unicode的时候就设计的精简一点呢？
那就反过来问，当初设计计算机的时候，就不用ASCII码表，不用GBK，而是直接用最完美的字符编码表，不就好了吗？
历史是一点点发展的，科技也是一点点的发展的，不会存在一下子的大爆发，所以不要用现在的眼光去判断历史发展的问题。
只能发现问题，然后解决问题。
未经允许不得转载：445IT之家 » Python Unicode的IO问题
