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ù)當(dāng)時的 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 表示字符的，遵守 Unicode V2.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 漢字字符集
其實解決 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 的字位。其所有字符都可以一對一映射到 Unicode 2.0，也就是說 JAVA 實際上提供了 GBK 字符集的支持。這是現(xiàn)階段 Windows 和其它一些中文操作系統(tǒng)的缺省字符集，但并不是所有的國際化軟件都支持該字符集，感覺是他們并不完全知道 GBK 是怎么回事。值得注意的是它不是國家標(biāo)準(zhǔn)，而只是規(guī)范。隨著 GB18030-2000國標(biāo)的發(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)的是能夠完全映射到 Unicode 3.0 標(biāo)準(zhǔn)的所有字形。
●它是國家標(biāo)準(zhǔn)，是強制性的。
現(xiàn)在還沒有任何一個操作系統(tǒng)或軟件實現(xiàn)了 GBK2K 的支持，這是現(xiàn)階段和將來漢化的工作內(nèi)容。
3.JSP/Servlet 漢字編碼問題及在 WAS 中的解決辦法
3.1 常見的 encoding 問題的現(xiàn)象
網(wǎng)上常出現(xiàn)的 JSP/Servlet encoding 問題一般都表現(xiàn)在 browser 或應(yīng)用程序端，如:
●瀏覽器中看到的 Jsp/Servlet 頁面中的漢字怎么都成了 ’?’ ?
●瀏覽器中看到的 Servlet 頁面中的漢字怎么都成了亂碼？
●JAVA 應(yīng)用程序界面中的漢字怎么都成了方塊？
●Jsp/Servlet 頁面無法顯示 GBK 漢字。
●Jsp/Servlet 不能接收 form 提交的漢字。
●JSP/Servlet 數(shù)據(jù)庫讀寫無法獲得正確的內(nèi)容。
隱藏在這些問題后面的是各種錯誤的字符轉(zhuǎn)換和處理（除第3個外，是因為 Java font 設(shè)置錯誤引起的）。解決類似的字符 encoding 問題，需要了解 Jsp/Servlet 的運行過程，檢查可能出現(xiàn)問題的各個點。
3.2 JSP/Servlet web 編程時的 encoding 問題
運行于Java 應(yīng)用服務(wù)器的 JSP/Servlet 為 Browser 提供 HTML 內(nèi)容，其過程如下圖所示：
其中有字符編碼轉(zhuǎn)換的地方有：
a.JSP 編譯。Java 應(yīng)用服務(wù)器將根據(jù) JVM 的 file.encoding 值讀取 JSP 源文件，并轉(zhuǎn)換為內(nèi)部字符編碼進行 JSP 編譯，生成 JAVA 源文件，根據(jù) file.encoding 值寫回文件系統(tǒng)。如果當(dā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 字符亂碼問題。
b.Java 需要被編譯為 .class 才能在 JVM 中執(zhí)行，這個過程存在與a.同樣的 file.encoding 問題。從這里開始 servlet 和 jsp 的運行就類似了，只不過 Servlet 的編譯不是自動進行的。
c.Servlet 需要將 HTML 頁面內(nèi)容轉(zhuǎn)換為 browser 可接受的 encoding 內(nèi)容發(fā)送出去。依賴于各 JAVA App Server 的實現(xiàn)方式，有的將查詢 Browser 的 accept-charset 和 accept-language 參數(shù)或以其它猜的方式確定 encoding 值，有的則不管。因此 constant-encoding 也許是最好的解決方法。對于中文網(wǎng)頁，可在 JSP 或 Servlet 中設(shè)置 contentType="text/html; charset=GB2312"；如果頁面中有GBK字符，則設(shè)置為contentType="text/html; charset=GBK"，由于IE 和 Netscape對GBK的支持程度不一樣，作這種設(shè)置時需要測試一下。
因為16位 JAVA char在網(wǎng)絡(luò)傳送時高8位會被丟棄，也為了確保Servlet頁面中的漢字（包括內(nèi)嵌的和servlet運行過程中得到的）是期望的內(nèi)碼，可以用 PrintWriter out=res.getWriter() 取代 ServletOutputStream out=res.getOutputStream(), PrinterWriter 將根據(jù)contentType中指定的charset作轉(zhuǎn)換(ContentType需在此之前指定！);也可以用OutputStreamWriter封裝 ServletOutputStream 類并用write(String)輸出漢字字符串。
對于 JSP，JAVA Application Server 應(yīng)當(dāng)能夠確保在這個階段將嵌入的漢字正確傳送出去。
d.這是 URL 字符 encoding 問題。如果通過 get/post 方式從 browser 返回的值中包含漢字信息， servlet 將無法得到正確的值。SUN的 J2SDK 中，HttpUtils.parseName 在解析參數(shù)時根本沒有考慮 browser 的語言設(shè)置，而是將得到的值按 byte 方式解析。這是網(wǎng)上討論得最多的 encoding 問題。因為這是設(shè)計缺陷，只能以 bin 方式重新解析得到的字符串；或者以 hack HttpUtils 類的方式解決。參考文章 2、3 均有介紹，不過最好將其中的中文 encoding GB2312、 CP1381 都改為 GBK，否則遇到 GBK 漢字時，還是會有問題。
Servlet API 2.3 提供一個新的函數(shù) HttpServeletRequest.setCharacterEncoding 用于在調(diào)用 request.getParameter(“param_name”) 前指定應(yīng)用程序希望的 encoding，這將有助于徹底解決這個問題。
WebSphere Application Server 對標(biāo)準(zhǔn)的 Servlet API 2.x 作了擴展，提供較好的多語言支持。上述c,d情況，WAS 都要查詢 Browser 的語言設(shè)置，在缺省狀況下zh、zh-cn 等均被映射為 JAVA encoding CP1381（注意：CP1381 只是等同于 GB2312 的一個 codepage，沒有 GBK 支持）。這樣做我想是因為無法確認 Browser 運行的操作系統(tǒng)是支持GB2312, 還是 GBK，所以取其小。但是實際的應(yīng)用系統(tǒng)還是要求頁面中出現(xiàn) GBK 漢字，最著名的是朱總理名字中的“?”(rong2 ，0xe946，\u9555)，所以有時還是需要將 Encoding/Charset 指定為 GBK。當(dāng)然 WAS 中變更缺省的 encoding 沒有上面說的那么麻煩，針對 a,b，參考文章 5 ），在 Application Server 的命令行參數(shù)中指定 -Dfile.encoding=GBK 即可； 針對 d，在 Application Server 的命令行參數(shù)中指定-Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那么c情況下可以不再指定charset。
3.3 數(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ù)以指定的編碼形式存儲。當(dāng)應(yīng)用程序訪問數(shù)據(jù)時，在入口和出口處都會有 encoding 轉(zhuǎn)換。對于中文數(shù)據(jù)，應(yīng)當(dāng)保證數(shù)據(jù)的完整性。GB2312，GBK，UTF-8 等都是可選的數(shù)據(jù)庫 encoding；如果選擇 ISO8859-1(8-bit SBCS)，那么應(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)當(dāng)注意的是讀出來的數(shù)據(jù)的 encoding，JAVA 程序中一般得到的是 Unicode。寫數(shù)據(jù)時則相反。
3.4 定位問題時常用的技巧
定位中文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ù)的英文字母長度）。
4.結(jié)束語
其實 JSP/Servlet 的中文encoding 并沒有想像的那么復(fù)雜，雖然定位和解決問題沒有定規(guī)，各種運行環(huán)境也各不盡然，但后面的原理是一樣的。了解字符集的知識是解決字符問題的基礎(chǔ)。不過，隨著中文字符集的變化，不僅僅是 java 編程，中文信息處理中的問題還是會存在一段時間的。
