[[211481]]

我們經(jīng)常聽到純文本格式和二進制編碼，什么是純文本，什么是二進制呢？以一個例子做說明。新建一個文件叫hello.txt，內(nèi)容為：

hello, world 

這個文件有12個字節(jié)：

借助Node.js可以看這個文件在硬盤的原始二進制存儲是什么，如下代碼：

let fs = require("fs"); 
// 讀取原始二進制內(nèi)容 
let buffer = fs.readFileSync("hello.txt");  
console.log(buffer); 

運行后控制臺輸出12個字節(jié)的二進制內(nèi)容（以十六進制顯示）：

<Buffer 68 65 6c 6c 6f 2c 20 77 6f 72 6c 64> 

參考ASCII表，我們發(fā)現(xiàn)這些數(shù)字剛好是英文對應的ASCII編碼，如下圖所示：

如果這個文本文件以utf-8讀取的方式：

let fs = require("fs"); 
let text = fs.readFileSync("hello.txt", "utf-8");  
console.log(text); 

輸出的就是文本：

這里看到了兩種截然不同的輸出結(jié)果，但實際上不管是純文本文件還是二進制文件，硬盤或者內(nèi)存里存儲的都是0101，就看你如何解讀它，或者說怎么解碼。（只不過我們通常說的純文本是指那種能夠解碼成可讀文本的格式，二進制文件格式指那種無法用UTF-8等文本解碼的文件如圖片。）

如下圖所示：

如果認為是UTF-8的話，一個編碼可以對應一個文字。文字的字形又是怎么來的呢？它是在字體文件里面， 以svg矢量格式存儲著每個字符的形狀。究竟什么是UTF/UTF-8編碼呢？

UTF編碼

1個字節(jié)最多只表示0 ~ (2^8 – 1)共256個字符，ASCII使用7位表示128個字符，能夠滿足現(xiàn)代英語的要求，對于特殊符號、亞洲語言、Emoj又應該如何表示？我們按上面的方法，查看以下包含中文和Emoji字符的文件存儲的是什么：

we 發(fā) 財  

如下圖所示：

其中20是空格的編碼，可以看到一個英文還是1個字節(jié)，一個中文用了3個字節(jié)，而一個Emoj用了4個字節(jié)。它怎么知道每次應該讀取多少個字節(jié)呢？如下圖所示：

如果一個字節(jié)是0開頭，表示這個字節(jié)就表示一個字符，如果是3個1開頭表示這個字符要占3個字節(jié)，有多少個1就表示當前字符占用了多少個字節(jié)。這個就是UTF-8的存儲特點，UTF規(guī)定了每個字符的編號，而UTF-8定義了字符應該怎么存儲。從unicode官網(wǎng)可以查到，“我”的UTF編碼是6211，如下圖所示：

6211怎么變成utf-8編碼呢？因為6211落在下面這個范圍：

U+ 0800 ~ U+ FFFF: 1110XXXX 10XXXXXX 10XXXXXX 

所以是這么轉(zhuǎn)的：

“我”的utf-8就是E6 88 91，可以對比encodeURIComponent的結(jié)果：

可以說utf-8讓utf得到了實現(xiàn)，utf-8是當前互聯(lián)網(wǎng)上使用最廣的文本編碼方式。除了utf-8還有utf-16，它們和utf的轉(zhuǎn)換關(guān)系如下所示：

UTF-8  
U+ 0000 ~ U+ 007F: 0XXXXXXX 
U+ 0080 ~ U+ 07FF: 110XXXXX 10XXXXXX  
U+ 0800 ~ U+ FFFF: 1110XXXX 10XXXXXX 10XXXXXX  
U+10000 ~ U+10FFFF: 11110XXX 10XXXXXX 10XXXXXX 10XXXXXX 
  
UTF-16  
U+0000 - U+FFFF         xxxxxxxx xxxxxxxx 
U+10000 - U+10FFFF   110110xx xxxxxxxx 110111xx xxxxxxxx 

