計算機字符編碼的前世今生

有人丟給你下面這張圖，如果你能清楚地說明它們之間的關系以及用途，那么你對字符編碼的理解肯定過關了。

不知道看了上面這張圖，是否有混亂的感覺，本文試著給你梳理、講透這些孤立的幾個單詞之間聯(lián)系......

2.1 ASCII（寡頭壟斷時期）

計算機內部，所有信息最終都是一個二進制值。每一個二進制位（bit）有0和1兩種狀態(tài)，8個二進制位稱之為1個字節(jié)。把鍵盤上（如下圖）所有按鍵的狀態(tài)。

用8位二進制共256種表示綽綽有余。把所有的空格、標點符號、數(shù)字、大小寫字母分別用連續(xù)的字節(jié)狀態(tài)表示，一直編到了第127號，這樣計算機利用8位二進制位（1個字節(jié)）就可以用來存儲英語的文字了，這就是大名鼎鼎的ASCII（美國信息互換標準代碼）。當時世界上所有的計算機都用同樣的ASCII方案來保存英文文字。

2.2 非 ASCII 編碼（漢字編碼的發(fā)展）

伴隨著互聯(lián)網的興起，計算機技術的發(fā)展，世界各地都開始使用計算機，但是很多國家用的不是英文，所適用的字母里有許多是ASCII里沒有的。

為了可以在計算機保存他們的文字，決定采用 127號之后的空位來表示這些新的字母、符號，還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序號編到了最后一個狀態(tài)255。

從128 到255這一頁的字符集被稱“擴展字符集”。此之后，貪婪的人類再沒有新的狀態(tài)可以用了。

隨著計算機在中國流行時，已經沒有可以利用的字節(jié)狀態(tài)來表示漢字，況且有6000多個常用漢字需要保存。但這難不倒智慧的中國人民，我們就把那些127號之后的奇異符號們直接取消掉，并規(guī)定：一個小于127的字符的意義與原來相同，但兩個大于127的字符連在一起時，就表示一個漢字，前面的一個字節(jié)（他稱之為高字節(jié)）從0xA1用到0xF7，后面一個字節(jié)（低字節(jié)）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。

在這些編碼里，我們還把數(shù)學符號、羅馬希臘的字母都編進去了，連在 ASCII 里本來就有的數(shù)字、標點、字母都統(tǒng)統(tǒng)重新編了兩個字節(jié)長的編碼，這就是常說的”全角”字符。而原來在127號以下的那些就叫”半角”字符了。中國人民看到這樣很不錯，于是就把這種漢字方案叫做 “GB2312”。GB2312 是對 ASCII 的中文擴展。

（圖片來源于網絡）

（圖片來源于網絡）

但是中國的漢字太多了，我們很快就就發(fā)現(xiàn)有許多人的人名沒有辦法在這里打出來。我們不得不繼續(xù)把GB2312 沒有用到的碼位找出來老實不客氣地用上。后來還是不夠用，于是干脆不再要求低字節(jié)一定是127號之后的內碼，只要第一個字節(jié)是大于127就固定表示這是一個漢字的開始，不管后面跟的是不是擴展字符集里的內容。

結果擴展之后的編碼方案被稱為 GBK 標準，GBK包括了GB2312 的所有內容，同時又增加了近20000個新的漢字（包括繁體字）和符號。后來少數(shù)民族也要用電腦了，于是我們再擴展，又加了幾千個新的少數(shù)民族的字，GBK擴成了 GB18030。

2.3 非 ASCII 編碼

百花齊放，各自編碼標準帶來的問題

當時各個國家都像中國這樣搞出一套自己的編碼標準，結果互相之間誰也不懂誰的編碼，誰也不支持別人的編碼，就連大陸和臺灣這樣只相隔了150海里，使用著同一種語言，也分別采用了不同的 DBCS 編碼方案。

當時的中國人想讓電腦顯示漢字，就必須裝上一個“漢字系統(tǒng)”，專門用來處理漢字的顯示、輸入的問題，像是那個臺灣的愚昧封建人士寫的算命程序就必須加裝另一套支持 BIG5

編碼的什么“倚天漢字系統(tǒng)”才可以用，裝錯了字符系統(tǒng)，顯示就會亂了套！這怎么辦？

而且世界民族之林中還有那些一時用不上電腦的窮苦人民，他們的文字又怎么辦？

（圖片來源于維基百科）

2.4 Unicode

世界這么亂，得我來管管，大一統(tǒng)時期

ISO（國際標準化組織）的國際組織決定著手解決這個問題。采用的方法很簡單：廢了所有的地區(qū)性編碼方案，重新搞一個包括了地球上所有文化、所有字母和符號的編碼！

他們打算叫它“Universal Multiple-Octet Coded Character Set”，簡稱UCS, 俗稱 “Unicode”。Unicode相當于一個抽象層，給每個字符一個唯一的碼點(code point)。

用 0x000000 - 0x10FFFF 這么多的數(shù)字去對應全世界所有的語言、公式、符號。然后把這些數(shù)字分成 17 部分，把常用的放到 0x0000 - 0xFFFF，也就是 2 個字節(jié)，叫做基本平面 （BMP）；從 0x010000 - 0x10FFFF 再劃分為其他平面。

（圖片來源于維基百科）

栗子：「v維」

