微軟本著顧客就是上帝的原則，就把賣給中國人的有系統(tǒng)默認使用GBK編碼，賣給韓國人的系統(tǒng)默認使用EUC-KR編碼，其他國家也是如此。

但是為了避免廣大消費者誤會賣給我們的系統(tǒng)功能有差異，微軟就把統(tǒng)一默認編碼都顯示成ANSI。

在我們的電腦里面，ANSI也就是我們的GBK系列的編碼，當我們用記事本另存的時候在下面就可以看到。

關(guān)于這個記事本，有個很注明的奇怪現(xiàn)象，當你在windows的記事本里新建一個文件，輸入聯(lián)通這兩個字后，保存，關(guān)閉。

然后再次打開，你會發(fā)現(xiàn)這兩個字變成了亂碼。

有人說這就是聯(lián)通之所以干不過移動的原因，其實這是因為GBK編碼與UTF-8編碼產(chǎn)生了編碼沖撞的原因。

Unicode         UTF-8
0000 - 007F     0XXXXXXX
0080 - 07FF     110XXXXX 10XXXXXX
0800 - FFFF     1110XXXX 10XXXXXX 10XXXXXX

上面這一段就是從Unicode到UTF-8的轉(zhuǎn)換規(guī)則。當然是按十六進制分的。

Unicode編碼中從0000到007F，對應UTF-8中的二進制編碼，就是以0開頭，占用一個字節(jié)。

Unicode編碼中從0080到07FF這段編碼對應的是UTF-8中的110開頭的一個字節(jié)，10開頭的一個字節(jié)，兩個字節(jié)

0800到FFFF這段編碼，對應的是UTF-8中的1110開頭的1個字節(jié)，10開頭的一個字節(jié)，還有一個10開頭的一個字節(jié)，這里要用三個字節(jié)。

列入仙這個字，Unicode編碼是4ED9,4ED9在0800和FFFF之間，所以需要這個三個字節(jié)的模板。

4ED9轉(zhuǎn)換成二進制是0100 1110 1101 1001 ，把這個比特流按三字節(jié)模板拆，就變成了這樣，依次替換模板中的X，得到1110-0100 10-111011 10-011001。

再轉(zhuǎn)成16進制，就變成了E4BB99。

 仙---->4ED9---->1110-0100 10-111011 10-011001
 1110-0100 10-111011 10-011001--->E4BB99

這其實就是UTF-8的編碼，而當你新建一個文本文件時，記事本編碼默認是ANSI，前面我們說過ANSI在我們電腦里其實就是GB系列編碼方式。

在這種編碼下，聯(lián)通的內(nèi)碼是：C1AA CDA8.這也是16進制的。

前面我們學進制轉(zhuǎn)換的時候知道，每四位二進制可以轉(zhuǎn)換成1位十六進制，也就是說每兩位十六進制就是一個字節(jié)。

C1就是第一個字節(jié)，轉(zhuǎn)成二進制就是110 0001。

AA是第二個字節(jié)，轉(zhuǎn)成二進制就是1010 1010。

CD是第三個字節(jié)，轉(zhuǎn)成二進制就是1100 1101。

A8是第四個字節(jié)，轉(zhuǎn)成二進制是1010 1000。

 C1--->1100 0001
AA--->1010 1010 
CD--->1100 1101
A8--->1010 1000

我們來看第三四個字節(jié)的開頭部分，都是110和10，正好與UTF-8規(guī)則里的兩字節(jié)模板是一致的。

于是再次打開這個文件的時候，及時本會自動識別編碼方式，它就誤認為這是一個UTF-8編碼的文件，會把第一個字節(jié)的110和第二個字節(jié)的10去掉。于是就得到了00001 101010。

再把各位對齊，補上前面的0，就得到了0000 0000 0110 1010，這個二進制就轉(zhuǎn)成十六進制就變成了006A。

Unicode的006A也就是小寫的字母j，而之后的兩個字節(jié)用UTF-8解碼之后是0368，這個字符什么也不是。

0000 0000 0110 1010--->006A--->j
0000 0011 0110 1000--->0368--->不存在

這就是聯(lián)通兩個字的文件沒有辦法在記事本里正常顯示的原因。如果你在聯(lián)通后面輸入幾個字，其他的字的編碼不見得有恰好是110和10開始的字節(jié)，這樣再次打開時記事本就不會堅持這是一個UTF-8編碼的文件。

而會用ANSI的方式解讀，這是亂碼就不會出現(xiàn)了。

未經(jīng)允許不得轉(zhuǎn)載：445IT之家 » Python 記事本寫‘聯(lián)通’亂碼的原因