簡介
種類
漢字亂碼現象有4種類型:
文本亂碼:是Windows系統顯示亂碼,如:選單、桌面、提示框等。這是由於註冊表中有關字型部分的設定不當引起的;
文檔亂碼:是執行檔本來顯示中文的地方出現亂碼。這種亂碼形成的原因比較複雜,有第1類的亂碼原因,也可能是軟體中用到的中文動態程式庫被英文動態程式庫覆蓋所造成的;
檔案亂碼:主要是指郵件亂碼;
網頁亂碼:是由於港澳的繁體中文大五碼(BIG5)與大陸簡體中文(GB2312)不通用而造成的。
修正亂碼,可以使用系統內碼轉換工具,如“南極星”等,將系統內碼轉換為對應內碼,字元即可正確顯示。
原因
一般是軟體程式解碼錯誤。如瀏覽器把GBK碼當成是Big5碼顯示,或電子郵件程式把對方傳來的郵件錯誤解碼。如果在傳送時編碼錯誤,收件者的電郵程式是不能解碼的,需要寄件者的電郵程式重新編碼再寄。字型檔案(font file)不對。來源編碼錯誤,或檔案受到破壞。
一種語言版本的作業系統安裝了另外一種語言版本的應用程式,或者應用程式安裝的升級補丁的語言版本與應用程式原來安裝的語言版本不一致。
早期單位元組的應用程式在打開雙位元組語言的檔案時不能正確識別文字的分割,在換行的地方把一個字從中分成兩段,導致緊接在後面的整個一行全部都是亂碼。
低版本的應用程式不能識別高版本的程式創建的檔案。
由於TXD等修改檔案出現內部衝突,一些修改遊戲的MOD(modification)CLEO、IV補丁、真實補丁、技能補丁、升級補丁和CCI人物補丁等遊戲修改軟體的“Readme”“必看!”等閱讀檔案會出現亂碼。
電腦軟體的錯誤操作也會導致整個檔案出現亂碼
資料庫原因
數據正確,但資料庫配置錯誤,使用了錯誤的字元集。一般是資料庫移植,還原時DBA的錯誤造成的。
一般是客戶端使用了默認的字元集,比如在GBK的機器上開發,但換到Linux下面就出現讀取的數據為亂碼了。
解決方法是:在連線參數裡面明確指定數據傳輸用的字元集,而不是使用作業系統默認的。
數據錯誤。一般是客戶端發來的數據編碼問題。比如頁面傳送數據是UTF-8,可是後台處理程式是GBK的,結果造成保存到資料庫的數據為亂碼。
解決方法:所有字元集編碼都採用統一的編碼。比如全部用GBK的。
相關資料
避免亂碼
1.儘量使用統一的編碼,如果你是重頭開發一個系統,特別是Java開發的,推薦從頁面到資料庫再到配置檔案都使用UTF-8進行編碼,安全第一。
2.SetCharacterEncodingFilter的使用,這個東西不是萬能的,但是沒有它就會很麻煩,如果是基於Servlet開發的東西,能用的就給它用上,省心。不過有一個注意的地方,這個Filter只是對POST請求有效,GET一律忽略,不信你可以debug一下,看看它怎么做的,至於為什麼不過濾get請求,好象是它對GET請求是無能為力的。
3.就如上面所說,GET請求有問題,儘量使用POST請求,這個也是Web開發的一個基本要領:
4.JavaScript和Ajax亂碼的避免,注意JavaScript默認是ISO8859的編碼,避免JS/AJAX亂碼和GET一樣,不要在URL裡面使用中文,實在避免不了,就只能在生成連結的時候轉碼。
5.儘早統一開發環境,早點模擬真實環境測試,這個好像也有離題的嫌疑,但凡軟體開發都是這么乾的,但仍然值得注意。
應對措施
1.開發環境亂碼
由於Java默認使用UTF-8編碼,而且網上很多人都建議Struts開發的時候應儘量選用UTF-8做為默認編碼,而非GBK。IDE使 用Eclipse,在第一次使用Eclipse的時候應將default text editor改為UTF-8編碼。
2.POST請求的過濾
這個是最基本的了,每個Servlet系統基本都會用到這個東西。不過只對POST請求有效,這個挺關鍵的。使用SetCharacterEncodingFilter,這個很基礎的一套過濾器,將所有來自頁面的POST請求全部過濾為UTF-8編碼。
3. JSP 頁面亂碼
將JSP頁面全部改為charset=UTF-8,這樣可以保證與後台互動的時候都是UTF-8編碼,一般套用做了以上工作就基本可以應付了。
4.資源檔案中漢字轉化UTF-8字元問題
國際化問題,在使用資源檔案的時候,由於中文在properties檔案中無法被程式所識別,需要將其進行轉碼,我在資源檔案下面製作了一個很簡單的 bat檔案,每次修改資源檔案的時候都是在一個臨時檔案中修改,然後執行這個bat檔案,將其轉化並保存為所需要的資源檔案。
5. GET請求亂碼
如果在本項目中採用了get方式提交請求並附加參數,結果導致編碼亂碼,原因是Tomcat默認請求編碼是ISO8859,需要在Tomcat的配置檔案 server.xml添加一個參數,URIEncoding=”UTF-8”,這樣請求中附屬檔案的參數就會以UTF-8來進行編碼。