如果 「v維」 這個字符串放到內存中就是 0x767ef4。問題來了，計算機怎么知道，幾個字節(jié)代表一個字符呢？是 0x76呢？還是 0x7ef4 呢？還是 0x767ef4？

Unicode只是對信源編碼，對字符集數(shù)字化，解決了字符到數(shù)字化的映射。接下來面臨如何解決存儲和傳輸?shù)膯栴}。

?用通信理論的思路可以理解為:

Unicode是信源編碼，對字符集數(shù)字化；

UTF-32、UTF-16、UTF-8是信道編碼，為更好的存儲和傳輸。

3.1 UTF-32

UTF-32 編碼，簡單明了，碼點值是多少，內存中就存多少，UTF-32 缺點很明顯了，字母 A 原本只需要 1 個字節(jié)去存儲，而現(xiàn)在卻用了 4 個字節(jié)去存，大部分位置都是 0。

提問：我們?yōu)槭裁匆啻婺敲炊嗔隳兀?/strong>

3.2 UTF-16

問題：「亮」?碼點值是 20142，換成 16 進制就是?0x4eae，內存中是按字節(jié)進行編址的。所以我們是先存4e呢？還是ae？

一個 Unicode 的碼點值會對應一個數(shù)字，對于Basic平面的字符，我們直接把這個數(shù)字存到內存中。

UTF - 16 編碼的時候，除本身的字節(jié)，為了區(qū)分大端序和小端序，最開頭還多了兩個字節(jié)，ff和fe。feff代表大端序，fffe代表小端序。

（Notepad中的BOM）

小知識：feff和fffe也叫做 BOM，它可以區(qū)分不同編碼。UTF-16 編碼最小單位是兩個字節(jié)，所以有字節(jié)序的問題，從而加了 BOM 來區(qū)分是大端序還是小端序。

3.3 UTF-8

UTF-8 顧名思義，是一套以 8 位為一個編碼單位的可變長編碼。會將一個碼位編碼為 1 到 4 個字節(jié)。一個碼點值會生成 1 個或多個字節(jié)，然后把這些字節(jié)按順序存就可以了。

小知識：UTF-8 無 BOM 或者 UTF-8 BOM。UTF - 8 的 BOM 是 EF BB BF ?，UTF-8 并不存在字節(jié)序的問題，因為它的最小編碼單位就是字節(jié)。?

UTF-8 并不需要區(qū)分大端序還是小端序，所以可以不需要 BOM。如果加了 BOM，對于一些讀取操作，它可能會把讀取到的 BOM 認為是字符，從而造成一些錯誤。所以我們保存 UTF - 8 編碼的文件時，最好選擇無 BOM。

栗子：「知」

根據上表中的編碼規(guī)則，「知」字的碼位 U+77E5 屬于第三行的范圍：

這就是將U+77E5 按照 UTF-8 編碼為字節(jié)序列E79FA5 的過程，反之亦然。

3.4 ANSI

「ANSI」指的是對應當前系統(tǒng) locale 的遺留（legacy）編碼。

Windows 里說的「ANSI」其實是 Windows code pages，這個模式根據當前 locale 選定具體的編碼，比如簡中 locale 下是 GBK。把自己這些 code page 稱作「ANSI」是 Windows 的臭毛病。在 ASCII 范圍內它們應該是和 ASCII 一致的。

3.1 擴展思考

問：在java中char 型變量中能不能存貯一個中文漢字，為什么？

答：java中使用的編碼符號集是Unicode（不涉及特定的編碼方式，給每個符號分配一個二進制編碼，目前已容納容納100多萬個符號），而漢字已納入Unicode字符集， 而char類型占兩個字節(jié)，用來表示Unicode編碼，所以是可以存儲漢字的

問：tomcat的中默認ISO-8859-1編碼，如何解決web項目中的亂碼問題？

答：

方式一：修改tomcat下的conf/server.xml文件

 "8080"  protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8 useBodyEncodingForURI="true"/>

• URIEncoding=”UTF-8“：即可讓Tomcat（默認ISO-8859-1編碼）以UTF-8的編碼處理請求參數(shù)。

• useBodyEncodingForURI="true"：是指請求參數(shù)的編碼方式采用請求體的編碼方式。

方式二：?

1）當使用字符流向瀏覽器發(fā)送頁面信息時，默認查詢的是ISO-8859-1碼表

• 設置1：

  response.setCharacterEncoding("UTF-8")

• 設置2：

  response.setContentType("text/html;charset=UTF-8")

2）客戶端請求服務器出現(xiàn)的中文亂碼解決方式

• POST請求方式：瀏覽器當前使用什么編碼，表單提交的參數(shù)就是什么編碼，

  服務端處理：

  request.setCharacterEncoding("utf-8")。

• GET請求方式：

String name=request.getParameter("name");//首先拿到參數(shù)的值
//得到的byte[] 再重新用utf-8去編碼，即可得到正常的值
name=new String(name.getBytes("iso-8859-1")/**用參數(shù)的值用iso-8859-1來解碼**/,"utf-8");

回到前言中的那個問題，整理了下面這張圖，不知現(xiàn)在的你是否對字符編碼有了更清楚的認識......

用通信理論的思路可以理解為:

Unicode是信源編碼，對字符集數(shù)字化；

UTF-32、UTF-16、UTF-8是信道編碼，為更好的存儲和傳輸。