文字亂碼修復方法：電腦字體亂碼怎麼解決

相信大家在日常生活中，都見過類似下面的這些類似的字元串：

上面這種，看起來不明所以的內容，通常被稱作亂碼。那麼亂碼是如何產生的，並且如何修復呢？我們接下來就一步步對此進行解釋

編碼規則

字元串，本質上都是一個位元組一個位元組的數據，連在一起存儲的。而要將這些數據顯示在屏幕上，則需要按一種編碼規則進行解析。

ASCII

ASCII編碼是最容易理解的。ASCII編碼因為每個字元僅佔用7bit，所以最多只能存儲127個字元，而每個字元都有唯一的一個數字與其對應。

例如：

數字0x35在這種編碼規則下，會被解析為字元5

數字0x6C在這種編碼規則下，會被解析為字元l

數字0x4C在這種編碼規則下，會被解析為字元L

具體對應規則，可以在網上搜索ASCII 碼錶查看

按照這種規則，一串hello，用16進位數據表示就是68 65 6C 6C 6F

GB2312

因為ASCII只能顯示127個字元，遠遠不能滿足中文字元的顯示需求，所以中國國家標準總局於1980年發布了國家標準代碼 GB 2312 標準（目前最新標準為 GB 18030）

簡單來說，在這套編碼規範下，每個中文字元可以由2個位元組表示，例如：

啊的實際數據為0xB0 0xA1

測的實際數據為0xB2 0xE2

試的實際數據為0xCA 0xD4

同時，因為ASCII編碼下每位元組使用了7bit（0x00-0x7f）,GB2312為了對其進行兼容，規定每個中文字元的高位位元組（第一個位元組）使用0xA1–0xF7的範圍，避開了ASCII編碼使用的區域。

也就是說，想下面的一串混用了中英文的數據，也可以正常被解析並顯示出來：

UTF-8

UTF-8可以使用1-4位元組來表示字元，因為其兼容性強，可以對Unicode字符集中的所有有效編碼點進行編碼，是目前使用最廣泛的編碼標準。

與GB2312一樣，UTF-8同樣兼容ASCII編碼。只是UTF-8比GB2312包含了更多字元，並且每種字元的位元組數並不是完全固定的。由於編碼規則比較複雜，這裡不作具體解釋，只會舉例說明：

啊的實際數據為0xE5 0x95 0x8A

測的實際數據為0xE6 0xB5 0x8B

試的實際數據為0xE8 0xAF 0x95

其他編碼

除了GB2312、UTF-8和ASCII編碼，還有許多編碼標準，他們大部分互不兼容。

存儲和傳輸字元串數據

數據都是要進行存儲和傳輸的

存儲

微軟使用BOM 頭這種技術來為純文本文件標記其編碼，這樣打開文件時就可以用正確的編碼進行解析。

而大部分Linux不使用類似技術，所以讀取後只能靠猜測，或強行指定，來進行顯示。

傳輸

傳輸不僅指字元串數據在互聯網上的傳輸，也包括了在各類函數調用過程中的傳輸。這類操作通常都不會帶有字元編碼標準的標記，一般靠直接指定編碼來解決。

產生亂碼

聰明的你應該已經想到了，如果一串某編碼的數據，被人使用另一種編碼標準進行解析，那麼得出的結果幾乎一定是錯誤的。

比如測試解析結果這幾個字，我們使用UTF-8編碼，得到下面16進位數據：

如果，收到這些數據的人嘗試使用GB2312編碼來顯示，那麼結果就是我們非常熟悉的亂碼了：

上面的過程就是典型的亂碼形成過程

修復亂碼

亂碼是否可以還原？答案是肯定的，只需要按亂碼形成時的操作反過來做一遍就可以恢復了。但是有些編碼中會出現?這種無法解析顯示的數據，這部分數據就完全丟失了。

一般的亂碼修復操作，就是把各種編碼可能性都試一遍，看哪個結果可靠，那麼就是原始內容。

這裡推薦使用開源的工具 llcom (llcom.papapoi.com)，來進行亂碼恢復工作

我們用上一節生成的亂碼數據作為例子，嘗試修復：

可以看到可靠的結果已經顯示出來，修復成功

避免亂碼

建議在寫代碼時統一使用UTF-8編碼，這是目前互聯網的最主要的編碼形式

如果是資源佔用緊張，但依舊需要中文顯示的地方，可以考慮使用GB2312編碼存儲數據