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