程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> Java中字符集編碼的問題

Java中字符集編碼的問題

編輯:關於JAVA

1. 概述

本文主要包括以下幾個方面:編碼基本知識,Java,系統軟件,url,工具軟件等。

在下面的描述中,將以"中文"兩個字為例,經查表可以知道其GB2312編碼是"d6d0 cec4",Unicode編碼為"4e2d 6587",UTF編碼就是"e4b8ad e69687"。注意,這兩個字沒有iso8859-1編碼,但可以用iso8859-1編碼來"表示"。

2. 編碼基本知識

最早的編碼是iso8859-1,和ascii編碼相似。但為了方便表示各種各樣的語言,逐漸出現了很多標准編碼,重要的有如下幾個。

2.1. iso8859-1

屬於單字節編碼,最多能表示的字符范圍是0-255,應用於英文系列。比如,字母a的編碼為0x61=97。

很明顯,iso8859-1編碼表示的字符范圍很窄,無法表示中文字符。但是,由於是單字節編碼,和計算機最基礎的表示單位一致,所以很多時候,仍舊使用iso8859-1編碼來表示。而且在很多協議上,默認使用該編碼。比如,雖然"中文"兩個字不存在iso8859-1編碼,以gb2312編碼為例,應該是"d6d0 cec4"兩個字符,使用iso8859-1編碼的時候則將它拆開為4個字節來表示:"d6 d0 ce c4"(事實上,在進行存儲的時候,也是以字節為單位處理的)。而如果是UTF編碼,則是6個字節"e4 b8 ad e6 96 87"。很明顯,這種表示方法還需要以另一種編碼為基礎。

2.2. GB2312/GBK

這就是漢子的國標碼,專門用來表示漢字,是雙字節編碼,而英文字母和iso8859-1一致(兼容iso8859-1編碼)。其中gbk編碼能夠用來同時表示繁體字和簡體字,而gb2312只能表示簡體字,gbk是兼容gb2312編碼的。

2.3. unicode

這是最統一的編碼,可以用來表示所有語言的字符,而且是定長雙字節(也有四字節的)編碼,包括英文字母在內。所以可以說它是不兼容iso8859- 1編碼的,也不兼容任何編碼。不過,相對於iso8859-1編碼來說,uniocode編碼只是在前面增加了一個0字節,比如字母a為"00 61"。

需要說明的是,定長編碼便於計算機處理(注意GB2312/GBK不是定長編碼),而unicode又可以用來表示所有字符,所以在很多軟件內部是使用unicode編碼來處理的,比如Java。

2.4. UTF

考慮到unicode編碼不兼容iso8859-1編碼,而且容易占用更多的空間:因為對於英文字母,unicode也需要兩個字節來表示。所以 unicode不便於傳輸和存儲。因此而產生了utf編碼,utf編碼兼容iso8859-1編碼,同時也可以用來表示所有語言的字符,不過,utf編碼是不定長編碼,每一個字符的長度從1-6個字節不等。另外,utf編碼自帶簡單的校驗功能。一般來講,英文字母都是用一個字節表示,而漢字使用三個字節。

注意,雖然說utf是為了使用更少的空間而使用的,但那只是相對於unicode編碼來說,如果已經知道是漢字,則使用GB2312/GBK無疑是最節省的。不過另一方面,值得說明的是,雖然utf編碼對漢字使用3個字節,但即使對於漢字頁,utf編碼也會比unicode編碼節省,因為頁中包含了很多的英文字符。

3. Java對字符的處理

在Java應用軟件中,會有多處涉及到字符集編碼,有些地方需要進行正確的設置,有些地方需要進行一定程度的處理。

3.1. getBytes(charset)

這是java字符串處理的一個標准函數,其作用是將字符串所表示的字符按照charset編碼,並以字節方式表示。注意字符串在Java內存中總是按unicode編碼存儲的。比如"中文",正常情況下(即沒有錯誤的時候)存儲為"4e2d 6587",如果charset為"gbk",則被編碼為"d6d0 cec4",然後返回字節"d6 d0 ce c4"。如果charset為"utf8"則最後是"e4 b8 ad e6 96 87"。如果是"iso8859-1",則由於無法編碼,最後返回 "3f 3f"(兩個問號)。

