Java/J2EE中文問題終極解決之道 | |
板橋里人 http://www.jdon.com 2005/06/29 Java中文問題一直困擾著很多初學者,如果了解了Java系統的中文問題原理,我們就可以對中文問題能夠采取根本的解決之道。 最古老的解決方案是使用String的字節碼轉換,這種方案問題是不方便,我們需要破壞對象封裝性,進行字節碼轉換。 還有一種方式是對J2EE容器進行編碼設置,如果J2EE應用系統脫離該容器,則會發生亂碼,而且指定容器配置不符合J2EE應用和容器分離的原則。 在Java內部運算中,涉及到的所有字符串都會被轉化為UTF-8編碼來進行運算。那么,在被Java轉化之前,字符串是什么樣的字符集? Java總是根據操作系統的默認編碼字符集來決定字符串的初始編碼,而且Java系統的輸入和輸出的都是采取操作系統的默認編碼。 因此,如果能統一Java系統的輸入、輸出和操作系統3者的編碼字符集合,將能夠使Java系統正確處理和顯示漢字。這是處理Java系統漢字的一個原則,但是在實際項目中,能夠正確抓住和控制住Java系統的輸入和輸出部分是比較難的。J2EE中,由于涉及到外部瀏覽器和數據庫等,所以中文問題亂碼顯得非常突出。 J2EE應用程序是運行在J2EE容器中。在這個系統中,輸入途徑有很多種:一種是通過頁面表單打包成請求(request)發往服務器的;第二種是通過數據庫讀入;還有第3種輸入比較復雜,JSP在第一次運行時總是被編譯成Servlet,JSP中常常包含中文字符,那么編譯使用javac時,Java將根據默認的操作系統編碼作為初始編碼。除非特別指定,如在Jbuilder/eclipse中可以指定默認的字符集。 輸出途徑也有幾種:第一種是JSP頁面的輸出。由于JSP頁面已經被編譯成Servlet,那么在輸出時,也將根據操作系統的默認編碼來選擇輸出編碼,除非指定輸出編碼方式;還有輸出途徑是數據庫,將字符串輸出到數據庫。 由此看來,一個J2EE系統的輸入輸出是非常復雜,而且是動態變化的,而Java是跨平臺運行的,在實際編譯和運行中,都可能涉及到不同的操作系統,如果任由Java自由根據操作系統來決定輸入輸出的編碼字符集,這將不可控制地出現亂碼。 正是由于Java的跨平臺特性,使得字符集問題必須由具體系統來統一解決,所以在一個Java應用系統中,解決中文亂碼的根本辦法是明確指定整個應用系統統一字符集。 指定統一字符集時,到底是指定ISO8859_1 、GBK還是UTF-8呢? (1)如統一指定為ISO8859_1,因為目前大多數軟件都是西方人編制的,他們默認的字符集就是ISO8859_1,包括操作系統Linux和數據庫MySQL等。這樣,如果指定Jive統一編碼為ISO8859_1,那么就有下面3個環節必須把握: 開發和編譯代碼時指定字符集為ISO8859_1。 運行操作系統的默認編碼必須是ISO8859_1,如Linux。 在JSP頭部聲明:<%@ page contentType="text/html;charset=ISO8859_1" %>。 (2)如果統一指定為GBK中文字符集,上述3個環節同樣需要做到,不同的是只能運行在默認編碼為GBK的操作系統,如中文Windows。 統一編碼為ISO8859_1和GBK雖然帶來編制代碼的方便,但是各自只能在相應的操作系統上運行。但是也破壞了Java跨平臺運行的優越性,只在一定范圍內行得通。例如,為了使得GBK編碼在linux上運行,設置Linux編碼為GBK。 那么有沒有一種除了應用系統以外不需要進行任何附加設置的中文編碼根本解決方案呢? 將Java/J2EE系統的統一編碼定義為UTF-8。UTF-8編碼是一種兼容所有語言的編碼方式,惟一比較麻煩的就是要找到應用系統的所有出入口,然后使用UTF-8去“結扎”它。 一個J2EE應用系統需要做下列幾步工作:
|