天天看點

常見的Java/J2EE中文問題解決詳細

最古老的解決方案是使用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,那麼在輸出時,也将根據作業系統的預設編碼來選擇輸出編碼,除非指定輸出編碼方式;還有輸出途徑是資料庫,将字元串輸出到資料庫

統一編碼為ISO8859_1和GBK固然帶來編制代碼的利便,但是各自隻能在響應的作業系統上運作但是也破壞了Java跨平台運作的優越性,隻在一定範疇内行得通例如,為了使得GBK編碼在linux上運作,設定Linux編碼為GBK

開發和編譯代碼時指定字元集為ISO8859_1

指定統一字元集時,到底是指定ISO8859_1GBK仍是UTF-8呢?

(1)如統一指定為ISO8859_1,因為目前大多數軟體都是西方人編制的,他們預設的字元集就是ISO8859_1,包括作業系統Linux和資料庫MySQL等這樣,如果指定Jive統一編碼為ISO8859_1,那麼就有下面3個環節必須把握:

在JSP頭部聲明:

運作作業系統的預設編碼必須是ISO8859_1,如Linux

正是由于Java的跨平台特性,使得字元集問題必須由具體系統來統一解決,是以在一個Java應用系統中,解決中文亂碼的根本措施是明确指定全部應用系一切一字元集

(2)如果統一指定為GBK中文字元集,上述3個環節同樣需要做到,不同的是隻能運作在預設編碼為GBK的作業系統,如中文Windows

由此看來,一個J2EE系統的輸入輸出是非常複雜,而且是動态變化的,而Java是跨平台運作的,在實際編譯和運作中,都可能涉及到不同的作業系統,如果任由Java自由根據作業系統來決意輸入輸出的編碼字元集,這将不可控制地出現亂碼

那麼有沒有一種除了應用系統以外不需要進行任何附加設定的中文編碼根本解決方案呢?

引文來源  常見的Java/J2EE中文問題解決詳細說明-IT頻道-和訊網

------------------exo----------

一鍵轉貼,快速捕捉生活精彩,赢每周好禮!檢視活動首頁>>

一個J2EE應用系統需要做下列幾步工作:

開發和編譯代碼時指定字元集為UTF-8JBuilder和Eclipse都可以在項目屬性中設定使用過濾器,如果所有苦求都經過一個Servlet控制配置設定器,那麼使用Servlet的filter執行語句,将所有來自浏覽器的苦求(request)轉換為UTF-8,因為浏覽器發過來的苦求包根據浏覽器所在的作業系統編碼,可能是各種形式編碼閉鍵一句:

将Java/J2EE系統的統一編碼定義為UTF-8UTF-8編碼是一種相容所有語言的編碼方式,惟一比較麻煩的就是要找到應用系統的所有出入心,然後使用UTF-8去結紮它

繼續閱讀