講講文字編碼的那些事
我們經常聽到純文本格式和二進制編碼，什么是純文本，什么是二進制呢？以一個例子做說明。新建一個文件叫hello.txt，內容為：
- hello, world
這個文件有12個字節：
借助Node.js可以看這個文件在硬盤的原始二進制存儲是什么，如下代碼：
- let fs = require("fs");
- // 讀取原始二進制內容
- let buffer = fs.readFileSync("hello.txt");
- console.log(buffer);
運行后控制臺輸出12個字節的二進制內容（以十六進制顯示）：
- <Buffer 68 65 6c 6c 6f 2c 20 77 6f 72 6c 64>
參考ASCII表，我們發現這些數字剛好是英文對應的ASCII編碼，如下圖所示：
如果這個文本文件以utf-8讀取的方式：
- let fs = require("fs");
- let text = fs.readFileSync("hello.txt", "utf-8");
- console.log(text);
輸出的就是文本：
這里看到了兩種截然不同的輸出結果，但實際上不管是純文本文件還是二進制文件，硬盤或者內存里存儲的都是0101，就看你如何解讀它，或者說怎么解碼。（只不過我們通常說的純文本是指那種能夠解碼成可讀文本的格式，二進制文件格式指那種無法用UTF-8等文本解碼的文件如圖片。）
如下圖所示：
如果認為是UTF-8的話，一個編碼可以對應一個文字。文字的字形又是怎么來的呢？它是在字體文件里面， 以svg矢量格式存儲著每個字符的形狀。究竟什么是UTF/UTF-8編碼呢？
UTF編碼
1個字節最多只表示0 ~ (2^8 – 1)共256個字符，ASCII使用7位表示128個字符，能夠滿足現代英語的要求，對于特殊符號、亞洲語言、Emoj又應該如何表示？我們按上面的方法，查看以下包含中文和Emoji字符的文件存儲的是什么：
- we 發 財
如下圖所示：
其中20是空格的編碼，可以看到一個英文還是1個字節，一個中文用了3個字節，而一個Emoj用了4個字節。它怎么知道每次應該讀取多少個字節呢？如下圖所示：
如果一個字節是0開頭，表示這個字節就表示一個字符，如果是3個1開頭表示這個字符要占3個字節，有多少個1就表示當前字符占用了多少個字節。這個就是UTF-8的存儲特點，UTF規定了每個字符的編號，而UTF-8定義了字符應該怎么存儲。從unicode官網可以查到，“我”的UTF編碼是6211，如下圖所示：
6211怎么變成utf-8編碼呢？因為6211落在下面這個范圍：
- U+ 0800 ~ U+ FFFF: 1110XXXX 10XXXXXX 10XXXXXX
所以是這么轉的：
“我”的utf-8就是E6 88 91，可以對比encodeURIComponent的結果：
可以說utf-8讓utf得到了實現，utf-8是當前互聯網上使用最廣的文本編碼方式。除了utf-8還有utf-16，它們和utf的轉換關系如下所示：
- 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的優點在于一個英文只要一個字節，但是一個中文卻是3個字節，utf-16的優點在于編碼長度固定，一個中文只要兩2個字節，但是一個英文也要兩個字節。所以對于英文網頁utf-8編碼更加有利，而對于中文網頁使用utf-16應該更加有利。因為絕大部分的中文都是落在U+0000到U+FFFF。而對于Emoj這種不太常用排在后面的符號，不管是utf-8還是utf-16都需要4個字節。同時utf-32都是固定4個字節。
完整的UTF編碼可以在官網查到，這里列一些符號及其編碼的范圍，如下圖所示：
中文漢字是從4E00到9FFF，大約有兩萬個。FXXXX和10XXXX的編碼是用于自定義的，如可以用于圖標字體，但是圖標字體通常沒有使用這個范圍，而是用更簡短的編碼，這些編碼剛好映射到其它正常字符集如繁體字，這樣就導致圖標字體還沒加載好之前系統會使用默認的字體，頁面就會先顯示繁體字然后再恢復成圖標。這種問題在安卓手機會出現。
我們可以直接在html上使用UTF編碼，如：
那么網頁上將會顯示：
這個也叫html實體(entity)，通常用于特殊符號的轉義或者圖標字體。
然后我們再討論下亂碼。
亂碼
用文本編輯器打開一個二進制文件，例如打開一個圖片文件：
很多文本編輯器默認是使用utf-8編碼，如submlime：
每個編碼如果對應一個符號就顯示出來，但是這些符號連起來看起來比較亂，所以就“亂碼”了。
這里舉一個實際的亂碼問題，windows的壓縮包，在mac解壓文件名通常會亂碼，如下圖所示，這是為什么呢？
windows的默認編碼方式是ANSI，使用windows自帶的文本編輯器可以保存以下幾種編碼：
ANSI根據locale，簡體中文是使用GBK。什么是GBK呢？GBK是中文的地方性編碼，如“我”的GBK編碼是CED2，最開始的中文編碼標準是GB2312，收錄了6000多個常用漢字，后來又出了GBK，把繁體字收進去了，再后來又出了GB18030把少數民族的語言收錄了，各種編碼關系如下圖所示：
但是Mac的軟件一般是使用utf-8，中文應該是3個字節，但是現在只有2個字節，還對不上，所以解壓的時候就變成了其它的符號，看起來亂碼了。Mac可以裝一個叫the unarchive的軟件，它有算法自動檢測字符編碼：
用它解壓的文件名就沒有問題。另外，很多代碼編輯器一般默認是使用utf-8，在windows自帶的文本編輯器保存的txt在這種編輯器打開將會亂碼：
當選擇了正確的編碼方式后顯示就正常了：
關于文字編碼還有一個經常會遇到的問題，那就是回車與換行。
回車與換行
Sublime的默認換行方式是根據系統設置，如下圖Sublime的設置：
從它的注釋還可以看到windows是使用CRLF，而unix系的系統是使用LF：
- CR：Carriage Return （回車\r）
- LF：Line Feed（換行\n）
也就是說windows的換行是\r\n，而unix系的如Mac是使用\n。回車和換行有什么區別呢？回車是指把光標移到行首，而換行是把光標換到下一行。如果在Node.js里面運行以下代碼：
- console.log("hello, world\rgoodbye, world");
那么將會輸出”goodbye, world”：
“hello, world”被覆蓋了，這就是回車符的作用。后來可能出于節省空間的目的，unix的換行就只有\n了。
“\r”在git里面會被顯示成^M：
有時候還會遇到另外一個問題：在綁host的時候，從QQ復制的消息粘貼到host文件里，MAC可能會多了個\r導致沒有生效，而windows可能會少了\r出問題，雖然在你的編輯器里看起來可能都是正常換行的。
再討論下字符串長度的問題。
字符串長度
Java和JS的字符串都是使用UTF-16編碼，因為它有長度比較固定的優勢，不像UTF-8字節數可能從1變到4。如下圖所示：
英文和中文長度都是1，而Emoj的長度是2，因為長度單位是2個字節作為1，Emoj的需要4個字節，因此長度是2。
可以使用charCodeAt返回當前字符的utf編碼：
如果是要檢測中文的話可以使用正則表達式，看當前符號是否落在中文編碼的范圍內：
在Mysql里面，如果一個字段的類型為VARCHAR(10)的話，那么它最多可以存儲10個英文或者10個中文，如果這個字段使用的是默認的utf-8編碼，那么它需要占10 * 3 = 30個字節，如果使用了GBK編碼，那么它需要使用10 * 2 = 20個字節。
meta charset標簽
我們通常會給頁面head標簽加一個charset的meta，指明當前頁面的編碼方式：
- <meta charset="utf-8">
在html4里面是這么寫的：
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
這兩個作用一樣，只是后者已經過時。這個編碼究竟有什么用呢？
以下以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，頁面正常顯示：
現在我把charset改成gbk：
- <meta charset="gbk">
然后重新刷新頁面，就不正常了：
但是如果我在Node.js的server里面設置Content-Type的響應頭的charset為utf-8的話：
- res.setHeader("Content-Type", "text/html; charset=utf-8");
從瀏覽器控制臺可以看到這個響應頭：
不管meta標簽里面設置的是什么編碼，頁面都能正常顯示。
所以根據我們的觀察meta標簽只有在http的響應頭里沒有設置charset的時候才會起作用。
本篇討論了utf/utf-8/utf-16的關系，utf是國際標準，規定了每個字符的編碼，而utf-8/utf-16決定了utf該如何存儲與讀取，utf-8的優點是對于英文比較有利，比較節省空間，utf-16對于中文比較有利。但是如果西方國家使用utf-8，然后東方國家使用utf-16，那么互聯網可能就亂了，所以從統一標準的角度我們還是使用utf-8。還討論了GBK編碼和亂碼的問題，如果一個字符存的時候是用的一種編碼，但是讀的時候卻用的另一種編碼，那就會對不上原先的字符，就會出現亂碼的情況。另外，由于utf-16編碼長度比較固定，所以JS和Java使用了utf-16做為它們在內存里字符串的編碼。根據實驗，meta的charset標簽在沒有設置響應頭的charset時可以起作用。
總之字符編碼是一個很大的話題，本篇主要討論了和web關系比較大的部分，還列了平時會遇到的幾個問題。相信看完本文，你對文字編碼應該有了一個比較好的理解。
【本文是51CTO專欄作者“人人網FED”的原創稿件，轉載請通過51CTO聯系原作者獲取授權】
