聯(lián)通不如移動的故事

在編碼界一直流傳著聯(lián)通不如移動的一個故事。。。

請不要誤會，聯(lián)通和移動和本篇文章所說的編碼確實沒什么關(guān)系，但請出聯(lián)通和移動幫忙做個小實驗，再來仔細(xì)說說編碼。

在Windows系統(tǒng)下，在桌面上右鍵新建一個記事本文件，打開它輸入“聯(lián)通”兩個漢字，Ctrl+S保存并關(guān)閉。

雙擊再次打開它，看到了什么？奇怪，文字怎么變成亂碼了？

好吧，再次新建一個文件，這回輸入“移動”保存再試試。神奇，移動居然完美顯示。

好了，不說什么故事了，這個有趣的現(xiàn)象正是為了聊聊計算機中“編碼”的那些事，之后再解釋為什么“聯(lián)通不如移動”。

聊聊字符編碼的發(fā)展史

在計算機中，所有存儲的數(shù)據(jù)都由二進制表示。字母、數(shù)字、字符這些都不例外，計算機中最小的單位就是二進制位（0和1），8個位表示一個字節(jié)，因此8個二進制位就可以排列組合出256種狀態(tài)，也就是理論上可以表示出256種字符，而由哪些二進制位表示哪些字符，這就是由人來決定的了，也就是人們制定出的各種“編碼”。

電腦這種東西最早由老外發(fā)明，外國人使用的英語只有26個字母，再加上標(biāo)點、數(shù)字和一些符號也不會太多，因此英文通常用ASCII編碼來表示。

ASCII碼

ASCII碼最開始只在美國使用，組合出的256種狀態(tài)中，第0~32中規(guī)定了特殊用途，一旦終端、打印機遇上約定好的這些字節(jié)被傳過來時，就要做一些約定的動作，比如遇到0×10, 終端就換行等等。

又把所有的空格、標(biāo)點符號、數(shù)字、大小寫字母分別用連續(xù)的字節(jié)狀態(tài)表示，一直編到了第 127 號，這樣計算機就可以用不同字節(jié)來存儲英語的文字了。

記得當(dāng)初學(xué)習(xí)C語言的時候，就清楚的知道了一些常用的ASCII碼值，比如大寫A是65，小寫a是97等。

這128個符號（包括32個不能打印出來的控制符號），只占用了一個字節(jié)的后面7位，最前面的一位統(tǒng)一規(guī)定為0。

英文可以表示了，但是世界上除了英文還有很多語言。我們的中文文字浩如煙海，僅僅靠這8個二進制位遠遠不夠，怎么辦？

GB2312

且不說中文，在歐洲有些國家的語言中也有一些特殊的字母，比如俄文希臘文等。于是便使用127號之后的空位繼續(xù)表示他們的字母。當(dāng)然，由于每個國家的語言不同，就越來越亂，比如130在法語中是字母 é，但是在希伯萊語中130卻是他們的字母 ?。

我們的中文就更難辦了，即使把所有的位都用上，也表示不完成千上萬的漢字，于是我們自己也制定了一套中文的編碼GB2312。

中國為了表示漢字，把127號之后的符號取消了，規(guī)定：

• 一個小于127的字符的意義與原來相同，但兩個大于 127 的字符連在一起時，就表示一個漢字；
• 前面的一個字節(jié)（他稱之為高字節(jié)）從0xA1用到0xF7，后面一個字節(jié)（低字節(jié)）從 0xA1 到 0xFE；
• 這樣我們就可以組合出大約7000多個(247-161)*(254-161)=(7998)簡體漢字了。
• 還把數(shù)學(xué)符號、日文假名和ASCII里原來就有的數(shù)字、標(biāo)點和字母都重新編成兩個字長的編碼。這就是全角字符，127以下那些就叫半角字符。

把這種漢字方案叫做 GB2312。GB2312 是對 ASCII 的中文擴展。

GBK

再后來，發(fā)現(xiàn)了GB2312雖然解決了中文編碼的問題，但是仍有不足。

GB2312表示的中文有時不夠，有些字并不是生僻字，但是沒有收錄其中，當(dāng)時有個小插曲，我當(dāng)時在高考報名的系統(tǒng)中查詢成績的時候報不出我的名字，只能報出我的姓，正是因為我的名字“玥”字不在GB2312的編碼范圍，因此沒有。

于是干脆不再要求低字節(jié)一定是 127 號之后的內(nèi)碼，只要第一個字節(jié)是大于 127 就固定表示這是一個漢字的開始,又增加了近 20000 個新的漢字（包括繁體字）和符號。

這就是更全面的GBK編碼。

Unicode

隨著發(fā)展，每個國家都對自己的語言編出一套自己的編碼，真是混亂不堪，我們不知道別人用什么編碼，別人也不知道我們用什么編碼，于是標(biāo)準(zhǔn)組織出手了。

ISO標(biāo)準(zhǔn)組織看到了亂象，制定了一套Unicode編碼以解決這種混亂的局面，它的制定簡單粗暴，不是全世界的語言多么，我干脆就規(guī)定，所有的字符都給我用兩個字節(jié)表示（兩個8位一共16位），對于 ASCII 里的那些 半角字符，Unicode 保持其原編碼不變，只是將其長度由原來的 8 位擴展為16 位，而其他文化和語言的字符則全部重新統(tǒng)一編碼。

從 Unicode 開始，無論是半角的英文字母，還是全角的漢字，它們都是統(tǒng)一的一個字符。同時，也都是統(tǒng)一的兩個字節(jié)。

UTF8

Unicode的制定是在1990年，正式使用在1994年，那個年代在現(xiàn)在來看簡直是遠古時期，那時由于互聯(lián)網(wǎng)并不發(fā)達并沒有推廣開。