utf-8的優(yōu)點在于一個英文只要一個字節(jié)，但是一個中文卻是3個字節(jié)，utf-16的優(yōu)點在于編碼長度固定，一個中文只要兩2個字節(jié)，但是一個英文也要兩個字節(jié)。所以對于英文網(wǎng)頁utf-8編碼更加有利，而對于中文網(wǎng)頁使用utf-16應該更加有利。因為絕大部分的中文都是落在U+0000到U+FFFF。而對于Emoj這種不太常用排在后面的符號，不管是utf-8還是utf-16都需要4個字節(jié)。同時utf-32都是固定4個字節(jié)。

完整的UTF編碼可以在官網(wǎng)查到，這里列一些符號及其編碼的范圍，如下圖所示：

中文漢字是從4E00到9FFF，大約有兩萬個。FXXXX和10XXXX的編碼是用于自定義的，如可以用于圖標字體，但是圖標字體通常沒有使用這個范圍，而是用更簡短的編碼，這些編碼剛好映射到其它正常字符集如繁體字，這樣就導致圖標字體還沒加載好之前系統(tǒng)會使用默認的字體，頁面就會先顯示繁體字然后再恢復成圖標。這種問題在安卓手機會出現(xiàn)。

我們可以直接在html上使用UTF編碼，如：

那么網(wǎng)頁上將會顯示：

這個也叫html實體(entity)，通常用于特殊符號的轉(zhuǎn)義或者圖標字體。

然后我們再討論下亂碼。

亂碼

用文本編輯器打開一個二進制文件，例如打開一個圖片文件：

很多文本編輯器默認是使用utf-8編碼，如submlime：

每個編碼如果對應一個符號就顯示出來，但是這些符號連起來看起來比較亂，所以就“亂碼”了。

這里舉一個實際的亂碼問題，windows的壓縮包，在mac解壓文件名通常會亂碼，如下圖所示，這是為什么呢？

windows的默認編碼方式是ANSI，使用windows自帶的文本編輯器可以保存以下幾種編碼：

ANSI根據(jù)locale，簡體中文是使用GBK。什么是GBK呢？GBK是中文的地方性編碼，如“我”的GBK編碼是CED2，最開始的中文編碼標準是GB2312，收錄了6000多個常用漢字，后來又出了GBK，把繁體字收進去了，再后來又出了GB18030把少數(shù)民族的語言收錄了，各種編碼關(guān)系如下圖所示：

但是Mac的軟件一般是使用utf-8，中文應該是3個字節(jié)，但是現(xiàn)在只有2個字節(jié)，還對不上，所以解壓的時候就變成了其它的符號，看起來亂碼了。Mac可以裝一個叫the unarchive的軟件，它有算法自動檢測字符編碼：

用它解壓的文件名就沒有問題。另外，很多代碼編輯器一般默認是使用utf-8，在windows自帶的文本編輯器保存的txt在這種編輯器打開將會亂碼：

當選擇了正確的編碼方式后顯示就正常了：

關(guān)于文字編碼還有一個經(jīng)常會遇到的問題，那就是回車與換行。

回車與換行

Sublime的默認換行方式是根據(jù)系統(tǒng)設置，如下圖Sublime的設置：

從它的注釋還可以看到windows是使用CRLF，而unix系的系統(tǒng)是使用LF：

• CR：Carriage Return （回車\r）
• LF：Line Feed（換行\(zhòng)n）

也就是說windows的換行是\r\n，而unix系的如Mac是使用\n。回車和換行有什么區(qū)別呢？回車是指把光標移到行首，而換行是把光標換到下一行。如果在Node.js里面運行以下代碼：

console.log("hello, world\rgoodbye, world"); 

那么將會輸出”goodbye, world”：

“hello, world”被覆蓋了，這就是回車符的作用。后來可能出于節(jié)省空間的目的，unix的換行就只有\(zhòng)n了。

“\r”在git里面會被顯示成^M：

