文字編碼的那些事

時間 2019-11-16

原文原文鏈接

咱們常常聽到純文本格式和二進制編碼，什麼是純文本，什麼是二進制呢？以一個例子作說明。新建一個文件叫hello.txt，內容爲：html

hello, world複製代碼

這個文件有12個字節：git

藉助Node.js能夠看這個文件在硬盤的原始二進制存儲是什麼，以下代碼：web

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讀取的方式：sql

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

輸出的就是文本：windows

這裏看到了兩種大相徑庭的輸出結果，但實際上不論是純文本文件仍是二進制文件，硬盤或者內存裏存儲的都是0101，就看你如何解讀它，或者說怎麼解碼。（只不過咱們一般說的純文本是指那種可以解碼成可讀文本的格式，二進制文件格式指那種沒法用UTF-8等文本解碼的文件如圖片。）瀏覽器

以下圖所示：bash

若是認爲是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關係比較大的部分，還列了平時會遇到的幾個問題。相信看完本文，你對文字編碼應該有了一個比較好的理解。