1、JVM中單個字符佔用的字節長度跟編碼方式有關，而默認編碼方式又跟平臺是一一對應的或說平臺決定了默認字符編碼方式；
2、對於單個字符：ISO-8859-1單字節編碼，GBK雙字節編碼，UTF-8三字節編碼；因此中文平臺(中文平臺默認字符集編碼GBK)下一個中文字符佔2個字節，而英文平臺(英文平臺默認字符集編碼Cp1252(類似於ISO-8859-1))。
3、getBytes()、getBytes(encoding)函數的作用是使用系統默認或者指定的字符集編碼方式，將字符串編碼成字節數組。
編碼方式決定字節長度；在中文平臺下，默認的字符集編碼是GBK，此時如果使用getBytes()或getBytes("GBK")，則按照GBK的編碼規則將每個中文字符用2個byte表示。所以我們看到"中文"最終GBK編碼結果就是： -42 -48 -50 -60 。-42和-48代表了"中"字，而"-50"和"-60"則代表了"文"字。
在中文平臺下，如果指定的字符集編碼是UTF-8，那麼按照UTF-8對中文的編碼規則：每個中文用3個字節表示，那麼"中文"這兩個字符最終被編碼成：-28 -72 -83、-26 -106 -121兩組。每3個字節代表一箇中文字符。
在中文平臺下，如果指定的字符集編碼是ISO-8859-1，由於此字符集是單字節編碼，所以使用getBytes("ISO-8859-1")時，每個字符只取一個字節，每個漢字只取到了一半的字符。另外一半的字節丟失了。由於這一半的字符在字符集中找不到對應的字符，所以默認使用編碼63代替，也就是?。
在英文平臺下，默認的字符集編碼是Cp1252(類似於ISO-8859-1)，如果使用GBK、UTF-8進行編碼，得到的字節數組依然是正確的(GBK4個字節，UTF-8是6個字節)。因爲在JVM內部是以Unicode存儲字符串的，使用getBytes(encoding)會讓JVM進行一次Unicode到指定編碼之間的轉換。對於GBK，JVM依然會轉換成4個字節，對於UTF-8，JVM依然會轉換成6個字節。但是對於ISO-8859-1，則由於無法轉換(2個字節--->1個字節，截取了一半的字節)，所以轉換後的結果是錯誤的。
在中文平臺下，默認的字符集編碼是GBK，於是content.getBytes()得到的是什麼呢？就是下面這4個字節：
byte[0] = -42 hex string = ffffffd6
byte[1] = -48 hex string = ffffffd0
byte[2] = -50 hex string = ffffffce
byte[3] = -60 hex string = ffffffc4
如果新的encoding是GBK，那麼經過解碼後，由於一個字符用2個字節表示。於是最終的結果就是：
char[0]='中' --- byte[0] + byte[1]
char[1]='文' --- byte[2] + byte[3]
如果新的encoding是ISO-8859-1，那麼經過解碼後，由於一個字符用1個字節表示，於是原來本應該2個字節一起解析的變成單個字節解析，每個字節都代表了一個漢字字符的一半。這一半的字節在ISO-8859-1中找不到對應的字符，就變成了"?"了，最終的結果：
char[0]='?' ---- byte[0]
char[1]='?' ---- byte[1]
char[2]='?' ---- byte[2]
char[3]='?' ---- byte[3]
如果新的encoding是UTF-8，那麼經過解碼後，由於一個字符用3個字節表示，於是原來4個字節的數據無法正常的解析成UTF-8的數據，最終的結果也是每一個都變成"?"。
char[0]='?' ---- byte[0]
char[1]='?' ---- byte[1]
char[2]='?' ---- byte[2]
char[3]='?' ---- byte[3]
如果是在英文平臺下，由於默認的編碼方式是Cp1252，於是content.getBytes()得到的字節都是被截去一半的殘留字符，所以我們看到在英文平臺下，不論指定的encoding是GBK、UTF-8，其結果和ISO-8859-1都是一樣的。
記住：這個方法再次證明了String的getBytes()方法的危險性，如果我們使用new String(str.getBytes(), encoding)對字符串進行重新編碼解碼時，我們一定要清楚str.getBytes()方法返回的字節數組的長度、內容到底是什麼，因爲在接下來使用新的encoding進行編碼解碼時，Java並不會自動地對字節數組進行擴展以適應新的encoding。而是按照新的編碼方法直接對該字節數組進行解析。於是結果就像上面的例子一樣，同樣是4個原始字節，有些每2個一組進行解析，有些每個一組進行解析，有些每3個一組進行解析。其結果就只能看那種編碼方式合適了。
結論：相同的平臺下，同一個中文字符，在不同的編碼方式下，得到的是完全不同的字節數組。這些字節數組有可能是正確的(只要該字符集支持中文)，也可能是完全錯誤的(該字符集不支持中文)。
記住：不要輕易地使用或濫用String類的getBytes(encoding)方法，更要儘量避免使用getBytes()方法。因爲這個方法是平臺依賴的，在平臺不可預知的情況下完全可能得到不同的結果。如果一定要進行字節編碼，則用戶要確保encoding的方法就是當初字符串輸入時的encoding。
———————————————————————————————————————————————————
和getBytes(encoding)不同，toCharArray()返回的是"自然字符"。但是這個"自然字符"的數目和內容卻是由原始的編碼方式決定的。
FileWriter是字符流輸出流，而OutputStreamWriter是字節流輸出流在中文平臺下，如果使用FileWriter，不論你如何設置字符集都不會起作用。因爲它採用的是默認的系統字符集。即便你設置了System.setProperty("file.encoding", "ISO-8859-1")，或者在運行時給予參數-Dfile.encoding=UTF-8都不會起作用。你會發現它最終還是都已"GB2312"或者"GBK"的方式保存。
在中文平臺下，如果使用OutputStreamWriter，則在後臺寫入時會把字符流轉換成字節流，此時指定的編碼字符集就起作用了。可以看到在指定GBK、UTF-8的情況下中文可以正常的保存和讀取，同時文件按照我們給定的方式保存了。而對於ISO-8859-1則變成了?，這再次證明了採用ISO-8859-1是不能保存中文的，而且會因爲中文編碼在ISO-8859-1的編碼中找不到對應的字符而默認轉換成?。
在英文平臺下，如果使用FileWriter，不論你如何設置字符集同樣都不會起作用。所有的文件都將按照ISO-8859-1的編碼方式保存，毫無疑問地變成了?。在英文平臺下，如果使用OutputStreamWriter，則只有當我們把字符和文件的編碼方式正確設置爲GBK、UTF-8的情況下，中文才能正確的保存並顯示。
通過上述的實驗證明，爲了確保在不同的平臺下，客戶端輸入的中文可以被正確地解析、保存、讀取。最好的辦法就是使用OutputStreamWriter配合UTF-8編碼。如果不想使用UTF-8編碼，那麼可以考慮使用GB2312，不建議使用GBK、GB18030。因爲對於某些老式的文本編輯器，甚至不支持GBK、GB18030的編碼，但是對於GB2312則是一定支持的。因爲前兩者都不是國標但後者是。
關於String的getBytes()，getBytes(encoding)和new String(bytes, encoding)這三個方法，非常值得注意：A.getBytes()：使用平臺默認的編碼方式(通過file.encoding屬性獲取)方式來將字符串轉換成byte[]。得到的是字符串最原始的字節編碼值。
B.getBytes(NAME_OF_CHARSET)：使用指定的編碼方式將字符串轉換成byte[]，如果想要得到正確的字節數組，程序員必須給出正確的NAME_OF_CHARSET。否則得到的就不會得到正確的結果。
C.new String(bytes, encoding)：如果我們在客戶端使用UTF-8編碼的JSP頁面發出請求，瀏覽器編碼後的UTF-8字節會以ISO-8859-1的形式傳遞到服務器端。所以要得到經HTTP協議傳輸的原始字節，我們需要先調用getBytes("ISO-8859-1")得到原始的字節，但由於我們客戶端的原始編碼是UTF-8，如果繼續按照ISO-8859-1解碼，那麼得到的將不是一箇中文字符，而是3個亂碼的字符。所以我們需要再次調用new String(bytes,"UTF-8")，將字節數組按照UTF-8的格式，每3個一組進行解碼，才能還原爲客戶端的原始字符。
D.String的getBytes()、getBytes(NAME_OF_CHARSET)方法都是比較微妙的方法，原則上：傳輸時採用的是什麼編碼，我們就需要按照這種編碼得到字節。new String(bytes, NAME_OF_CHARSET)則更加需要小心，原則上：客戶端採用的是什麼編碼，那麼這裏的NAME_OF_CHARSET就必須和客戶端保持一致。例如JSP頁面是GBK，那麼我們接收頁面傳遞而來的參數時就必須使用new String(parameter.getBytes("ISO-8859-1"), "GBK");如果使用了錯誤的解碼方式，如使用了UTF-8，那麼得到的很有可能就是亂碼了。也就是說：GBK--->ISO-8859-1--->GBK、UTF-8--->ISO-8859-1--->UTF-8的轉換過程是沒有問題的。但是GBK--->ISO-8859-1--->UTF-8、UTF-8--->ISO-8859-1--->GBK的字節直接轉碼則可能導致亂碼，需要另外的轉換過程。
記住：謹慎地使用getBytes(NAME_OF_CHARSET)和new String(bytes, NAME_OF_CHARSET)，除非你很清楚的知道原始的字符編碼和傳輸協議使用的編碼。推薦使用基於服務器的配置、過濾器設置request/response的characterEncoding、content type屬性。還有就是JSP頁面的pageEncoding屬性、HTML meta元素的content type屬性。儘量避免頻繁的在代碼中進行字符串轉碼，即降低了效率又增加了風險。
不應該出現這種寫法：new String(str.getBytes("gbk"), "utf-8");
這種寫法，一般都是對字符數據編碼理解得不透徹，才這麼寫的。
編碼編的是二進制數據，編碼後，二進制數據（字節流或字節數組）會轉換成Java語言的字符（串）型的數據，供編程人員使用。