隨著互聯(lián)網(wǎng)的發(fā)展，為了解決Unicode傳輸問題，于時面向眾多的UTF標(biāo)準(zhǔn)出現(xiàn)了。

• UTF-8 就是在互聯(lián)網(wǎng)上使用最廣的一種 Unicode 的實現(xiàn)方式
• UTF-8就是每次以8個位為單位傳輸數(shù)據(jù)
• 而UTF-16就是每次 16 個位
• UTF-8 最大的一個特點，就是它是一種變長的編碼方式
• Unicode 一個中文字符占 2 個字節(jié)，而 UTF-8 一個中文字符占 3 個字節(jié)
• UTF-8 是 Unicode 的實現(xiàn)方式之一

因為UTF8是Unicode的實現(xiàn)方式之一，它們之間是互通的，就是說Unicode編碼可以傳換為UTF8，它有一套對應(yīng)規(guī)則：

Unicode符號范圍（16進制）UTF8編碼（2進制）

0000 0000-0000 007F	0xxxxxxx
0000 0080-0000 07FF	110xxxxx 10xxxxxx
0000 0800-0000 FFFF	1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

可以看到，對于單字節(jié)的符號，字節(jié)的第一位設(shè)為0，后面7位為這個符號的 Unicode 碼。因此對于英語字母，UTF-8 編碼和 ASCII 碼是相同的（見上面表格的第一行）。

對于n字節(jié)的符號（n>1），第一個字節(jié)的前n位都設(shè)為1，第n+1位設(shè)為0，后面字節(jié)的前兩位一律設(shè)為10。剩下的沒有提及的二進制位，全部為這個符號的 Unicode 碼。

說的有些抽象，舉個例子吧，比如來了一個漢字，電腦是怎么知道的它是用UTF8編碼的呢？

因為漢字用三個字節(jié)表示（別再問為什么用三個字節(jié)表示了，這是規(guī)定），因此第一個字節(jié)的前三位都為1，第四位設(shè)為0，后面的位都以10開頭，所以它肯定長這個樣子：1110xxxx 10xxxxxx 10xxxxxx。

OK，電腦按照這個規(guī)則一看明白了，來的是個漢字！

不如再舉個例子，從Unicode編碼表中查出一個漢字對應(yīng)的編碼，把它轉(zhuǎn)換為UTF8試一試，就用我的名字“玥”字吧，它的Unicode編碼為\u73a5

首先第一步把16進制轉(zhuǎn)換為2進制，它的值是111001110100101，那怎么拆分這個2進制的值呢？因為UTF8都是后6位為這個字符的Unicode的碼，所以我們從右往左數(shù)6位給一一對應(yīng)上，不足的位補0就好了。

這樣就得出了“玥”字的UTF8編碼：11100111 10001110 10100101

作為開發(fā)人員完全可以用代碼實現(xiàn)一下，這里用node.js真實的實現(xiàn)一下轉(zhuǎn)碼：

function transferToUTF8(unicode) {code = [1110, 10, 10];let binary = unicode.toString(2); //轉(zhuǎn)為二進制code[2] = code[2] + binary.slice(-6); //提取后6位code[1] = code[1] + binary.slice(-12, -6); //提取中間6位code[0] = code[0] + binary.slice(0, binary.length - 12).padStart(4, '0'); //取剩余開始的位，不夠補0code = code.map(item => parseInt(item, 2)); //把字符串轉(zhuǎn)換為二進制數(shù)值return Buffer.from(code).toString(); //利用Buffer轉(zhuǎn)轉(zhuǎn)為漢字 }console.log(transferToUTF8(0x73a5));

運行結(jié)果：

玥

以上代碼定義了一個transfer函數(shù)，參數(shù)接收一個16進制值，它代表了一個Unicode字符，transfer函數(shù)內(nèi)部先轉(zhuǎn)換為二進制，并按照UTF-8的規(guī)則轉(zhuǎn)換為相應(yīng)的UTF-8編碼，最后，利用node.js的Buffer最終轉(zhuǎn)碼成漢字，可以看到，已經(jīng)正確輸出了漢字“玥”。

以上，就是簡單分析了Unicode和UTF-8的轉(zhuǎn)換關(guān)系。

為什么聯(lián)通不如移動？

故事就要講完了，說了這么多編碼的事現(xiàn)在可以回頭看看開篇為什么聯(lián)通變成了亂碼，因為在Windows的記事本中文默認(rèn)的保存編碼為GB2312，通過查詢可以查到漢字“聯(lián)”對應(yīng)的GB2312編碼為uc1aa，轉(zhuǎn)換為二進制是1100000110101010，正好是16位兩個字節(jié)，按8位拆成兩組正好與UTF8的第二種編碼格式對應(yīng)上了：110xxxxx 10xxxxxx，這樣再次打開記事本的時候Windows掃描文件內(nèi)容，它就會認(rèn)為這是UTF-8編碼的文件，而不是GB2312！此時此刻按照UTF-8來解析文件內(nèi)容當(dāng)然出現(xiàn)了亂碼。

這時可以重新另存為文件，把文件格式改為GB2312來保存，現(xiàn)次打開“聯(lián)通”終于顯示了。

這個例子很極端，可以說“聯(lián)通”二字的編碼正好是個巧合，但是搞明白了編碼的細(xì)節(jié)，更有助于我們在開發(fā)中遇到問題可以快速理解其實質(zhì)，并加以解決，在此記下筆記，與大家共同學(xué)習(xí)提高。

總結(jié)

以上是生活随笔為你收集整理的从一个小故事聊聊字符编码那些事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。