在历史的长河里,产生了媛媛不止我们前面提到的那些编码方式,还有很多。
对于我们中国来说,在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问题