JSP/Servlet 中的漢字編碼問題
（作者：張建芳，轉自IBM DeveloperWorks 中國網站　2001年04月18日 15:08）

　　網上就 JSP/Servlet 中 DBCS 字符編碼問題有許多優秀的文章和討論，本文對它們作一些整理，并結合 IBM WebSphere Application Server 3.5（WAS）的解決方法作一些說明，希望它不是多余的。

1.問題的起源
　　每個國家（或區域）都規定了計算機信息交換用的字符編碼集，如美國的 ASCII，中國的 GB2312-80，日本的 JIS 等，作為該國家/區域內信息處理的基礎，有著統一編碼的重要作用。字符編碼集按長度分為 SBCS（單字節字符集），DBCS（雙字節字符集）兩大類。早期的軟件（尤其是操作系統），為了解決本地字符信息的計算機處理，出現了各種本地化版本（L10N），為了區分，引進了 LANG，Codepage 等概念。但是由于各個本地字符集代碼范圍重疊，相互間信息交換困難；軟件各個本地化版本獨立維護成本較高。因此有必要將本地化工作中的共性抽取出來，作一致處理，將特別的本地化處理內容降低到最少。這也就是所謂的國際化（I18N）。各種語言信息被進一步規范為 Locale 信息。處理的底層字符集變成了幾乎包含了所有字形的 Unicode。

　　現在大部分具有國際化特征的軟件核心字符處理都是以 Unicode 為基礎的，在軟件運行時根據當時的 Locale/Lang/Codepage 設置確定相應的本地字符編碼設置，并依此處理本地字符。在處理過程中需要實現 Unicode 和本地字符集的相互轉換，甚或以 Unicode 為中間的兩個不同本地字符集的相互轉換。這種方式在網絡環境下被進一步延伸，任何網絡兩端的字符信息也需要根據字符集的設置轉換成可接受的內容。

　　Java 語言內部是用 Unicode 表示字符的，遵守 Unicode V2.0。Java 程序無論是從/往文件系統以字符流讀/寫文件，還是往 URL 連接寫 HTML 信息，或從 URL 連接讀取參數值，都會有字符編碼的轉換。這樣做雖然增加了編程的復雜度，容易引起混淆，但卻是符合國際化的思想的。

　　從理論上來說，這些根據字符集設置而進行的字符轉換不應該產生太多問題。而事實是由于應用程序的實際運行環境不同，Unicode 和各個本地字符集的補充、完善，以及系統或應用程序實現的不規范，轉碼時出現的問題時時困擾著程序員和用戶。

2.GB2312-80，GBK，GB18030-2000 漢字字符集
　　其實解決 JAVA 程序中的漢字編碼問題的方法往往很簡單，但理解其背后的原因，定位問題，還需要了解現有的漢字編碼和編碼轉換。

　　GB2312-80 是在國內計算機漢字信息技術發展初始階段制定的，其中包含了大部分常用的一、二級漢字，和 9 區的符號。該字符集是幾乎所有的中文系統和國際化的軟件都支持的中文字符集，這也是最基本的中文字符集。其編碼范圍是高位0xa1－0xfe，低位也是 0xa1-0xfe；漢字從 0xb0a1 開始，結束于 0xf7fe；

　　GBK 是 GB2312-80 的擴展，是向上兼容的。它包含了 20902 個漢字，其編碼范圍是 0x8140-0xfefe，剔除高位 0x80 的字位。其所有字符都可以一對一映射到 Unicode 2.0，也就是說 JAVA 實際上提供了 GBK 字符集的支持。這是現階段 Windows 和其它一些中文操作系統的缺省字符集，但并不是所有的國際化軟件都支持該字符集，感覺是他們并不完全知道 GBK 是怎么回事。值得注意的是它不是國家標準，而只是規范。隨著 GB18030-2000國標的發布，它將在不久的將來完成它的歷史使命。

　　GB18030-2000(GBK2K) 在 GBK 的基礎上進一步擴展了漢字，增加了藏、蒙等少數民族的字形。GBK2K 從根本上解決了字位不夠，字形不足的問題。它有幾個特點：

　　●它并沒有確定所有的字形，只是規定了編碼范圍，留待以后擴充。