有時候還會遇到另外一個問題：在綁host的時候，從QQ復制的消息粘貼到host文件里，MAC可能會多了個\r導致沒有生效，而windows可能會少了\r出問題，雖然在你的編輯器里看起來可能都是正常換行的。

再討論下字符串長度的問題。

字符串長度

Java和JS的字符串都是使用UTF-16編碼，因為它有長度比較固定的優(yōu)勢，不像UTF-8字節(jié)數(shù)可能從1變到4。如下圖所示：

英文和中文長度都是1，而Emoj的長度是2，因為長度單位是2個字節(jié)作為1，Emoj的需要4個字節(jié)，因此長度是2。

可以使用charCodeAt返回當前字符的utf編碼：

如果是要檢測中文的話可以使用正則表達式，看當前符號是否落在中文編碼的范圍內(nèi)：

在Mysql里面，如果一個字段的類型為VARCHAR(10)的話，那么它最多可以存儲10個英文或者10個中文，如果這個字段使用的是默認的utf-8編碼，那么它需要占10 * 3 = 30個字節(jié)，如果使用了GBK編碼，那么它需要使用10 * 2 = 20個字節(jié)。

meta charset標簽

我們通常會給頁面head標簽加一個charset的meta，指明當前頁面的編碼方式：

<meta charset="utf-8"> 

在html4里面是這么寫的：

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 

這兩個作用一樣，只是后者已經(jīng)過時。這個編碼究竟有什么用呢？

以下以code.html作為研究：

<!DOCType html> 
<html> 
<head> 
    <meta charset="utf-8"> 
</head> 
<body> 
    你好world 
</body> 
</html> 

然后我們用Node.js寫一個最簡單的server：

let http = require("http"); 
let fs = require("fs"); 
  
http.createServer((req, res) => { 
    let content = fs.readFileSync("./code.html", "utf-8"); 
    console.log(req.url); 
    res.end(content); 
}).listen("8125", err => { 
    if (err) { 
        console.log(err); 
    } else { 
        console.log("Server start, listening on http://localhost:8125"); 
    } 
}); 

運行，然后訪問localhost:8125，頁面正常顯示：

現(xiàn)在我把charset改成gbk：

<meta charset="gbk"> 

然后重新刷新頁面，就不正常了：

但是如果我在Node.js的server里面設置Content-Type的響應頭的charset為utf-8的話：

res.setHeader("Content-Type", "text/html; charset=utf-8"); 

從瀏覽器控制臺可以看到這個響應頭：

不管meta標簽里面設置的是什么編碼，頁面都能正常顯示。

所以根據(jù)我們的觀察meta標簽只有在http的響應頭里沒有設置charset的時候才會起作用。

本篇討論了utf/utf-8/utf-16的關(guān)系，utf是國際標準，規(guī)定了每個字符的編碼，而utf-8/utf-16決定了utf該如何存儲與讀取，utf-8的優(yōu)點是對于英文比較有利，比較節(jié)省空間，utf-16對于中文比較有利。但是如果西方國家使用utf-8，然后東方國家使用utf-16，那么互聯(lián)網(wǎng)可能就亂了，所以從統(tǒng)一標準的角度我們還是使用utf-8。還討論了GBK編碼和亂碼的問題，如果一個字符存的時候是用的一種編碼，但是讀的時候卻用的另一種編碼，那就會對不上原先的字符，就會出現(xiàn)亂碼的情況。另外，由于utf-16編碼長度比較固定，所以JS和Java使用了utf-16做為它們在內(nèi)存里字符串的編碼。根據(jù)實驗，meta的charset標簽在沒有設置響應頭的charset時可以起作用。

總之字符編碼是一個很大的話題，本篇主要討論了和web關(guān)系比較大的部分，還列了平時會遇到的幾個問題。相信看完本文，你對文字編碼應該有了一個比較好的理解。

【本文是51CTO專欄作者“人人網(wǎng)FED”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系原作者獲取授權(quán)】

戳這里，看該作者更多好文