3.2. new String(charset)

這是Java字符串處理的另一個標准函數,和上一個函數的作用相反,將字節數組按照charset編碼進行組合識別,最後轉換為unicode存儲。參考上述getBytes的例子,"gbk" 和"utf8"都可以得出正確的結果"4e2d 6587",但iso8859-1最後變成了"003f 003f"(兩個問號)。

因為utf8可以用來表示/編碼所有字符,所以new String( str.getBytes( "utf8" ), "utf8" ) === str,即完全可逆。

3.3. setCharacterEncoding()

該函數用來設置http請求或者相應的編碼。

對於request,是指提交內容的編碼,指定後可以通過getParameter()則直接獲得正確的字符串,如果不指定,則默認使用 iso8859-1編碼,需要進一步處理。參見下述"表單輸入"。值得注意的是在執行setCharacterEncoding()之前,不能執行任何 getParameter()。java doc上說明:This method must be called prior to reading request parameters or reading input using getReader()。而且,該指定只對POST方法有效,對GET方法無效。分析原因,應該是在執行第一個getParameter()的時候, Java將會按照編碼分析所有的提交內容,而後續的getParameter()不再進行分析,所以setCharacterEncoding()無效。而對於GET方法提交表單是,提交的內容在URL中,一開始就已經按照編碼分析所有的提交內容,setCharacterEncoding()自然就無效。

對於response,則是指定輸出內容的編碼,同時,該設置會傳遞給浏覽器,告訴浏覽器輸出內容所采用的編碼。

3.4. 處理過程

下面分析兩個有代表性的例子,說明Java對編碼有關問題的處理方法。

3.4.1. 表單輸入

User input *(gbk:d6d0 cec4) browser *(gbk:d6d0 cec4) web server iso8859-1(00d6 00d 000ce 00c4) class,需要在class中進行處理:getbytes("iso8859-1")為d6 d0 ce c4,new String("gbk")為d6d0 cec4,內存中以unicode編碼則為4e2d 6587。

l 用戶輸入的編碼方式和頁面指定的編碼有關,也和用戶的操作系統有關,所以是不確定的,上例以gbk為例。

l 從browser到web server,可以在表單中指定提交內容時使用的字符集,否則會使用頁面指定的編碼。而如果在url中直接用?的方式輸入參數,則其編碼往往是操作系統本身的編碼,因為這時和頁面無關。上述仍舊以gbk編碼為例。

l Web server接收到的是字節流,默認時(getParameter)會以iso8859-1編碼處理之,結果是不正確的,所以需要進行處理。但如果預先設置了編碼(通過request. setCharacterEncoding ()),則能夠直接獲取到正確的結果。

l 在頁面中指定編碼是個好習慣,否則可能失去控制,無法指定正確的編碼。

3.4.2. 文件編譯

假設文件是gbk編碼保存的,而編譯有兩種編碼選擇:gbk或者iso8859-1,前者是中文Windows的默認編碼,後者是Linux的默認編碼,當然也可以在編譯時指定編碼。

JSP *(gbk:d6d0 cec4) Java file *(gbk:d6d0 cec4) compiler read uincode(gbk: 4e2d 6587; iso8859-1: 00d6 00d 000ce 00c4) compiler write utf(gbk: e4b8ad e69687; iso8859-1: *) compiled file unicode(gbk: 4e2d 6587; iso8859-1: 00d6 00d 000ce 00c4) class。所以用gbk編碼保存,而用iso8859-1編譯的結果是不正確的。

class unicode(4e2d 6587) system.out / JSP.out gbk(d6d0 cec4) os console / browser。

l 文件可以以多種編碼方式保存,中文Windows下,默認為ansi/gbk。

l 編譯器讀取文件時,需要得到文件的編碼,如果未指定,則使用系統默認編碼。一般class文件,是以系統默認編碼保存的,所以編譯不會出問題,但對於 JSp文件,如果在中文Windows下編輯保存,而部署在英文Linux下運行/編譯,則會出現問題。所以需要在JSP文件中用 pageEncoding指定編碼。

