最近遇到一個關(guān)于字符編碼與解碼的問題，使用GB2312保存了一個文件，然后使用vscode打開的時候，發(fā)現(xiàn)中文字符全是亂碼了。為什么會出現(xiàn)這個問題？研究了一下編碼與解碼。

文件在計算機上存儲的都是二進制。顧名思義，編碼就是把一個字符編碼成二進制碼存起來的方式，而解碼就是把這個二進制碼按照原本編碼的規(guī)則還原成原來的字符。

我們經(jīng)常使用的ASCII碼，是上個世紀60年代美國制定的一套字符編碼，它規(guī)定了英語字符與二進制位之間的關(guān)系，一直沿用至今。ASCII 碼一共規(guī)定了128個字符的編碼。ASCII使用一個字節(jié)來進行編碼，一個字節(jié)有8個bit位，ASCII只使用了后面的7個bit位，最前面的一個bit位使用0填充。

一些歐洲國家發(fā)現(xiàn)ASCII編碼的128個字符不能表示他們的語言的所有的字符，所以他們決定啟用最前面的一位，這樣一來，就可以編碼256個字符了，比以前又多了128個字符可以使用。

但是又有問題出現(xiàn)了，不同的國家的字母不一樣，他們啟用最高位來進行編碼，不同的語言有不同的編碼方式，導致了同樣的編碼在不同的國家代表的字符不一樣；例如法語中130代表é，但是在希臘語中代表的是?。注意由于各個國家都是在美國制定的標準上來擴充ASCII的，他們都保留了美國人制定的標準，也就是說所有的字符編碼中，0-127表示的符號是一樣的，128-256表示的符號在各個國家制定的編碼表中是不一樣的。對于中文來說，256個字符根本不夠用，常用的漢字就有5000多個，所以沒有辦法使用ASCII進行編碼。

這時候為了統(tǒng)一編碼，并且能夠表示全世界所有的符號，就出現(xiàn)了Unicode編碼。unicode是一個標準，也可以說是世界上的語言字符和數(shù)字映射的一種標準。它沒有限制字符的數(shù)量，但是可能這個標準規(guī)定的映射只是映射了一部分字符。網(wǎng)上說的Unicode編碼占二個字節(jié)或者四個字節(jié)都是有問題的（目前來說，可能占兩個字節(jié)（使用UCS-2），也可能占四個字節(jié)（使用UCS-4）關(guān)于UCS-2和UCS-4感興趣可以了解一下）。Unicode 只是一個符號集，它只規(guī)定了符號的二進制代碼，卻沒有規(guī)定這個二進制代碼應該如何存儲，也就是說沒有指定存儲的時候使用多少個字節(jié)。

　　 Unicode是字符集，為每一個「字符」分配一個唯一的 ID（學名為碼位 / 碼點 / Code Point）。簡單的理解就是，拿中文來說，常用的漢字有5000多個，那么就是給每一個漢字一個唯一的編號（比如說1-5000），這就是所謂的unicode字符集，對于其他語言的字符，也有一個唯一的編號。

這時候出現(xiàn)了UTF-8編碼，UTF-8編碼是一種可變長度編碼，它可以使用1~4個字節(jié)表示一個符號，根據(jù)不同的符號而變化字節(jié)長度。UTF-8編碼也能夠表示全世界所有的字符。UTF-8 是 Unicode 的實現(xiàn)方式之一。

UTF-8是編碼規(guī)則，將「碼位」轉(zhuǎn)換為字節(jié)序列的規(guī)則（編碼/解碼 可以理解為 加密/解密 的過程）。由于Unicode只是定義了每一個字符對應的編號，但是計算機只能處理二進制，所以存儲以及內(nèi)存中的字符必須被編碼成二進制形式，這時候UTF-8就起作用了。UTF-8定義了一套規(guī)則，能夠?qū)nicode給每一個字符的編號，轉(zhuǎn)換成計算機能夠理解的二進制。這樣計算機能夠理解。

UTF-8 的編碼規(guī)則很簡單，只有二條：

1）對于單字節(jié)的符號，字節(jié)的第一位設(shè)為0，后面7位為這個符號的 Unicode 碼。因此對于英語字母，UTF-8 編碼和 ASCII 碼是相同的。

