文字亂碼修復方法電腦字體亂碼怎么解決 _字體

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

文章插圖
上面這種，看起來不明所以的內容，通常被稱作亂碼。那么亂碼是如何產生的，并且如何修復呢？我們接下來就一步步對此進行解釋
編碼規則
字符串，本質上都是一個字節一個字節的數據，連在一起存儲的。而要將這些數據顯示在屏幕上，則需要按一種編碼規則進行解析。
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) ，來進行亂碼恢復工作
我們用上一節生成的亂碼數據作為例子，嘗試修復：