l Java編譯的時候會轉換成統一的unicode編碼處理,最後保存的時候再轉換為utf編碼。

l 當系統輸出字符的時候,會按指定編碼輸出,對於中文Windows下,System.out將使用gbk編碼,而對於response(浏覽器),則使用 JSP文件頭指定的contentType,或者可以直接為response指定編碼。同時,會告訴browser頁的編碼。如果未指定,則會使用 iso8859-1編碼。對於中文,應該為browser指定輸出字符串的編碼。

l browser顯示頁的時候,首先使用response中指定的編碼(JSP文件頭指定的contentType最終也反映在response上),如果未指定,則會使用頁中meta項指定中的contentType。

3.5. 幾處設置

對於web應用程序,和編碼有關的設置或者函數如下。

3.5.1. JSP編譯

指定文件的存儲編碼,很明顯,該設置應該置於文件的開頭。例如:。另外,對於一般class文件,可以在編譯的時候指定編碼。

3.5.2. JSP輸出

指定文件輸出到browser是使用的編碼,該設置也應該置於文件的開頭。例如:。該設置和response.setCharacterEncoding("GBK")等效。

3.5.3. meta設置

指定頁使用的編碼,該設置對靜態頁尤其有作用。因為靜態頁無法采用JSP的設置,而且也無法執行response.setCharacterEncoding()。例如:

如果同時采用了jsp輸出和meta設置兩種編碼指定方式,則JSp指定的優先。因為JSP指定的直接體現在response中。

需要注意的是,apache有一個設置可以給無編碼指定的頁指定編碼,該指定等同於JSP的編碼指定方式,所以會覆蓋靜態頁中的meta指定。所以有人建議關閉該設置。

3.5.4. form設置

當浏覽器提交表單的時候,可以指定相應的編碼。例如: 
。一般不必不使用該設置,浏覽器會直接使用頁的編碼。

4. 系統軟件

下面討論幾個相關的系統軟件。

4.1. MySQL數據庫

很明顯,要支持多語言,應該將數據庫的編碼設置成utf或者unicode,而utf更適合與存儲。但是,如果中文數據中包含的英文字母很少,其實unicode更為適合。

數據庫的編碼可以通過MySQL的配置文件設置,例如default-character-set=utf8。還可以在數據庫鏈接URL中設置,例如: useUnicode=true&characterEncoding=UTF-8。注意這兩者應該保持一致,在新的sql版本裡,在數據庫鏈接 URL裡可以不進行設置,但也不能是錯誤的設置。

4.2. apache

appache和編碼有關的配置在httpd.conf中,例如AddDefaultCharset UTF-8。如前所述,該功能會將所有靜態頁面的編碼設置為UTF-8,最好關閉該功能。

另外,apache還有單獨的模塊來處理頁響應頭,其中也可能對編碼進行設置。

4.3. Linux默認編碼

這裡所說的Linux默認編碼,是指運行時的環境變量。兩個重要的環境變量是LC_ALL和LANG,默認編碼會影響到Java URLEncode的行為,下面有描述。

建議都設置為"zh_CN.UTF-8"。

4.4. 其它

為了支持中文文件名,Linux在加載磁盤時應該指定字符集,例如:mount /dev/hda5 /mnt/hda5/ -t ntfs -o iocharset=gb2312。

另外,如前所述,使用GET方法提交的信息不支持request.setCharacterEncoding(),但可以通過tomcat的配置文件指定字符集,在tomcat的server.XML文件中,形如:。這種方法將統一設置所有請求,而不能針對具體頁面進行設置,也不一定和 browser使用的編碼相同,所以有時候並不是所期望的。

5. URL地址

URL地址中含有中文字符是很麻煩的,前面描述過使用GET方法提交表單的情況,使用GET方法時,參數就是包含在URL中。

5.1. URL編碼

對於URL中的一些特殊字符,浏覽器會自動進行編碼。這些字符除了"/?&"等外,還包括unicode字符,比如漢子。這時的編碼比較特殊。

