在歷史的長河里，產(chǎn)生了媛媛不止我們前面提到的那些編碼方式，還有很多。

對于我們中國來說，在GBK之前還有GB2312，它是對ASCII碼表的中文擴展，當(dāng)時咱們還沒那么富裕，三個字節(jié)對我們來說太奢侈了，所以GB2312只是用兩個字節(jié)，給常用的漢字進(jìn)行了編碼。

緊接著臺灣的同胞一看，這明顯是不讓我們寫繁體字了，于是他們也自己弄了一個繁體字編碼，叫大五碼（Big-5）。

然后在GBK之后，由于少數(shù)民族也需要用電腦了，于是又?jǐn)U展成了GB18030，還有當(dāng)時很多沒有流行起來的編碼方式，我就不一一贅述了。

現(xiàn)在只是我們國家都有那么多種編碼標(biāo)準(zhǔn)，更不用說其他國家了。

這就是我們經(jīng)常遇到亂碼問題的原因。

因為你打開的方式不對，你用什么方式保存的文件，打開的時候，就要按對應(yīng)的編碼來反解成Unicode才會正常顯示，不然就會是一團(tuán)亂碼。

現(xiàn)在內(nèi)存里固定都是Unicode，我們是沒辦法選擇的，但是我們往硬盤里存數(shù)據(jù)的時候，是可以選擇存GBK或者其他編碼的。

但是如果我們現(xiàn)在存文件，還是指定GBK或者其他老的編碼方式來存的話，這就是一種圖步，我們不應(yīng)該這么做，理論上來說，我們應(yīng)該直接把Unicode格式的二進(jìn)制數(shù)據(jù)存到硬盤。

為什么說是理論上呢？

因為Unicode簡單粗暴，都是用兩個字節(jié)來表示一個字符，個別生僻的字符會用更多，如果我這個文件里就是包含了各個國家的字符，那這樣就沒問題。

但是如果我這個文件99%都是英文的話，這個Unicode會有什么問題呢？是不是會多占一倍的空間??！本來我八位就足夠了，你要給我用16位。

但是這個浪費空間的問題不是致命的，現(xiàn)在的存儲越來越便宜了，真正致命的是IO問題。

我們現(xiàn)在來想，到底是讀寫100兆的文件IO次數(shù)多，還是讀寫50兆的文件IO次數(shù)多呢？

所以真正影響這個問題是IO增多的問題。

這個IO問題我們之前最開始 的時候也提過，后面我會專門開兩篇溫江講硬盤的IO操作，這里就不多介紹了。

所以本著這個原則，我們應(yīng)該將Unicode，在原有的基礎(chǔ)上進(jìn)行精簡，這時候有同學(xué)就會問，為什么不能一開始設(shè)計Unicode的時候就設(shè)計的精簡一點呢？

那就反過來問，當(dāng)初設(shè)計計算機的時候，就不用ASCII碼表，不用GBK，而是直接用最完美的字符編碼表，不就好了嗎？

歷史是一點點發(fā)展的，科技也是一點點的發(fā)展的，不會存在一下子的大爆發(fā)，所以不要用現(xiàn)在的眼光去判斷歷史發(fā)展的問題。

只能發(fā)現(xiàn)問題，然后解決問題。

未經(jīng)允許不得轉(zhuǎn)載：445IT之家 » Python Unicode的IO問題