網上就 JSP/Servlet 中 DBCS 字符編碼問題有許多優秀的文章和討論，本文對它們作一些整理，並結合 IBM WebSphere Application Server 3.5（WAS）的解決方法作一些說明，希望它不是多余的。
內容：
問題的起源
GB2312-80，GBK，GB18030-2000 漢字字符集及 Encoding
中文轉碼時′?′、亂碼的由來
JSP/Servlet 漢字編碼問題及在 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 漢字字符集及 Encoding
其實解決 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 的支持，這是現階段和將來漢化的工作內容。
Unicode 的介紹......就免了吧。
JAVA 支持的encoding中與中文編程相關的有：(有幾個在JDK文檔中未列出)
ASCII 7-bit, 同 ascii7
