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

Java字符集筆記

編輯:關於JAVA

概述

  本文主要包括以下幾個方面:編碼基本知識,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編碼處理之,結果是不正確的,所以需要進行處理。如 http://www.5a520.cn 小說520網 但如果預先設置了編碼(通過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編譯

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

  3.5.2. JSP輸出

  指定文件輸出到browser是使用的編碼,該設置也應該置於文件的開頭。例如:<%@ page contentType="text/Html; charset= GBK" %>.該設置和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選項無效。比如" http://www.bt285.cn中文。html?a=中文",當UTF-8選項有效時,將發送鏈接" http://www.bt285.cn%e4%b8%ad%e6%96%87.html?a=\x4e\x2d\x65\x87";而UTF-8選項無效時,將發送鏈接"\x4e\x2d\x65\x87.Html?a=\x4e\x2d\x65\x87".注意後者前面的"中文"兩個字只有4個字節,而前者卻有18個字節,這主要時URL編碼的原因。

  當web server(tomcat)接收到該鏈接時,將會進行URL解碼,即去掉"%",同時按照ISO8859-1編碼(上面已經描述,可以使用 URLEncoding來設置成其它編碼)識別。上述例子的結果分別是" http://www.feng123.com\ue4\ub8\uad\ue6\u96\u87.html?a=\u4e\u2d\u65\u87" 和" http://www.feng123.com\u4e\u2d\u65\u87.Html?a=\u4e\u2d\u65\u87",注意前者前面的" 中文"兩個字恢復成了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編碼是" \xd1\xa7\xcf\xb0",如果使用上述isValidUtf8方法判斷,將返回true.可以考慮使用更嚴格的判斷方法,不過估計效果不大。

  有一個例子可以證明google也遇到了上述問題,而且也采用了和上述相似的處理方法,比如,如果在地址欄中輸入"http://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表示為"\xE8\xAF\xAD\xE8\xA8\x80 \xE8\xAA\x9E\xE8\xA8\x80",進行簡繁體編碼轉換後應該是兩個相同的 "\xE8\xAF\xAD\xE8\xA8\x80>".

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