即我們在寫java源文件的時候一般使用的是utf-8編碼,但是tomcat控制檯(直接在bin裏面啓動的那個黑窗口)編碼是gbk.爲什麼tomcat控制沒有亂碼問題？
最開始我想的是既然我的java源文件是按照utf-8編碼,那麼最後必須按照utf-8解碼纔不會有問題啊。爲什麼tomcat用gbk解碼沒有亂碼問題？
然後查了下javac編譯過程：
當javac編譯的時候會根據-Dfile.encoding參數來進行編譯,-Dfile.encoding,一般爲系統默認字符,windows下爲gbk。當我們在ecplise下編寫文件的時候,一般我們會設置編碼爲utf-8,所以編譯的時候會以utf-8編譯。
重點來了：java編譯採用的編碼是unicode編碼,所以這裏面有一個轉碼的過程。java源文件的編碼轉碼爲unicode。這裏我做了一個實驗：
public static void main(String[] args) {
System.out.println((int)'我');
}
分別修改java源文件的編碼爲gbk,和utf-8運行上面的代碼會發現打印出來的unicode編碼都是25105。可見java都是使用unicode編碼來對源文件的編碼。相當於unicode是一座橋樑。
然後就是打印輸出到控制檯。
當我們執行下面這段代碼的時候到底是什麼意思?
String a = "您好";
byte[] bytes = a.getBytes("utf-8");
這句代碼的意思是將unicode編碼轉化爲utf-8編碼。然後交由控制檯去顯示。
現在回到最開始的問題：爲什麼tomcat控制檯沒有亂碼問題？
因爲1、在編譯源文件的時候,java會根據根據源文件的編碼來用unicode編碼。放在內存中。不管gbk還是utf-8.都會查找碼錶生成統一的unicode編碼。
2、在控制檯輸出的時候,java會根據當前-Dfile.encoding參數進行轉化,在windows上該編碼爲gbk,所以java會將unicode編碼轉化爲gbk,然後tomcat控制檯用的gbk解碼。所以沒有亂碼問題。
換言之：對java來說,我們不用考慮那麼多,只要保證調用String.getBytes("編碼")這句代碼使用的編碼和最終用來解碼的編碼一致即可。