每天總結一個小知識點，工作小記第3回;

正在學習如何把一個東西給別人講的很簡單。

早上在地鐵上，看到一個公眾號的文章，裡面應該是筆誤，而且一個簡單的東西給說的太晦澀了，我寫個白話暴力版：

Java8中的String的char，應該是Unicode編碼，而不是UTF-8編碼； 已經給文章回復了，但是還沒看到修正。

簡單粗暴地對 Unicode、GBK、UTF-8進行一下比喻：

我們電腦中，有很多檔案，但是發給別人時，一般不會直接發文件本體，而是打包發zip壓縮包、rar壓縮包、或者7z、tar.gz等。因為壓縮可以顯著減少體積，加快傳輸速度。

可以粗暴地把 電腦裡的檔案類比為Unicode， 把各種壓縮工具  類比為 GBK，UTF-8。

Unicode叫做萬國碼，全球統一的標準。用了16位來定位表達文字，如果全世界都統一用Unicode，而且通訊的時候直接使用原生的Unicode，不就什麼麻煩都沒有了。

實際上，java8的String內部的Char[] 儲存的就是原生的Unicode。但是問題是：Unicode在儲存和傳輸時體積較大，因為有16位來表示，即使是 abcd這種ascii，也需要16位。 如果字串都是abcd這種字元，那麼就是一倍的額外儲存代價，如果要傳輸，就是額外的一倍頻寬。

所以，有一系列的GBK、UTF-8的編碼方案來實現Unicode雙向對映。 這種編碼方案就是在表達同樣資訊的前提下，儘可能少的佔用空間。 就類似zip、rar這種不同的壓縮方案。 不同的壓縮技術對應不同的場景。

decode("UTF-8")  --> 對應壓縮軟體的 解壓操作
encode("UTF-8")  --> 對應壓縮軟體的 打包操作

所以，我們想把rar壓縮包變成7z檔案，就需要先解壓，解壓為普通檔案，再壓縮為7z檔案。

同樣類比，想把UTF-8變成GBK，就先把UTF-8的資料 解壓，decode("UTF-8")為Unicode【java8的String裡面是Char，Unicode】， 這樣就得到了原生的檔案之類的，再encode("GBK")打包為別的格式。