漫話：如何給女朋友解釋什麼是"錕斤拷"？
週末女朋友出去逛街了，我自己一個人在家看綜藝節目，突然，女朋友給我打來電話。
過了一會，女朋友回來了，她拿出手機，給我看了她在超市拍的照片：

要想知道什麼是亂碼，需要先從計算機編碼說起。 字元編碼和ASCII
我們經常看一些諜戰劇，諜戰劇裡敵特、地下黨員以及八路軍各部間傳送情報的時候，一般都是通過電報傳送的，電報在傳遞的過程中，需要發報員用電鍵發出長短不一的電碼，收報員就會聽到電報機發出的滴滴滴答答答的聲音。其實電報發出的聲音都是"滴"和"答"的組合，"答"的聲音是"滴"的三倍長。
發報員要先通過一種方式，將想要傳送的情報轉成電報的滴答聲，收報員在聽到滴答聲之後，再將它們翻譯成正常的文字。這個過程就是字元編碼和字元解碼。
諜戰劇中將情報轉成電報的"滴"和"答"聲主要通過摩爾斯電碼，這是一種通過不同的排列順序來表達不同的英文字母、數字和標點符號的字元編碼方式。莫爾斯電碼由短的和長的電脈衝（稱為點和劃）所組成。點和劃的時間長度都有規定，以一點為一個基本單位，一劃等於三個點的長度。正好對應上電報的"滴"和"答"。
就像電報只能發出"滴"和"答"聲一樣，計算機只認識0和1兩種字元，但是，人類的文字是多種多樣的，如何把人類的文字轉換成計算機認識的01字元呢，這個過程同樣需要通過字元編碼。
字元編碼（Character encoding）是一套法則，使用該法則能夠對自然語言的字元的一個集合（如字母表或音節表），與其他東西的一個集合（如號碼或電脈衝）進行配對。
和摩爾斯電碼功能類似，上個世紀60年代，美國製定了一套字元編碼，對英語字元與二進位制位之間的關係，做了統一規定，這被稱為 ASCII 碼，一直沿用至今。
ASCII（American Standard Code for Information Interchange，美國資訊交換標準程式碼）是基於拉丁字母的一套計算機編碼系統。它主要用於顯示現代英語，其中共有128個字元，包含了所有的大寫和小寫字母，數字0到9、標點符號， 以及在美式英語中使用的特殊控制字元等。
在介紹其他的字元編碼之前，我們先來說一下一個計算機領域通用的字符集。
Unicode（中文：萬國碼、國際碼、統一碼、單一碼）是電腦科學領域裡的一項業界標準。它對世界上大部分的文字系統進行了整理、編碼，使得計算機可以用更為簡單的方式來呈現和處理文字。
Unicode至今仍在不斷增修，每個新版本都加入更多新的字元。目前最新的版本為2019年5月公佈的12.1，這一版本只新增了一個字元，即日本新年號令和的合字。
Unicode備受認可，並廣泛地應用於計算機軟體的國際化與本地化過程。有很多新科技，如可擴充套件置標語言（Extensible Markup Language，簡稱：XML）、Java程式語言以及現代的作業系統，都採用Unicode編碼。
Unicode是一套通用的字符集，包含世界上的大部分文字，也就是說，Unicode是可以表示中文的。
Unicode雖然統一了全世界字元的編碼，但沒有規定如何儲存。這麼做是有考慮的：
如果Unicode統一規定，每個符號就要用三個或四個位元組表示，因為字元太多，只能用這麼多位元組才能表示完全。
一旦這麼規定，那麼每個英文字母前都必然有二到三個位元組是0，因為所有英文字母在ASCII中都有，都可以用一個位元組表示，剩餘位元組位置就要補充0。
如果這樣，文字檔案的大小會因此大出二三倍，這對於儲存來說是極大的浪費。為瞭解決這個問題，就出現了一些中間格式的字符集，他們被稱為通用轉換格式，即UTF（Unicode Transformation Format）。常見的UTF格式有：UTF-7,UTF-7.5,UTF-8,UTF-16,以及 UTF-32。
UTF-8 使用一至四個位元組為每個字元編碼
UTF-16 使用二或四個位元組為每個字元編碼
UTF-32 使用四個位元組為每個字元編碼
所以我們可以說，UTF-8、UTF-16等都是 Unicode 的一種實現方式。
舉個例子，Unicode規定了一箇中文字元 "我"對應的unicode是"\u6211"，但是，在UTF-8和UTF-16等不同的實現方式下，這個二進位制code的儲存方式是不一樣的。
UTF-8使用可變長度位元組來儲存 Unicode字元，例如ASCII字母繼續使用1位元組儲存，重音文字、希臘字母或西裡爾字母等使用2位元組來儲存，而常用的漢字就要使用3位元組。輔助平面字元則使用4位元組。
因為UTF-8是Unicode的一種實現，所以他包含了世界上的所有文字的編碼，他採用的是1-4位元組進行編碼。
對於那些排在前面優先納入的文字，可能就優先使用1位元組、2位元組儲存了，對於後納入的文字，就要使用3位元組或者4位元組儲存了。
正是因為他太全了，所以那些晚一些納入的字元，在UTF-8中的儲存所佔的位元組數可能就會多一些，那他的儲存空間要求就會很大。
對於常用的漢字，在UTF-8中採用3位元組進行編碼，但是如果有一種只包含中文和ASCII的編碼的話，就不需要使用3個位元組，可能2個位元組就夠了。
對於大部分網站來說，基本都是隻服務一個國家或者地區的，比如一箇中國的網站，一般會出現簡體字和繁體字以及一些英文字元，很少會出現日語或者韓文的。
也是出於這樣的考慮，中國國家標準總局於1981年制定並實施了 GB 2312-80 編碼，即中華人民共和國國家標準簡體中文字符集。後來廠商微軟利用GB 2312-80未使用的編碼空間，收錄GB 13000.1-93全部字元制定了GBK編碼。
有了標準中文字符集，如果是一個純中文網站，就可以可以採用這種編碼方式，這樣可以大大節省一些儲存空間的。
常用的中文編碼有GBK，GB2312，GB18030等，最常用的是GBK。
GB2312（1980年）：16位字符集，收錄有6763個簡體漢字，682個符號，共7445個字元；
優點：適用於簡體中文環境，屬於中國國家標準，通行於大陸，新加坡等地也使用此編碼；
缺點：不相容繁體中文，其漢字集合過少。
GBK（1995年）：16位字符集，收錄有21003個漢字，883個符號，共21886個字元；
優點：適用於簡繁中文共存的環境，為簡體Windows所使用，向下完全相容gb2312，向上支援 ISO-10646 國際標準 ；所有字元都可以一對一對映到unicode2.0上；
缺點：不屬於官方標準，和big5之間需要轉換；很多搜尋引擎都不能很好地支援GBK漢字。
GB18030（2000年）：32位字符集；收錄了27484個漢字，同時收錄了藏文、蒙文、維吾爾文等主要的少數民族文字。
優點：可以收錄所有你能想到的文字和符號，屬於中國最新的國家標準；
缺點：目前支援它的軟體較少。
我們還拿前面介紹過的發電報的例子來說，假設有以下場景：
發報員使用"美式摩爾斯電碼"將情報轉換成電報，收報員接收到電報之後，通過"現代國際摩爾斯電碼"進行破譯。那麼得到的情報內容就可能完全看不懂，這就是亂碼了。
就像在計算機領域，我們把一串中文字元通過UTF-8進行編碼傳輸給別人，別人拿到這串文字之後，通過GBK進行解碼，得到的內容就會是“錕屆瀿錕斤拷雮傡錕斤拷直錕斤拷錕”，這就是亂碼。
如以下程式碼：
public static void main(String[] args) throws UnsupportedEncodingException {
String s = "漫話程式設計！";
byte[] bytes = s.getBytes(Charset.forName("GBK"));
System.out.println("GBK編碼，GBK解碼：" + new String(bytes,"GBK"));
System.out.println("GBK編碼，GB18030解碼：" + new String(bytes,"GB18030"));
System.out.println("GBK編碼，UTF-8解碼：" + new String(bytes,"UTF-8"));
}
複製程式碼輸出結果：
GBK編碼，GBK解碼：漫話程式設計！
GBK編碼，GB18030解碼：漫話程式設計！
GBK編碼，UTF-8解碼：????????
複製程式碼可以看到，將中文字元，通過GBK編碼，再使用UTF-8解碼，得到的字元就是一串問號，這就是亂碼了。
因為Unicode是一直在更新的，在這個過程中，肯定有一些比較新的字元他是無法表示的。或者即使Unicode釋出了新版納入了某個文字，但是很多軟體系統並未升級也會有這樣的問題。
就像生活中一些手機廠商新出的那些emoji表情，在自己的手機上可以正常顯示，發到其他品牌的手機上可能就無法顯示。這其實也是字符集不支援導致的。
發生以上情況時，無法顯示的時候也需要有一個字元來表示的，在Unicode中，這個字元就是 � ，他也是Unicode中定義的一個特殊字元。也就是"0xFFFD REPLACEMENT CHARACTER"，所有無法表示的字元都會通過這個字元來表示。
Unicode官方有關於這個符號的介紹，從上表中可以看到，他的10進製表示是65533，在UTF-8下，他的16進位制形式是'0xEF 0xBF 0xBD'（三個位元組）。
如果有兩個連續的字元都無法顯示，如"� �" ，那麼在UTF-8編碼下，16進製表示為：
0xEF 0xBF 0xBD
0xEF 0xBF 0xBD
複製程式碼以上這段編碼，如果放到GBK中進行解碼的話，因為GBK中一個漢字兩個位元組，那麼結果就是：
0xEF 0xBF,0xBD 0xEF,0xBF 0xBD
複製程式碼即
0xEFBF
0xBDEF
0xBFBD
複製程式碼那麼，如果展示出來，就是：錕（0xEFBF），斤（0xBDEF），拷（0xBFBD）,所以，以後再見到錕斤拷，第一時間想到UTF-8和GBK的轉換問題準沒錯。
除了錕斤拷以外，還有兩組比較經典的亂碼，分別是"燙燙燙"和"屯屯屯"，這兩個亂碼產生自VC，這是debug模式下VC對記憶體的初始化操作。VC會把棧中新分配的記憶體初始化為0xcc，而把堆中新分配的記憶體初始化為0xcd。把0xcc和0xcd按照字元打印出來，就是燙和屯了。
