JSP/Servlet 中的漢字編碼問題

js|servlet|編碼|漢字|問題 網上就 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 編程，中文資訊處理中的問題還是會存在一段時間的。