JSP/Servlet 中的漢字編碼問題(轉(zhuǎn)）
作者：UB 時間：2002-06-14 10:51:10
JSP/Servlet中的漢字編碼問題(1)
[作者:不詳添加時間:2001-9-68:12:47>
網(wǎng)上就JSP/Servlet中DBCS字符編碼問題有許多優(yōu)秀的文章和討論，本文對它們作一些整理，并結(jié)合IBMWebSphereApplicationServer3.5（WAS）的解決方法作一些說明，希望它不是多余的。
內(nèi)容：
問題的起源
GB2312-80，GBK，GB18030-2000漢字字符集及Encoding
中文轉(zhuǎn)碼時'?'、亂碼的由來
JSP/Servlet漢字編碼問題及在WAS中的解決辦法
結(jié)束語
1.問題的起源
每個國家（或區(qū)域）都規(guī)定了計算機信息交換用的字符編碼集，如美國的擴展ASCII碼,中國的GB2312-80，日本的JIS等，作為該國家/區(qū)域內(nèi)信息處理的基礎(chǔ)，有著統(tǒng)一編碼的重要作用。字符編碼集按長度分為SBCS（單字節(jié)字符集），DBCS（雙字節(jié)字符集）兩大類。早期的軟件（尤其是操作系統(tǒng)），為了解決本地字符信息的計算機處理，出現(xiàn)了各種本地化版本（L10N），為了區(qū)分，引進了LANG,Codepage等概念。但是由于各個本地字符集代碼范圍重疊，相互間信息交換困難；軟件各個本地化版本獨立維護成本較高。因此有必要將本地化工作中的共性抽取出來，作一致處理，將特別的本地化處理內(nèi)容降低到最少。這也就是所謂的國際化（I18N）。各種語言信息被進一步規(guī)范為Locale信息。處理的底層字符集變成了幾乎包含了所有字形的Unicode。
現(xiàn)在大部分具有國際化特征的軟件核心字符處理都是以Unicode為基礎(chǔ)的，在軟件運行時根據(jù)當時的Locale/Lang/Codepage設(shè)置確定相應(yīng)的本地字符編碼設(shè)置，并依此處理本地字符。在處理過程中需要實現(xiàn)Unicode和本地字符集的相互轉(zhuǎn)換，甚或以Unicode為中間的兩個不同本地字符集的相互轉(zhuǎn)換。這種方式在網(wǎng)絡(luò)環(huán)境下被進一步延伸，任何網(wǎng)絡(luò)兩端的字符信息也需要根據(jù)字符集的設(shè)置轉(zhuǎn)換成可接受的內(nèi)容。
Java語言內(nèi)部是用Unicode表示字符的，遵守UnicodeV2.0。Java程序無論是從/往文件系統(tǒng)以字符流讀/寫文件，還是往URL連接寫HTML信息，或從URL連接讀取參數(shù)值，都會有字符編碼的轉(zhuǎn)換。這樣做雖然增加了編程的復(fù)雜度，容易引起混淆，但卻是符合國際化的思想的。
從理論上來說，這些根據(jù)字符集設(shè)置而進行的字符轉(zhuǎn)換不應(yīng)該產(chǎn)生太多問題。而事實是由于應(yīng)用程序的實際運行環(huán)境不同，Unicode和各個本地字符集的補充、完善，以及系統(tǒng)或應(yīng)用程序?qū)崿F(xiàn)的不規(guī)范，轉(zhuǎn)碼時出現(xiàn)的問題時時困擾著程序員和用戶。
2.GB2312-80，GBK，GB18030-2000漢字字符集及Encoding
其實解決JAVA程序中的漢字編碼問題的方法往往很簡單，但理解其背后的原因，定位問題，還需要了解現(xiàn)有的漢字編碼和編碼轉(zhuǎn)換。
GB2312-80是在國內(nèi)計算機漢字信息技術(shù)發(fā)展初始階段制定的，其中包含了大部分常用的一、二級漢字，和9區(qū)的符號。該字符集是幾乎所有的中文系統(tǒng)和國際化的軟件都支持的中文字符集，這也是最基本的中文字符集。其編碼范圍是高位0xa1－0xfe，低位也是0xa1-0xfe；漢字從0xb0a1開始，結(jié)束于0xf7fe；
GBK是GB2312-80的擴展，是向上兼容的。它包含了20902個漢字，其編碼范圍是0x8140-0xfefe，剔除高位0x80的字位。其所有字符都可以一對一映射到Unicode2.0，也就是說JAVA實際上提供了GBK字符集的支持。這是現(xiàn)階段Windows和其它一些中文操作系統(tǒng)的缺省字符集，但并不是所有的國際化軟件都支持該字符集，感覺是他們并不完全知道GBK是怎么回事。值得注意的是它不是國家標準，而只是規(guī)范。隨著GB18030-2000國標的發(fā)布，它將在不久的將來完成它的歷史使命。
GB18030-2000(GBK2K)在GBK的基礎(chǔ)上進一步擴展了漢字，增加了藏、蒙等少數(shù)民族的字形。GBK2K從根本上解決了字位不夠，字形不足的問題。它有幾個特點，
它并沒有確定所有的字形，只是規(guī)定了編碼范圍，留待以后擴充。
編碼是變長的，其二字節(jié)部分與GBK兼容；四字節(jié)部分是擴充的字形、字位，其編碼范圍是首字節(jié)0x81-0xfe、二字節(jié)0x30-0x39、三字節(jié)0x81-0xfe、四字節(jié)0x30-0x39。
它的推廣是分階段的，首先要求實現(xiàn)的是能夠完全映射到Unicode3.0標準的所有字形。
它是國家標準，是強制性的。
現(xiàn)在還沒有任何一個操作系統(tǒng)或軟件實現(xiàn)了GBK2K的支持，這是現(xiàn)階段和將來漢化的工作內(nèi)容。
Unicode的介紹......就免了吧。
JAVA支持的encoding中與中文編程相關(guān)的有：(有幾個在JDK文檔中未列出)ASCII7-bit,同ascii7
ISO8859-18-bit,同8859_1,ISO-8859-1,ISO_8859-1,latin1...
GB2312-80同gb2312,gb2312-1980,EUC_CN,euccn,1381,Cp1381,1383,Cp1383,ISO2022CN,ISO2022CN_GB......
GBK(注意大小寫),同MS936
UTF8UTF-8
GB18030(現(xiàn)在只有IBMJDK1.3.?有支持),同Cp1392,1392
JAVA語言采用Unicode處理字符.但從另一個角度來說，在java程序中也可以采用非Unicode的轉(zhuǎn)碼，重要的是保證程序入口和出口的漢字信息不失真。如完全采用ISO-8859-1來處理漢字也能達到正確的結(jié)果。網(wǎng)絡(luò)上流行的許多解決方法，都屬于這種類型。為了不致引起混淆，本文不對這種方法作討論。
3.中文轉(zhuǎn)碼時'?'、亂碼的由來
兩個方向轉(zhuǎn)換都有可能得到錯誤的結(jié)果：
Unicode-->Byte,如果目標代碼集不存在對應(yīng)的代碼，則得到的結(jié)果是0x3f.
如：
"\u00d6\u00ec\u00e9\u0046\u00bb\u00f9".getBytes("GBK")的結(jié)果是"?ìéF?ù",Hex值是3fa8aca8a6463fa8b4.
仔細看一下上面的結(jié)果，你會發(fā)現(xiàn)\u00ec被轉(zhuǎn)換為0xa8ac,\u00e9被轉(zhuǎn)換為\xa8a6...它的實際有效位變長了！這是因為GB2312符號區(qū)中的一些符號被映射到一些公共的符號編碼，由于這些符號出現(xiàn)在ISO-8859-1或其它一些SBCS字符集中，故它們在Unicode中編碼比較靠前，有一些其有效位只有8位，和漢字的編碼重疊(其實這種映射只是編碼的映射，在顯示時仔細不是一樣的。Unicode中的符號是單字節(jié)寬，漢字中的符號是雙字節(jié)寬).在Unicode\u00a0--\u00ff之間這樣的符號有20個。了解這個特征非常重要！由此就不難理解為什么JAVA編程中，漢字編碼的錯誤結(jié)果中常常會出現(xiàn)一些亂碼(其實是符號字符),而不全是'?'字符,就比如上面的例子。
Byte-->Unicode,如果Byte標識的字符在源代碼集不存在，則得到的結(jié)果是0xfffd.
如：
Byteba[>={(byte)0x81,(byte)0x40,(byte)0xb0,(byte)0xa1};newString(ba,"gb2312");
結(jié)果是"?啊",hex值是"\ufffd\u554a".0x8140是GBK字符，按GB2312轉(zhuǎn)換表沒有對應(yīng)的值，取\ufffd.(請注意：在顯示該uniCode時，因為沒有對應(yīng)的本地字符，所以也適用上一種情況，顯示為一個"?".)
實際編程中，JSP/Servlet程序得到錯誤的漢字信息，往往是這兩個過程的疊加，有時甚至是兩個過程疊加后反復(fù)作用的結(jié)果.
4.JSP/Servlet漢字編碼問題及在WAS中的解決辦法
4.1常見的encoding問題的現(xiàn)象
網(wǎng)上常出現(xiàn)的JSP/Servletencoding問題一般都表現(xiàn)在browser或應(yīng)用程序端，如:
瀏覽器中看到的Jsp/Servlet頁面中的漢字怎么都成了’?’?
瀏覽器中看到的Servlet頁面中的漢字怎么都成了亂碼？
JAVA應(yīng)用程序界面中的漢字怎么都成了方塊？
Jsp/Servlet頁面無法顯示GBK漢字。
JSP頁面中內(nèi)嵌在<%...%>,<%=...%>等Tag包含的JAVAcode中的中文成了亂碼，但頁面的其它漢字是對的。
Jsp/Servlet不能接收form提交的漢字。
JSP/Servlet數(shù)據(jù)庫讀寫無法獲得正確的內(nèi)容。
隱藏在這些問題后面的是各種錯誤的字符轉(zhuǎn)換和處理（除第3個外，是因為Javafont設(shè)置錯誤引起的）。解決類似的字符encoding問題，需要了解Jsp/Servlet的運行過程，檢查可能出現(xiàn)問題的各個點。
4.2JSP/Servletweb編程時的encoding問題
運行于Java應(yīng)用服務(wù)器的JSP/Servlet為Browser提供HTML內(nèi)容，其過程如下圖所示：
其中有字符編碼轉(zhuǎn)換的地方有:
JSP編譯。Java應(yīng)用服務(wù)器將根據(jù)JVM的file.encoding值讀?。燡SP源文件，編譯生成JAVA源文件，再根據(jù)file.encoding值寫回文件系統(tǒng)。如果當前系統(tǒng)語言支持GBK，那么這時候不會出現(xiàn)encoding問題。如果是英文的系統(tǒng)，如LANG是en_US的Linux,AIX或Solaris，則要將JVM的file.encoding值置成GBK。系統(tǒng)語言如果是GB2312，則根據(jù)需要，確定要不要設(shè)置file.encoding，將file.encoding設(shè)為GBK可以解決潛在的GBK字符亂碼問題
Java需要被編譯為.class才能在JVM中執(zhí)行，這個過程存在與a.同樣的file.encoding問題。從這里開始servlet和jsp的運行就類似了，只不過Servlet的編譯不是自動進行的。對于JSP程序,對產(chǎn)生的JAVA中間文件的編譯是自動進行的(在程序中直接調(diào)用sun.tools.javac.Main類).因此如果在這一步出現(xiàn)問題的話,也要檢查encoding和OS的語言環(huán)境，或者將內(nèi)嵌在JSPJAVACode中的靜態(tài)漢字轉(zhuǎn)為Unicode,要么靜態(tài)文本輸出不要放在JAVAcode中。對于Servlet,javac編譯時手工指定-encoding參數(shù)就可以了。
Servlet需要將HTML頁面內(nèi)容轉(zhuǎn)換為browser可接受的encoding內(nèi)容發(fā)送出去。依賴于各JAVAAppServer的實現(xiàn)方式，有的將查詢Browser的accept-charset和accept-language參數(shù)或以其它猜的方式確定encoding值，有的則不管。因此采用固定encoding也許是最好的解決方法。對于中文網(wǎng)頁，可在JSP或Servlet中設(shè)置contentType="text/html;charset=GB2312"；如果頁面中有GBK字符，則設(shè)置為contentType="text/html;charset=GBK"，由于IE和Netscape對GBK的支持程度不一樣，作這種設(shè)置時需要測試一下。
因為16位JAVAchar在網(wǎng)絡(luò)傳送時高8位會被丟棄，也為了確保Servlet頁面中的漢字（包括內(nèi)嵌的和servlet運行過程中得到的）是期望的內(nèi)碼，可以用PrintWriterout=res.getWriter()取代ServletOutputStreamout=res.getOutputStream().PrinterWriter將根據(jù)contentType中指定的charset作轉(zhuǎn)換(ContentType需在此之前指定！);也可以用OutputStreamWriter封裝ServletOutputStream類并用write(String)輸出漢字字符串。
對于JSP，JAVAApplicationServer應(yīng)當能夠確保在這個階段將嵌入的漢字正確傳送出去。
這是解釋URL字符encoding問題。如果通過get/post方式從browser返回的參數(shù)值中包含漢字信息，servlet將無法得到正確的值。SUN的J2SDK中，HttpUtils.parseName在解析參數(shù)時根本沒有考慮browser的語言設(shè)置，而是將得到的值按byte方式解析。這是網(wǎng)上討論得最多的encoding問題。因為這是設(shè)計缺陷，只能以bin方式重新解析得到的字符串；或者以hackHttpUtils類的方式解決。參考文章2均有介紹，不過最好將其中的中文encodingGB2312、CP1381都改為GBK，否則遇到GBK漢字時，還是會有問題。
ServletAPI2.3提供一個新的函數(shù)HttpServeletRequest.setCharacterEncoding用于在調(diào)用request.getParameter(“param_name”)前指定應(yīng)用程序希望的encoding，這將有助于徹底解決這個問題。
4.3IBMWebsphereApplicationServer中的解決方法
WebSphereApplicationServer對標準的ServletAPI2.x作了擴展，提供較好的多語言支持。運行在中文的操作系統(tǒng)中，可以不作任何設(shè)置就可以很好地處理漢字。下面的說明只是對WAS是運行在英文的系統(tǒng)中，或者需要有GBK支持時有效。
上述c,d情況，WAS都要查詢Browser的語言設(shè)置，在缺省狀況下，zh,zh-cn等均被映射為JAVAencodingCP1381（注意：CP1381只是等同于GB2312的一個codepage，沒有GBK支持）。這樣做我想是因為無法確認Browser運行的操作系統(tǒng)是支持GB2312,還是GBK，所以取其小。但是實際的應(yīng)用系統(tǒng)還是要求頁面中出現(xiàn)GBK漢字，最著名的是朱總理名字中的“镕"(rong2，0xe946，\u9555)，所以有時還是需要將Encoding/Charset指定為GBK。當然WAS中變更缺省的encoding沒有上面說的那么麻煩，針對a,b，參考文章5，在ApplicationServer的命令行參數(shù)中指定-Dfile.encoding=GBK即可；針對d，在ApplicationServer的命令行參數(shù)中指定-Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那么c情況下可以不再指定charset。
上面列出的問題中還有一個關(guān)于Tag<%...%>,<%=...%>中的JAVA代碼里包含的靜態(tài)文本未能正確顯示的問題，在WAS中的解決方法是除了設(shè)置正確的file.encoding,還需要以相同方法設(shè)置-Duser.language=zh-Duser.region=CN。這與JAVAlocale的設(shè)置有關(guān)。
4.4數(shù)據(jù)庫讀寫時的encoding問題
JSP/Servlet編程中經(jīng)常出現(xiàn)encoding問題的另一個地方是讀寫數(shù)據(jù)庫中的數(shù)據(jù)。
流行的關(guān)系數(shù)據(jù)庫系統(tǒng)都支持數(shù)據(jù)庫encoding，也就是說在創(chuàng)建數(shù)據(jù)庫時可以指定它自己的字符集設(shè)置，數(shù)據(jù)庫的數(shù)據(jù)以指定的編碼形式存儲。當應(yīng)用程序訪問數(shù)據(jù)時，在入口和出口處都會有encoding轉(zhuǎn)換。對于中文數(shù)據(jù)，數(shù)據(jù)庫字符編碼的設(shè)置應(yīng)當保證數(shù)據(jù)的完整性.GB2312，GBK，UTF-8等都是可選的數(shù)據(jù)庫encoding；也可以選擇ISO8859-1(8-bit)，那么應(yīng)用程序在寫數(shù)據(jù)之前須將16Bit的一個漢字或Unicode拆分成兩個8-bit的字符，讀數(shù)據(jù)之后則需將兩個字節(jié)合并起來，同時還要判別其中的SBCS字符。沒有充分利用數(shù)據(jù)庫encoding的作用，反而增加了編程的復(fù)雜度，ISO8859-1不是推薦的數(shù)據(jù)庫encoding。JSP/Servlet編程時，可以先用數(shù)據(jù)庫管理系統(tǒng)提供的管理功能檢查其中的中文數(shù)據(jù)是否正確。
然后應(yīng)當注意的是讀出來的數(shù)據(jù)的encoding，JAVA程序中一般得到的是Unicode。寫數(shù)據(jù)時則相反。
4.5定位問題時常用的技巧
定位中文encoding問題通常采用最笨的也是最有效的辦法——在你認為有嫌疑的程序處理后打印字符串的內(nèi)碼。通過打印字符串的內(nèi)碼，你可以發(fā)現(xiàn)什么時候中文字符被轉(zhuǎn)換成Unicode，什么時候Unicode被轉(zhuǎn)回中文內(nèi)碼，什么時候一個中文字成了兩個Unicode字符，什么時候中文字符串被轉(zhuǎn)成了一串問號，什么時候中文字符串的高位被截掉了……
取用合適的樣本字符串也有助于區(qū)分問題的類型。如：”aa啊aa丂aa”等中英相間、GB、GBK特征字符均有的字符串。一般來說，英文字符無論怎么轉(zhuǎn)換或處理，都不會失真（如果遇到了，可以嘗試著增加連續(xù)的英文字母長度）。
5.結(jié)束語
其實JSP/Servlet的中文encoding并沒有想像的那么復(fù)雜，雖然定位和解決問題沒有定規(guī)，各種運行環(huán)境也各不盡然，但后面的原理是一樣的。了解字符集的知識是解決字符問題的基礎(chǔ)。不過，隨著中文字符集的變化，不僅僅是java編程，中文信息處理中的問題還是會存在一段時間的。
...........................UB修改于2002-06-14 10:52:07
RE:JAVA編程技術(shù)中漢字問題的分析及解決(轉(zhuǎn))
作者：UB 時間：2002-07-22 17:04:00 [修改] [回復(fù)] [刪除]
JAVA編程技術(shù)中漢字問題的分析及解決
文章來源：www.ibm.com
在基于Java語言的編程中，我們經(jīng)常碰到漢字的處理及顯示的問題。一大堆看不懂的亂碼肯定不是我們愿意看到的顯示效果，怎樣才能夠讓那些漢字正確顯示呢？Java語言默認的編碼方式是UNICODE，而我們中國人通常使用的文件和數(shù)據(jù)庫都是基于GB2312或者BIG5等方式編碼的，怎樣才能夠恰當?shù)剡x擇漢字編碼方式并正確地處理漢字的編碼呢？本文將從漢字編碼的常識入手，結(jié)合Java編程實例，分析以上兩個問題并提出解決它們的方案。
現(xiàn)在Java編程語言已經(jīng)廣泛應(yīng)用于互聯(lián)網(wǎng)世界，早在Sun公司開發(fā)Java語言的時候，就已經(jīng)考慮到對非英文字符的支持了。Sun公司公布的Java運行環(huán)境（JRE）本身就分英文版和國際版，但只有國際版才支持非英文字符。不過在Java編程語言的應(yīng)用中，對中文字符的支持并非如同JavaSoft的標準規(guī)范中所宣稱的那樣完美，因為中文字符集不只一個，而且不同的操作系統(tǒng)對中文字符的支持也不盡相同，所以會有許多和漢字編碼處理有關(guān)的問題在我們進行應(yīng)用開發(fā)中困擾著我們。有很多關(guān)于這些問題的解答，但都比較瑣碎，并不能夠滿足大家迫切解決問題的愿望，關(guān)于Java中文問題的系統(tǒng)研究并不多，本文從漢字編碼常識出發(fā)，分析Java中文問題，希望對大家解決這個問題有所幫助。
漢字編碼的常識
我們知道，英文字符一般是以一個字節(jié)來表示的，最常用的編碼方法是ASCII。但一個字節(jié)最多只能區(qū)分256個字符，而漢字成千上萬，所以現(xiàn)在都以雙字節(jié)來表示漢字，為了能夠與英文字符分開，每個字節(jié)的最高位一定為1，這樣雙字節(jié)最多可以表示64K格字符。我們經(jīng)常碰到的編碼方式有GB2312、BIG5、UNICODE等。關(guān)于具體編碼方式的詳細資料，有興趣的讀者可以查閱相關(guān)資料。我膚淺談一下和我們關(guān)系密切的GB2312和UNICODE。GB2312碼，中華人民共和國國家標準漢字信息交換用編碼，是一個由中華人民共和國國家標準總局發(fā)布的關(guān)于簡化漢字的編碼，通行于中國大陸地區(qū)及新加坡，簡稱國標碼。兩個字節(jié)中，第一個字節(jié)（高字節(jié)）的值為區(qū)號值加32（20H），第二個字節(jié)（低字節(jié)）的值為位號值加32（20H），用這兩個值來表示一個漢字的編碼。UNICODE碼是微軟提出的解決多國字符問題的多字節(jié)等長編碼，它對英文字符采取前面加“0”字節(jié)的策略實現(xiàn)等長兼容。如“A”的ASCII碼為0x41，UNICODE就為0x00，0x41。利用特殊的工具各種編碼之間可以互相轉(zhuǎn)換。
Java中文問題的初步認識
我們基于Java編程語言進行應(yīng)用開發(fā)時，不可避免地要處理中文。Java編程語言默認的編碼方式是UNICODE，而我們通常使用的數(shù)據(jù)庫及文件都是基于GB2312編碼的，我們經(jīng)常碰到這樣的情況：瀏覽基于JSP技術(shù)的網(wǎng)站看到的是亂碼，文件打開后看到的也是亂碼，被Java修改過的數(shù)據(jù)庫的內(nèi)容在別的場合應(yīng)用時無法繼續(xù)正確地提供信息。
StringsEnglish=“apple”;
StringsChinese=“蘋果”;
Strings=“蘋果apple”;
sEnglish的長度是5，sChinese的長度是4，而s默認的長度是14。對于sEnglish來說，Java中的各個類都支持得非常好，肯定能夠正確顯示。但對于sChinese和s來說，雖然JavaSoft聲明Java的基本類已經(jīng)考慮到對多國字符的支持（默認UNICODE編碼），但是如果操作系統(tǒng)的默認編碼不是UNICODE，而是國標碼等。從Java源代碼到得到正確的結(jié)果，要經(jīng)過“Java源代碼->Java字節(jié)碼->;虛擬機->操作系統(tǒng)->顯示設(shè)備”的過程。在上述過程中的每一步驟，我們都必須正確地處理漢字的編碼，才能夠使最終的顯示結(jié)果正確。
“Java源代碼->Java字節(jié)碼”，標準的Java編譯器javac使用的字符集是系統(tǒng)默認的字符集，比如在中文Windows操作系統(tǒng)上就是GBK,而在Linux操作系統(tǒng)上就是ISO-8859-1，所以大家會發(fā)現(xiàn)在Linux操作系統(tǒng)上編譯的類中源文件中的中文字符都出了問題，解決的辦法就是在編譯的時候添加encoding參數(shù)，這樣才能夠與平臺無關(guān)。用法是
javac–encodingGBK。
“Java字節(jié)碼->虛擬機->操作系統(tǒng)”，Java運行環(huán)境（JRE）分英文版和國際版，但只有國際版才支持非英文字符。Java開發(fā)工具包（JDK）肯定支持多國字符，但并非所有的計算機用戶都安裝了JDK。很多操作系統(tǒng)及應(yīng)用軟件為了能夠更好的支持Java，都內(nèi)嵌了JRE的國際版本，為自己支持多國字符提供了方便。
“操作系統(tǒng)->顯示設(shè)備”，對于漢字來說，操作系統(tǒng)必須支持并能夠顯示它。英文操作系統(tǒng)如果不搭配特殊的應(yīng)用軟件的話，是肯定不能夠顯示中文的。
還有一個問題，就是在Java編程過程中，對中文字符進行正確的編碼轉(zhuǎn)換。例如，向網(wǎng)頁輸出中文字符串的時候，不論你是用
out.println(string);//string是含中文的字符串
還是用
<%=string%>，都必須作UNICODE到GBK的轉(zhuǎn)換，或者手動，或者自動。在JSP1.0中，可以定義輸出字符集，從而實現(xiàn)內(nèi)碼的自動轉(zhuǎn)換。用法是
<%@pageContentType=”text/html;charset=gb2312”%>
但是在一些JSP版本中并沒有提供對輸出字符集的支持，（例如JSP0.92），這就需要手動編碼輸出了，方法非常多。最常用的方法是
Strings1=request.getParameter(“keyword”);
Strings2=newString(s1.getBytes(“ISO-8859-1”),”GBK”);
getBytes方法用于將中文字符以“ISO-8859-1”編碼方式轉(zhuǎn)化成字節(jié)數(shù)組，而“GBK”是目標編碼方式。我們從以ISO-8859-1方式編碼的數(shù)據(jù)庫中讀出中文字符串s1，經(jīng)過上述轉(zhuǎn)換過程，在支持GBK字符集的操作系統(tǒng)和應(yīng)用軟件中就能夠正確顯示中文字符串s2。
Java中文問題的表層分析及處理
背景
開發(fā)環(huán)境JDK1.15Vcafe2.0JPadPro
服務(wù)器端NTIISSybaseSystemJconnect（JDBC）
客戶端IE5.0Pwin98
CLASS文件存放在服務(wù)器端，由客戶端的瀏覽器運行APPLET，APPLET只起調(diào)入FRAME類等主程序的作用。界面包括Textfield，TextArea，List，Choice等。
I.取中文
用JDBC執(zhí)行SELECT語句從服務(wù)器端讀取數(shù)據(jù)（中文）后，將數(shù)據(jù)用APPEND方法加到TextArea（TA），不能正確顯示。但加到List中時，大部分漢字卻可正確顯示。
將數(shù)據(jù)按“ISO-8859-1”編碼方式轉(zhuǎn)化為字節(jié)數(shù)組，再按系統(tǒng)缺省編碼方式（DefaultCharacterEncoding）轉(zhuǎn)化為STRING，即可在TA和List中正確顯示。
程序段如下：
dbstr2=results.getString(1);
//AfterreadingtheresultfromDBserver，convertingittostring.
dbbyte1=dbstr2.getBytes(“iso-8859-1”);
dbstr1=newString(dbbyte1);
在轉(zhuǎn)換字符串時不采用系統(tǒng)默認編碼方式，而直接采用“GBK”或者“GB2312”,在A和B兩種情況下，從數(shù)據(jù)庫取數(shù)據(jù)都沒有問題。
II.寫中文到數(shù)據(jù)庫
處理方式與“取中文”相逆，先將SQL語句按系統(tǒng)缺省編碼方式轉(zhuǎn)化為字節(jié)數(shù)組，再按“ISO-8859-1”編碼方式轉(zhuǎn)化為STRING，最后送去執(zhí)行，則中文信息可正確寫入數(shù)據(jù)庫。
程序段如下：
sqlstmt=tf_input.getText();
//BeforesendingstatementtoDBserver，convertingittosqlstatement.
dbbyte1=sqlstmt.getBytes();
sqlstmt=newString(dbbyte1,”iso-8859-1”);
_stmt=_con.createStatement();
_stmt.executeUpdate(sqlstmt);
……
問題：如果客戶機上存在CLASSPATH指向JDK的CLASSES.ZIP時（稱為A情況），上述程序代碼可正確執(zhí)行。但是如果客戶機只有瀏覽器，而沒有JDK和CLASSPATH時（稱為B情況），則漢字無法正確轉(zhuǎn)換。
我們的分析：
1.經(jīng)過測試，在A情況下，程序運行時系統(tǒng)的缺省編碼方式為GBK或者GB2312。在B情況下，程序啟動時瀏覽器的JAVA控制臺中出現(xiàn)如下錯誤信息：
Can'tfindresourceforsun.awt.windows.awtLocalization_zh_CN
然后系統(tǒng)的缺省編碼方式為“8859-1”。
2.如果在轉(zhuǎn)換字符串時不采用系統(tǒng)缺省編碼方式，而是直接采用“GBK”或“GB2312”，則在A情況下程序仍然可正常運行，在B情況下，系統(tǒng)出現(xiàn)錯誤：
UnsupportedEncodingException。
3.在客戶機上，把JDK的CLASSES.ZIP解壓后，放在另一個目錄中，CLASSPATH只包含該目錄。然后一邊逐步刪除該目錄中的.CLASS文件，另一邊運行測試程序，最后發(fā)現(xiàn)在一千多個CLASS文件中，只有一個是必不可少的，該文件是：sun.io.CharToByteDoubleByte.class。
將該文件拷到服務(wù)器端和其它的類放在一起，并在程序的開頭IMPORT它，在B情況下程序仍然無法正常運行。
4.在A情況下，如果在CLASSPTH中去掉sun.io.CharToByteDoubleByte.class，則程序運行時測得默認編碼方式為“8859-1”，否則為“GBK”或“GB2312”。
如果JDK的版本為1.2以上的話，在B情況下遇到的問題得到了很好的解決，測試的步驟同上，有興趣的讀者可以嘗試一下。
Java中文問題的根源分析及解決
在簡體中文MSWindows98+JDK1.3下，可以用System.getProperties()得到Java運行環(huán)境的一些基本屬性，類PoorChinese可以幫助我們得到這些屬性。
類PoorChinese的源代碼：
publicclassPoorChinese{
publicstaticvoidmain(String[>args){
System.getProperties().list(System.out);
}
}
執(zhí)行javaPoorChinese后，我們會得到:
系統(tǒng)變量file.encoding的值為GBK，user.language的值為zh，user.region的值為CN，這些系統(tǒng)變量的值決定了系統(tǒng)默認的編碼方式是GBK。
在上述系統(tǒng)中，下面的代碼將GB2312文件轉(zhuǎn)換成Big5文件，它們能夠幫助我們理解Java中漢字編碼的轉(zhuǎn)化:
importjava.io.*;
importjava.util.*;
publicclassgb2big5{
staticintiCharNum=0;
publicstaticvoidmain(String[>args){
System.out.println("InputGB2312file,outputBig5file.");
if(args.length!=2){
System.err.println("Usage:jviewgb2big5gbfilebig5file");
System.exit(1);
}
StringinputString=readInput(args[0>);
writeOutput(inputString,args[1>);
System.out.println("NumberofCharactersinfile:"+iCharNum+".");
}
staticvoidwriteOutput(Stringstr,StringstrOutFile){
try{
FileOutputStreamfos=newFileOutputStream(strOutFile);
Writerout=newOutputStreamWriter(fos,"Big5");
out.write(str);
out.close();
}
catch(IOExceptione){
e.printStackTrace();
e.printStackTrace();
}
}
staticStringreadInput(StringstrInFile){
StringBufferbuffer=newStringBuffer();
try{
FileInputStreamfis=newFileInputStream(strInFile);
InputStreamReaderisr=newInputStreamReader(fis,"GB2312");
Readerin=newBufferedReader(isr);
intch;
while((ch=in.read())>-1){
iCharNum+=1;
buffer.append((char)ch);
}
in.close();
returnbuffer.toString();
}
catch(IOExceptione){
e.printStackTrace();
returnnull;
}
}
}
編碼轉(zhuǎn)化的過程如下：
ByteToCharGB2312CharToByteBig5
GB2312------------------>Unicode------------->Big5
執(zhí)行javagb2big5gb.txtbig5.txt，如果gb.txt的內(nèi)容是“今天星期三”，則得到的文件big5.txt中的字符能夠正確顯示；而如果gb.txt的內(nèi)容是“情人節(jié)快樂”，則得到的文件big5.txt中對應(yīng)于“節(jié)”和“樂”的字符都是符號“？”（0x3F），可見sun.io.ByteToCharGB2312和sun.io.CharToByteBig5這兩個基本類并沒有編好。
正如上例一樣，Java的基本類也可能存在問題。由于國際化的工作并不是在國內(nèi)完成的，所以在這些基本類發(fā)布之前，沒有經(jīng)過嚴格的測試，所以對中文字符的支持并不像JavaSoft所聲稱的那樣完美。前不久，我的一位技術(shù)上的朋友發(fā)信給我說，他終于找到了JavaServlet中文問題的根源。兩周以來，他一直為JavaServlet的中文問題所困擾，因為每面對一個含有中文字符的字符串都必須進行強制轉(zhuǎn)換才能夠得到正確的結(jié)果（這好象是大家公認的唯一的解決辦法）。后來，他確實不想如此繼續(xù)安分下去了，因為這樣的事情確實不應(yīng)該是高級程序員所要做的工作，他就找出Servlet解碼的源代碼進行分析，因為他懷疑問題就出在解碼這部分。經(jīng)過四個小時的奮斗，他終于找到了問題的根源所在。原來他的懷疑是正確的，Servlet的解碼部分完全沒有考慮雙字節(jié)，直接把%XX當作一個字符。（原來JavaSoft也會犯這幺低級的錯誤?。?
如果你對這個問題有興趣或者遇到了同樣的煩惱的話，你可以按照他的步驟對Servlet.jar進行修改：
找到源代碼HttpUtils中的staticprivateStringparseName，在返回前將sb（StringBuffer）復(fù)制成bytebs[>，然后returnnewString(bs,”GB2312”)。作上述修改后就需要自己解碼了：
HashTableform=HttpUtils.parseQueryString(request.getQueryString())或者
form=HttpUtils.parsePostData(……)
千萬別忘了編譯后放到Servlet.jar里面。
五、關(guān)于Java中文問題的總結(jié)
Java編程語言成長于網(wǎng)絡(luò)世界，這就要求Java對多國字符有很好的支持。Java編程語言適應(yīng)了計算的網(wǎng)絡(luò)化的需求，為它能夠在網(wǎng)絡(luò)世界迅速成長奠定了堅實的基礎(chǔ)。Java的締造者（JavaSoft）已經(jīng)考慮到Java編程語言對多國字符的支持，只是現(xiàn)在的解決方案有很多缺陷在里面，需要我們付諸一些補償性的措施。而世界標準化組織也在努力把人類所有的文字統(tǒng)一在一種編碼之中，其中一種方案是ISO10646，它用四個字節(jié)來表示一個字符。當然，在這種方案未被采用之前，還是希望JavaSoft能夠嚴格地測試它的產(chǎn)品，為用戶帶來更多的方便。
附一個用于從數(shù)據(jù)庫和網(wǎng)絡(luò)中取出中文亂碼的處理函數(shù)，入?yún)⑹怯袉栴}的字符串，出參是問題已經(jīng)解決了的字符串。
StringparseChinese(Stringin)
{
Strings=null;
bytetemp[>;
if(in==null)
{
System.out.println("Warn:Chinesenullfounded!");
returnnewString("");
}
try
{
temp=in.getBytes("iso-8859-1");
s=newString(temp);
}
catch(UnsupportedEncodingExceptione)
{
System.out.println(e.toString());
}
returns;
}
|