其實不管是用哪種編碼，本質上保存的都是二進制。
一些基本概念與易錯點：
- 不同的編碼，占用的字節數是不一樣的。字符在不同的編碼占用的字節是不相同的，一個字節是8位。所以說，你看到的字符串到底占用多少個字節，要取決于到底是用了哪種編碼。比如在 GB 2312 編碼或 GBK 編碼中，一個漢字字符存儲需要2個字節。在UTF-8編碼中，一個漢字字符儲存需要3到4個字節。
- iOS中的NSData其實就是二進制。由于從上面已經知道一個漢字在不同的編碼，占用的字節數是不一樣的，所以占用的位數也就可能不一樣。所以其實不難理解，為什么要是用對應的編碼才能轉換為正確的字符串了。
- 不要以為保存的數據就肯定能從某種編碼中得到正確的字符串，實際上可能對字節數組進行了修改，不再是UTF8編碼了。比如：UTF8編碼生成的文件，可能由于加密等原因，先轉換為字節數組，對字節數組進行了處理了，然后保存。看到的則是亂碼了。解碼部分，肯定也是對字節數組處理。所以說，如果編碼修改了，兩邊就會無法匹配到一起，假如可以部分匹配到一起，那么可能兩種的字母都是占用一個字節，然后漢字字節數不同。
- 一些加密過的數據，如果進行UTF8來解碼，又編碼，會發現數據導致損壞。比如字節數組修改后，這時實際上用UTF8來解碼，得到的字符串實際上已經不是原來的了。比如字節FF和FE在UTF-8編碼中永遠不會出現，但是由于修改了，出現了這樣的字節就會出錯。所以導致UTF8先解碼，然后編碼的結果不一致。
- 看到一樣，不代表編碼一樣。一個漢字不同的編碼可能占用不同的字節數，就是說二進制位數不相同。所以文件可能是不同的編碼，看到的卻是一樣的字符串。
- nodejs可以使用iconv-lite來進行編碼轉換。
- nodejs中buffer類的單位是字節