　　●編碼是變長的，其二字節部分與 GBK 兼容；四字節部分是擴充的字形、字位，其編碼范圍是首字節 0x81-0xfe、二字節0x30-0x39、三字節 0x81-0xfe、四字節0x30-0x39。

　　●它的推廣是分階段的，首先要求實現的是能夠完全映射到 Unicode 3.0 標準的所有字形。

　　●它是國家標準，是強制性的。

　　現在還沒有任何一個操作系統或軟件實現了 GBK2K 的支持，這是現階段和將來漢化的工作內容。

3.JSP/Servlet 漢字編碼問題及在 WAS 中的解決辦法
　　3.1 常見的 encoding 問題的現象

　　網上常出現的 JSP/Servlet encoding 問題一般都表現在 browser 或應用程序端，如:

　　●瀏覽器中看到的 Jsp/Servlet 頁面中的漢字怎么都成了 ’?’ ?

　　●瀏覽器中看到的 Servlet 頁面中的漢字怎么都成了亂碼？

　　●JAVA 應用程序界面中的漢字怎么都成了方塊？

　　●Jsp/Servlet 頁面無法顯示 GBK 漢字。

　　●Jsp/Servlet 不能接收 form 提交的漢字。

　　●JSP/Servlet 數據庫讀寫無法獲得正確的內容。

　　隱藏在這些問題后面的是各種錯誤的字符轉換和處理（除第3個外，是因為 Java font 設置錯誤引起的）。解決類似的字符 encoding 問題，需要了解 Jsp/Servlet 的運行過程，檢查可能出現問題的各個點。

　　3.2 JSP/Servlet web 編程時的 encoding 問題

　　運行于Java 應用服務器的 JSP/Servlet 為 Browser 提供 HTML 內容，其過程如下圖所示：


　　其中有字符編碼轉換的地方有：

　　a.JSP 編譯。Java 應用服務器將根據 JVM 的 file.encoding 值讀取 JSP 源文件，并轉換為內部字符編碼進行 JSP 編譯，生成 JAVA 源文件，根據 file.encoding 值寫回文件系統。如果當前系統語言支持 GBK，那么這時候不會出現 encoding 問題。如果是英文的系統，如 LANG 是 en_US 的 Linux, AIX 或 Solaris，則要將 JVM 的 file.encoding 值置成 GBK 。系統語言如果是 GB2312，則根據需要，確定要不要設置 file.encoding，將 file.encoding 設為 GBK 可以解決潛在的 GBK 字符亂碼問題。

　　b.Java 需要被編譯為 .class 才能在 JVM 中執行，這個過程存在與a.同樣的 file.encoding 問題。從這里開始 servlet 和 jsp 的運行就類似了，只不過 Servlet 的編譯不是自動進行的。

　　c.Servlet 需要將 HTML 頁面內容轉換為 browser 可接受的 encoding 內容發送出去。依賴于各 JAVA App Server 的實現方式，有的將查詢 Browser 的 accept-charset 和 accept-language 參數或以其它猜的方式確定 encoding 值，有的則不管。因此 constant-encoding 也許是最好的解決方法。對于中文網頁，可在 JSP 或 Servlet 中設置 contentType="text/html; charset=GB2312"；如果頁面中有GBK字符，則設置為contentType="text/html; charset=GBK"，由于IE 和 Netscape對GBK的支持程度不一樣，作這種設置時需要測試一下。

　　因為16位 JAVA char在網絡傳送時高8位會被丟棄，也為了確保Servlet頁面中的漢字（包括內嵌的和servlet運行過程中得到的）是期望的內碼，可以用 PrintWriter out=res.getWriter() 取代 ServletOutputStream out=res.getOutputStream(), PrinterWriter 將根據contentType中指定的charset作轉換(ContentType需在此之前指定！);也可以用OutputStreamWriter封裝 ServletOutputStream 類并用write(String)輸出漢字字符串。

對于 JSP，JAVA Application Server 應當能夠確保在這個階段將嵌入的漢字正確傳送出去。

　　d.這是 URL 字符 encoding 問題。如果通過 get/post 方式從 browser 返回的值中包含漢字信息， servlet 將無法得到正確的值。SUN的 J2SDK 中，HttpUtils.parseName 在解析參數時根本沒有考慮 browser 的語言設置，而是將得到的值按 byte 方式解析。這是網上討論得最多的 encoding 問題。因為這是設計缺陷，只能以 bin 方式重新解析得到的字符串；或者以 hack HttpUtils 類的方式解決。參考文章 2、3 均有介紹，不過最好將其中的中文 encoding GB2312、 CP1381 都改為 GBK，否則遇到 GBK 漢字時，還是會有問題。