IE有一個選項"總是使用UTF-8發送URL",當該選項有效時,IE將會對特殊字符進行UTF-8編碼,同時進行URL編碼。如果改選項無效,則使用默認編碼"GBK",並且不進行URL編碼。但是,對於URL後面的參數,則總是不進行編碼,相當於UTF-8選項無效。比如"中文.html?a =中文",當UTF-8選項有效時,將發送鏈接"%e4%b8%ad%e6%96%87.html?a=x4ex2dx65x87";而UTF-8選項無效時,將發送鏈接"x4ex2dx65x87.Html?a=x4ex2dx65x87"。注意後者前面的"中文"兩個字只有4個字節,而前者卻有18個字節,這主要時URL編碼的原因。

當web server(tomcat)接收到該鏈接時,將會進行URL解碼,即去掉"%",同時按照ISO8859-1編碼(上面已經描述,可以使用 URLEncoding來設置成其它編碼)識別。上述例子的結果分別是"ue4ub8uadue6u96u87.html?a= u4eu2du65u87"和"u4eu2du65u87.Html?a=u4eu2du65u87",注意前者前面的"中文"兩個字恢復成了6個字符。這裡用"u",表示是unicode。

所以,由於客戶端設置的不同,相同的鏈接,在服務器上得到了不同結果。這個問題不少人都遇到,卻沒有很好的解決辦法。所以有的站會建議用戶嘗試關閉UTF-8選項。不過,下面會描述一個更好的處理辦法。

5.2. rewrite

熟悉的人都知道,apache有一個功能強大的rewrite模塊,這裡不描述其功能。需要說明的是該模塊會自動將URL解碼(去除%),即完成上述web server(tomcat)的部分功能。有相關文檔介紹說可以使用[NE]參數來關閉該功能,但我試驗並未成功,可能是因為版本(我使用的是 apache 2.0.54)問題。另外,當參數中含有"?& "等符號的時候,該功能將導致系統得不到正常結果。

rewrite本身似乎完全是采用字節處理的方式,而不考慮字符串的編碼,所以不會帶來編碼問題。

5.3. URLEncode.encode()

這是Java本身提供對的URL編碼函數,完成的工作和上述UTF-8選項有效時浏覽器所做的工作相似。值得說明的是,Java已經不贊成不指定編碼來使用該方法(deprecated)。應該在使用的時候增加編碼指定。

當不指定編碼的時候,該方法使用系統默認編碼,這會導致軟件運行結果得不確定。比如對於"中文",當系統默認編碼為"gb2312"時,結果是"% 4e%2d%65%87",而默認編碼為"UTF-8",結果卻是"%e4%b8%ad%e6%96%87",後續程序將難以處理。另外,這兒說的系統默認編碼是由運行tomcat時的環境變量LC_ALL和LANG等決定的,曾經出現過tomcat重啟後就出現亂碼的問題,最後才郁悶的發現是因為修改修改了這兩個環境變量。

建議統一指定為"UTF-8"編碼,可能需要修改相應的程序。

5.4. 一個解決方案

上面說起過,因為浏覽器設置的不同,對於同一個鏈接,web server收到的是不同內容,而軟件系統有無法知道這中間的區別,所以這一協議目前還存在缺陷。

針對具體問題,不應該僥幸認為所有客戶的IE設置都是UTF-8有效的,也不應該粗暴的建議用戶修改IE設置,要知道,用戶不可能去記住每一個web server的設置。所以,接下來的解決辦法就只能是讓自己的程序多一點智能:根據內容來分析編碼是否UTF-8。

比較幸運的是UTF-8編碼相當有規律,所以可以通過分析傳輸過來的鏈接內容,來判斷是否是正確的UTF-8字符,如果是,則以UTF-8處理之,如果不是,則使用客戶默認編碼(比如"GBK"),下面是一個判斷是否UTF-8的例子,如果你了解相應規律,就容易理解。

以下為引用的內容:

public static boolean isValidUtf8(byte[] b,int aMaxCount){

int lLen=b.length,lCharCount=0;

for(int i=0;i 
byte lByte=b[i++];//to fast Operation, ++ now, ready for the following for(;;)

if(lByte>=0) continue;//>=0 is normal ascii

if(lByte<(byte)0xc0 || lByte>(byte)0xfd) return false;

int lCount=lByte>(byte)0xfc?5:lByte>(byte)0xf8?4

:lByte>(byte)0xf0?3:lByte>(byte)0xe0?2:1;

if(i+lCount>lLen) return false;

for(int j=0;j=(byte)0xc0) return false;

}

return true;

}