2）對于n字節(jié)的符號（n > 1），第一個字節(jié)的前n位都設(shè)為1，第n + 1位設(shè)為0，后面字節(jié)的前兩位一律設(shè)為10。剩下的沒有提及的二進制位，全部為這個符號的 Unicode 碼。

下表總結(jié)了UTF-8編碼規(guī)則，字母x表示可用編碼的位。（四條編碼規(guī)則）

Unicode符號范圍     |        UTF-8編碼方式
(十六進制)          |              （二進制）
----------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx                                 第一條編碼規(guī)則
0000 0080-0000 07FF | 110xxxxx 10xxxxxx                        第二條編碼規(guī)則
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx               第三條編碼規(guī)則
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx      第四條編碼規(guī)則

上面弄清楚了ASCII，Unicode，UTF-8編碼之間的關(guān)系。可以發(fā)現(xiàn)其實某一個字符的UTF-8編碼的二進制其實還是保存的對應的Unicode編碼的二進制。

其實在計算機內(nèi)存中，統(tǒng)一使用Unicode編碼，當需要保存到硬盤或者需要傳輸?shù)臅r候，會進行相應的轉(zhuǎn)換。存儲在磁盤上的都是二進制數(shù)據(jù)，只不過編碼方式可能不一樣，有可能是UTF-8或者GB2312等。

當我們保存文件的時候，如果選擇的是UTF-8編碼進行保存，那么存儲在計算機內(nèi)存中的Unicode編碼的二進制就會根據(jù)上面介紹的UTF-8編碼規(guī)則被編碼成UTF-8形式的二進制存儲到磁盤上。

當我們打開文件的時候，假設(shè)存儲文件的時候使用的是UTF-8進行編碼的，那么在打開文件進行解碼的時候，就會根據(jù)上面介紹的UTF-8編碼規(guī)則進行解碼，得到Unicode編碼的二進制，然后查找Unicode碼表，找到對應的字符進行顯示。

回到剛開始遇到的問題。當我們使用vscode打開一個實際上是GB2312編碼的文件的時候，vscode默認是使用utf-8來進行解碼的。分析一下出現(xiàn)亂碼的原因：

就拿中文“漢”字來說，它的GB2312編碼是“BABA”，存儲在磁盤上的二進制是1011 1010 1011 1010。如果使用vscode直接打開，vscode會直接使用UTF-8進行解碼，vscode會根據(jù)UTF-8的編碼規(guī)則去解碼，它會發(fā)現(xiàn)1011 1010 1011 1010根本不能對應上UTF-8的任何一條編碼規(guī)則，這時候vscode就不能識別，就會出現(xiàn)亂碼了。

當然有些漢字，例如“聯(lián)通”的GB2312編碼是”C1AA CDA8“ ，恰好符合UTF-8的編碼規(guī)則（這只是一種巧合），存儲在磁盤上的二進制是：

1100 0001 1010 1010  第一、二字節(jié)
1100 1101 1010 1000  第三、四字節(jié)

同樣vscode使用UTF-8去解碼的時候，發(fā)現(xiàn)它對應于UTF-8第二條編碼規(guī)則。這時候就會提取出Unicode編碼的二進制，把第一個字節(jié)的110和第二個字節(jié)的10去掉，我們就得到了“00001 101010”，從低字節(jié)開始進行各位對齊，補上前導的0，就得到了“0000 0000 0110 1010”的Unicode二進制編碼，這是UNICODE的006A；同理，把第三個字節(jié)的110和第四個字節(jié)的10去掉，得到了“01101 101000”，同樣從低字節(jié)開始對齊各位，得到了“0000 0011 0101 1000”的Unicode二進制編碼，這是UNICODE的0368。

下一步會去查找Unicode編碼表，看這些Unicode編碼對應的字符是什么，006A對應的是小寫字母“j”，0368什么也不是，這個時候就會出現(xiàn)亂碼了。

對應于vscode使用UTF-8解碼其它的GB2312的字符，原理是類似的，由于不能夠準確解析，就會出現(xiàn)亂碼。如果想解決這個亂碼問題，可以先使用GB2312打開該文件，然后再使用UTF-8重新保存該文件就可以了。參考https://www.cnblogs.com/wangwenhui/p/11987569.html

參考鏈接：http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html

總結(jié)

以上是生活随笔為你收集整理的字符编码与解码，乱码原因分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。