　　Servlet API 2.3 提供一個新的函數 HttpServeletRequest.setCharacterEncoding 用于在調用 request.getParameter(“param_name”) 前指定應用程序希望的 encoding，這將有助于徹底解決這個問題。

　　WebSphere Application Server 對標準的 Servlet API 2.x 作了擴展，提供較好的多語言支持。上述c,d情況，WAS 都要查詢 Browser 的語言設置，在缺省狀況下zh、zh-cn 等均被映射為 JAVA encoding CP1381（注意：CP1381 只是等同于 GB2312 的一個 codepage，沒有 GBK 支持）。這樣做我想是因為無法確認 Browser 運行的操作系統是支持GB2312, 還是 GBK，所以取其小。但是實際的應用系統還是要求頁面中出現 GBK 漢字，最著名的是朱總理名字中的“?”(rong2 ，0xe946，\u9555)，所以有時還是需要將 Encoding/Charset 指定為 GBK。當然 WAS 中變更缺省的 encoding 沒有上面說的那么麻煩，針對 a,b，參考文章 5 ），在 Application Server 的命令行參數中指定 -Dfile.encoding=GBK 即可； 針對 d，在 Application Server 的命令行參數中指定-Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那么c情況下可以不再指定charset。

　　3.3 數據庫讀寫時的 encoding 問題

　　JSP/Servlet 編程中經常出現 encoding 問題的另一個地方是讀寫數據庫中的數據。

　　流行的關系數據庫系統都支持數據庫 encoding，也就是說在創建數據庫時可以指定它自己的字符集設置，數據庫的數據以指定的編碼形式存儲。當應用程序訪問數據時，在入口和出口處都會有 encoding 轉換。對于中文數據，應當保證數據的完整性。GB2312，GBK，UTF-8 等都是可選的數據庫 encoding；如果選擇 ISO8859-1(8-bit SBCS)，那么應用程序在寫數據之前須將 16Bit 的一個漢字或 Unicode 拆分成兩個 8-bit 的字符，讀數據之后則需將兩個字節合并起來，同時還有判別其中的 SBCS 字符。沒有充分利用數據庫 encoding 的作用，反而增加了編程的復雜度，ISO8859-1不是推薦的數據庫 encoding。JSP/Servlet編程時，可以先用數據庫管理系統提供的功能檢查其中的中文數據是否正確。

　　然后應當注意的是讀出來的數據的 encoding，JAVA 程序中一般得到的是 Unicode。寫數據時則相反。

　　3.4 定位問題時常用的技巧

　　定位中文encoding問題通常采用最笨的也是最有效的辦法——在你認為有嫌疑的程序處理后打印字符串的內碼。通過打印字符串的內碼，你可以發現什么時候中文字符被轉換成Unicode，什么時候Unicode被轉回中文內碼，什么時候一個中文字成了兩個 Unicode 字符，什么時候中文字符串被轉成了一串問號，什么時候中文字符串的高位被截掉了……

　　取用合適的樣本字符串也有助于區分問題的類型。如：”aa啊aa?aa” 等中英相間、GB、GBK特征字符均有的字符串。一般來說，英文字符無論怎么轉換或處理，都不會失真（如果遇到了，可以嘗試著增加連續的英文字母長度）。

4.結束語
　　其實 JSP/Servlet 的中文encoding 并沒有想像的那么復雜，雖然定位和解決問題沒有定規，各種運行環境也各不盡然，但后面的原理是一樣的。了解字符集的知識是解決字符問題的基礎。不過，隨著中文字符集的變化，不僅僅是 java 編程，中文信息處理中的問題還是會存在一段時間的。

5.參考文章
1) Character Problem Review
2) Java 編程技術中漢字問題的分析及解決
3) NLS Characters in WebSphere: SBCS/DBCS display on same page
4) GB18030
5) Setting language encoding in web applications: Websphere applications Server
作者簡介
　　張建芳，軟件工程師，畢業于北京理工大學計算機應用學院，有多年中文本地化經驗。您可通過 jfzhang@usa.net 與他聯系。

　　

轉自IBM