相應地,一個使用上述方法的例子如下:

以下為引用的內容:

public static String getUrlParam(String aStr,String aDefaultCharset)

throws UnsupportedEncodingException{

if(aStr==null) return null;

byte[] lBytes=aStr.getBytes("ISO-8859-1");

return new String(lBytes,StringUtil.isValidUtf8(lBytes)?"utf8":aDefaultCharset);

}

不過,該方法也存在缺陷,如下兩方面:

l 沒有包括對用戶默認編碼的識別,這可以根據請求信息的語言來判斷,但不一定正確,因為我們有時候也會輸入一些韓文,或者其他文字。

l 可能會錯誤判斷UTF-8字符,一個例子是"學習"兩個字,其GBK編碼是" xd1xa7xcfxb0",如果使用上述isValidUtf8方法判斷,將返回true。可以考慮使用更嚴格的判斷方法,不過估計效果不大。

有一個例子可以證明google也遇到了上述問題,而且也采用了和上述相似的處理方法,比如,如果在地址欄中輸入"www.google.com/search?hl=zh-CN&newwindow=1&q=學習",google將無法正確識別,而其他漢字一般能夠正常識別。

最後,應該補充說明一下,如果不使用rewrite規則,或者通過表單提交數據,其實並不一定會遇到上述問題,因為這時可以在提交數據時指定希望的編碼。另外,中文文件名確實會帶來問題,應該謹慎使用。

6. 其它

下面描述一些和編碼有關的其他問題。

6.1. SecureCRT

除了浏覽器和控制台與編碼有關外,一些客戶端也很有關系。比如在使用SecureCRT連接linux時,應該讓SecureCRT的顯示編碼(不同的session,可以有不同的編碼設置)和Linux的編碼環境變量保持一致。否則看到的一些幫助信息,就可能是亂碼。

另外,MySQL有自己的編碼設置,也應該保持和SecureCRT的顯示編碼一致。否則通過SecureCRT執行sql語句的時候,可能無法處理中文字符,查詢結果也會出現亂碼。

對於Utf-8文件,很多編輯器(比如記事本)會在文件開頭增加三個不可見的標志字節,如果作為MySQL的輸入文件,則必須要去掉這三個字符。(用Linux的vi保存可以去掉這三個字符)。一個有趣的現象是,在中文Windows下,創建一個新txt文件,用記事本打開,輸入"連通"兩個字,保存,再打開,你會發現兩個字沒了,只留下一個小黑點。

6.2. 過濾器

如果需要統一設置編碼,則通過filter進行設置是個不錯的選擇。在filter class中,可以統一為需要的請求或者回應設置編碼。參加上述setCharacterEncoding()。這個類apache已經給出了可以直接使用的例子SetCharacterEncodingFilter。

6.3. POST和GET

很明顯,以POST提交信息時,URL有更好的可讀性,而且可以方便的使用setCharacterEncoding()來處理字符集問題。但GET方法形成的URL能夠更容易表達頁的實際內容,也能夠用於收藏。

從統一的角度考慮問題,建議采用GET方法,這要求在程序中獲得參數是進行特殊處理,而無法使用setCharacterEncoding()的便利,如果不考慮rewrite,就不存在IE的UTF-8問題,可以考慮通過設置URIEncoding來方便獲取URL中的參數。

6.4. 簡繁體編碼轉換

GBK同時包含簡體和繁體編碼,也就是說同一個字,由於編碼不同,在GBK編碼下屬於兩個字。有時候,為了正確取得完整的結果,應該將繁體和簡體進行統一。可以考慮將UTF、GBK中的所有繁體字,轉換為相應的簡體字,BIG5編碼的數據,也應該轉化成相應的簡體字。當然,仍舊以UTF編碼存儲。

例如,對於"語言 語言",用UTF表示為"xE8xAFxADxE8xA8x80 xE8xAAx9ExE8xA8x80",進行簡繁體編碼轉換後應該是兩個相同的 "xE8xAFxADxE8xA8x80>"。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved