日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
講講文字編碼的那些事

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

 
 
 
 
    
  
  
  
  
  1. hello, world 
    2.

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

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

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

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

 
 
 
 
    
  
  
  
  
  1.  
    2.

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

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

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

輸出的就是文本：

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

如下圖所示：

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

UTF編碼

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

 
 
 
 
    
  
  
  
  
  1. we 發(fā) 財  
    2.

如下圖所示：

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

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

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

 
 
 
 
    
  
  
  
  
  1. U+ 0800 ~ U+ FFFF: 1110XXXX 10XXXXXX 10XXXXXX 
    2.

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

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

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

 
 
 
 
    
  
  
  
  
  1. UTF-8  
    2. 
  
  
  
  
  2. U+ 0000 ~ U+ 007F: 0XXXXXXX 
    3. 
  
  
  
  
  3. U+ 0080 ~ U+ 07FF: 110XXXXX 10XXXXXX  
    4. 
  
  
  
  
  4. U+ 0800 ~ U+ FFFF: 1110XXXX 10XXXXXX 10XXXXXX  
    5. 
  
  
  
  
  5. U+10000 ~ U+10FFFF: 11110XXX 10XXXXXX 10XXXXXX 10XXXXXX 
    6. 
  
  
  
  
  6.   
    7. 
  
  
  
  
  7. UTF-16  
    8. 
  
  
  
  
  8. U+0000 - U+FFFF         xxxxxxxx xxxxxxxx 
    9. 
  
  
  
  
  9. U+10000 - U+10FFFF   110110xx xxxxxxxx 110111xx xxxxxxxx 
    10.

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

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

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

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

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

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

然后我們再討論下亂碼。

亂碼

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

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

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

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

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

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

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

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

當(dāng)選擇了正確的編碼方式后顯示就正常了：

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

回車與換行

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

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

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

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

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

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

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

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

有時候還會遇到另外一個問題：在綁host的時候，從QQ復(fù)制的消息粘貼到host文件里，MAC可能會多了個\r導(dǎo)致沒有生效，而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返回當(dāng)前字符的utf編碼：

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

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

meta charset標(biāo)簽

我們通常會給頁面head標(biāo)簽加一個charset的meta，指明當(dāng)前頁面的編碼方式：

 
 
 
 
    
  
  
  
  
  1.  
    2.

在html4里面是這么寫的：

 
 
 
 
    
  
  
  
  
  1.  
    2.

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

以下以code.html作為研究：

 
 
 
 
    
  
  
  
  
  1.  
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3.  
    4. 
  
  
  
  
  4.      
    5. 
  
  
  
  
  5.  
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7.     你好world 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9.  
    10.

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

 
 
 
 
    
  
  
  
  
  1. let http = require("http"); 
    2. 
  
  
  
  
  2. let fs = require("fs"); 
    3. 
  
  
  
  
  3.   
    4. 
  
  
  
  
  4. http.createServer((req, res) => { 
    5. 
  
  
  
  
  5.     let content = fs.readFileSync("./code.html", "utf-8"); 
    6. 
  
  
  
  
  6.     console.log(req.url); 
    7. 
  
  
  
  
  7.     res.end(content); 
    8. 
  
  
  
  
  8. }).listen("8125", err => { 
    9. 
  
  
  
  
  9.     if (err) { 
    10. 
  
  
  
  
  10.         console.log(err); 
    11. 
  
  
  
  
  11.     } else { 
    12. 
  
  
  
  
  12.         console.log("Server start, listening on http://localhost:8125"); 
    13. 
  
  
  
  
  13.     } 
    14. 
  
  
  
  
  14. }); 
    15.

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

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

 
 
 
 
    
  
  
  
  
  1.  
    2.

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

但是如果我在Node.js的server里面設(shè)置Content-Type的響應(yīng)頭的charset為utf-8的話：

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

從瀏覽器控制臺可以看到這個響應(yīng)頭：

不管meta標(biāo)簽里面設(shè)置的是什么編碼，頁面都能正常顯示。

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

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

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

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


名稱欄目：講講文字編碼的那些事
網(wǎng)頁URL：http://www.dlmjj.cn/article/cdhhssg.html