淺析Servlet和Jsp中的多國語言顯示
因為一直不信Java竟會有不能混排顯示多國語言的BUG，這個周末研究了一下Servlet、Jsp的多國語言顯示的問題，也就是Servlet的多字符集問題，由于我對字符集的概念還不是很清晰所以寫出的東西未必是準確的，我是這樣理解Java中的字符集的：在運行時，每個字符串對象中存儲的都是編碼為UNICODE內碼的（筆者認為所有的語言中都是有相應編碼的，因為在計算機內部字符串總是用內碼來表示的，只不過一般計算機語言中的字符串編碼時平臺相關的，而Java則采用了平臺無關的UNICODE）。
Java從一個byte流中讀取一個字符串時，將把平臺相關的byte轉變為平臺無關的Unicode字符串。在輸出時Java將把Unicode字符串轉變為平臺相關的byte流，如果某個Unicode字符在某個平臺上不存在，將會輸出一個´?´。舉個例子：在中文Windows中，Java讀出一個"GB2312"編碼的文件（可以是任何流）到內存中構造字符串對象，將會把GB2312編碼的文字轉變為Unicode編碼的字符串，如果把這個字符串輸出又將會把Unicode字符串轉化為GB2312的byte流或數組："中文測試"----->"u4e2du6587u6d4bu8bd5"----->"中文測試"。
byte[] bytes = new byte[]{(byte)0xd6, (byte)0xd0, (byte)0xce, |
這段程序放到包含"中文測試"這四個字的系統（如中文系統）中，可以正確地打印出這些字。msg字符串中包含了正確的"中文測試"的Unicode編碼："u4e2du6587u6d4bu8bd5"，打印時轉換為操作系統的默認字符集，是否可以正確顯示依賴于操作系統的字符集，只有在支持相應字符集的系統中，我們的信息才能正確的輸出，否則得到的將會是垃圾。
話入正題，我們來看看Servlet/Jsp中的多語言問題。我們的目標是，任一國家的客戶端通過Form向Server發送信息，Server把信息存入數據庫中，客戶端在檢索時仍然能夠看到自己發送的正確信息。事實上，我們要保證，最終Server中的SQL語句中保存的時包含客戶端發送文字的正確Unicode編碼；DBC與數據庫通訊時采用的編碼方式能包含客戶端發送的文字信息，事實上，最好讓JDBC直接使用UNICODE/UTF8與數據庫通訊！這樣就可以確保不會丟失信息；Server向客戶端發送的信息時也要采用不丟失信息的編碼方式，也可以是Unicode/Utf8。
如果不指定Form的Enctype屬性，Form將把輸入的內容依照當前頁面的編碼字符集urlencode之后再提交，服務器端得到是urlencoding的字符串。編碼后得到的urlencoding字符串是與頁面的編碼相關的，如gb2312編碼的頁面提交"中文測試"，得到的是"%D6%D0%CE%C4%B2%E2%CA%D4"，每個"％"后跟的是16進制的字符串；而在UTF8編碼時得到的卻是"%E4%B8%AD%E6%96%87%E6%B5%8B%E8%AF%95"，因為GB2312編碼中一個漢字是16位的，而UTF8中一個漢字卻是24位的。中日韓三國的ie4以上瀏覽器均支持UTF8編碼，這種方案肯定包涵了這三國語言，所以我們如果讓Html頁面使用UTF8編碼那么將至少可以支持這三國語言。
但是，如果我們html/Jsp頁面使用UTF8編碼，因為應用程序服務器可能不知道這種情況，因為如果瀏覽器發送的信息不包含charset信息，至多Server知道讀到Accept-Language請求投標，我們知道僅靠這個投標是不能獲知瀏覽器所采用編碼的，所以應用程序服務器不能正確解析提交的內容，為什么？因為Java中的所有字符串都是Unicode16位編碼的，HttpServletRequest.request(String)的功能就是把客戶端提交的Urlencode編碼的信息轉為Unicode字符串，有些Server只能認為客戶端的編碼和Server平臺相同，簡單地使用URLDecoder.decode(String)方法直接解碼，如果客戶端編碼恰好和Server相同，那么就可以得到正確地字符串，否則，如果提交地字符串中包含了當地字符，那么將會導致垃圾信息。
【編輯推薦】
