給出如下結論：
在Class輸出字符串前，會將Unicode的字符串按照某一種內碼重新生成字節流，然后把字節流輸入，相當于進行了一步“String.getBytes(???)”操作。???代表某一種字符集。
如果是Servlet，那么，這種內碼就是在HttpServletResponse.setContentType()方法中指定的內碼，也就是上文定義的＜Servlet-charset＞。
如果是JSP，那么，這種內碼就是在＜%@ page contentType=""%＞中指定的內碼，也就是上文定義的＜Jsp-charset＞。
如果是Java程序，那么，這種內碼就是file.encoding中指定的內碼，默認為ISO8859-1。
當輸出對象是瀏覽器時
以流行的瀏覽器IE為例。IE支持多種內碼。假如IE接收到了一個字節流“D6 D0 CE C4”，你可以嘗試用各種內碼去查看。你會發現用“簡體中文”時能得到正確的結果。因為“D6 D0 CE C4”本來就是簡體中文中“中文”兩個字的編碼。
OK，完整地看一遍。
JSP：源文件為GB2312格式的文本文件，且JSP源文件中有“中文”這兩個漢字
如果指定了＜Jsp-charset＞為GB2312，轉化過程如下表。
表4 Jsp-charset = GB2312時的變化過程
| 序號 |
步驟說明 |
結果 |
| 1 |
編寫JSP源文件，且存為GB2312格式 |
D6 D0 CE C4
（D6D0=中 CEC4=文） |
| 2 |
jspc把JSP源文件轉化為臨時JAVA文件，并把字符串按照GB2312映射到Unicode，并用UTF格式寫入JAVA文件中 |
E4 B8 AD E6 96 87 |
| 3 |
把臨時JAVA文件編譯成CLASS文件 |
E4 B8 AD E6 96 87 |
| 4 |
運行時，先從CLASS文件中用readUTF讀出字符串，在內存中的是Unicode編碼 |
4E 2D 65 87（在Unicode中4E2D=中 6587=文） |
| 5 |
根據Jsp-charset=GB2312把Unicode轉化為字節流 |
D6 D0 CE C4 |
| 6 |
把字節流輸出到IE中，并設置IE的編碼為GB2312（作者按：這個信息隱藏在HTTP頭中） |
D6 D0 CE C4 |
| 7 |
IE用“簡體中文”查看結果 |
“中文”（正確顯示） |
如果指定了＜Jsp-charset＞為ISO8859-1，轉化過程如下表。
表5 Jsp-charset = ISO8859-1時的變化過程
| 序號 |
步驟說明 |
結果 |
| 1 |
編寫JSP源文件，且存為GB2312格式 |
D6 D0 CE C4
（D6D0=中 CEC4=文） |
| 2 |
jspc把JSP源文件轉化為臨時JAVA文件，并把字符串按照ISO8859-1映射到Unicode，并用UTF格式寫入JAVA文件中 |
C3 96 C3 90 C3 8E C3 84 |
| 3 |
把臨時JAVA文件編譯成CLASS文件 |
C3 96 C3 90 C3 8E C3 84 |
| 4 |
運行時，先從CLASS文件中用readUTF讀出字符串，在內存中的是Unicode編碼 |
00 D6 00 D0 00 CE 00 C4
（啥都不是！！！） |
| 5 |
根據Jsp-charset=ISO8859-1把Unicode轉化為字節流 |
D6 D0 CE C4 |
| 6 |
把字節流輸出到IE中，并設置IE的編碼為ISO8859-1（作者按：這個信息隱藏在HTTP頭中） |
D6 D0 CE C4 |
| 7 |
IE用“西歐字符”查看結果 |
亂碼，其實是四個ASCII字符，但由于大于128，所以顯示出來的怪模怪樣 |
| 8 |
改變IE的頁面編碼為“簡體中文” |
“中文”（正確顯示） |
奇怪了！為什么把＜Jsp-charset＞設成GB2312和ISO8859-1是一個樣的，都能正確顯示？因為表4表5中的第2步和第5步互逆，是相互“抵消”的。只不過當指定為ISO8859-1時，要增加第8步操作，殊為不便。
再看看不指定＜Jsp-charset＞ 時的情況。
表6 未指定Jsp-charset 時的變化過程
| 序號 |
步驟說明 |
結果 |
| 1 |
編寫JSP源文件，且存為GB2312格式 |
D6 D0 CE C4
（D6D0=中 CEC4=文） |
| 2 |
jspc把JSP源文件轉化為臨時JAVA文件，并把字符串按照ISO8859-1映射到Unicode，并用UTF格式寫入JAVA文件中 |
C3 96 C3 90 C3 8E C3 84 |
| 3 |
把臨時JAVA文件編譯成CLASS文件 |
C3 96 C3 90 C3 8E C3 84 |
| 4 |
運行時，先從CLASS文件中用readUTF讀出字符串，在內存中的是Unicode編碼 |
00 D6 00 D0 00 CE 00 C4 |
| 5 |
根據Jsp-charset=ISO8859-1把Unicode轉化為字節流 |
D6 D0 CE C4 |
| 6 |
把字節流輸出到IE中 |
D6 D0 CE C4 |
| 7 |
IE用發出請求時的頁面的編碼查看結果 |
視情況而定。如果是簡體中文，則能正確顯示，否則，需執行表5中的第8步 |
Servlet：源文件為JAVA文件，格式是GB2312，源文件中含有“中文”這兩個漢字
如果＜Compile-charset＞＝GB2312，＜Servlet-charset＞=GB2312
表7 Compile-charset=Servlet-charset=GB2312 時的變化過程
| 序號 |
步驟說明 |
結果 |
| 1 |
編寫Servlet源文件，且存為GB2312格式 |
D6 D0 CE C4
（D6D0=中 CEC4=文） |
| 2 |
用javac –encoding GB2312把JAVA源文件編譯成CLASS文件 |
E4 B8 AD E6 96 87 （UTF） |
| 3 |
運行時，先從CLASS文件中用readUTF讀出字符串，在內存中的是Unicode編碼 |
4E 2D 65 87 (Unicode) |
| 4 |
根據Servlet-charset=GB2312把Unicode轉化為字節流 |
D6 D0 CE C4 (GB2312) |
| 5 |
把字節流輸出到IE中并設置IE的編碼屬性為Servlet-charset=GB2312 |
D6 D0 CE C4 (GB2312) |
| 6 |
IE用“簡體中文”查看結果 |
“中文”（正確顯示） |
如果＜Compile-charset＞＝ISO8859-1，＜Servlet-charset＞=ISO8859-1
表8 Compile-charset=Servlet-charset=ISO8859-1時的變化過程
| 序號 |
步驟說明 |
結果 |
| 1 |
編寫Servlet源文件，且存為GB2312格式 |
D6 D0 CE C4
（D6D0=中 CEC4=文） |
| 2 |
用javac –encoding ISO8859-1把JAVA源文件編譯成CLASS文件 |
C3 96 C3 90 C3 8E C3 84 （UTF） |
| 3 |
運行時，先從CLASS文件中用readUTF讀出字符串，在內存中的是Unicode編碼 |
00 D6 00 D0 00 CE 00 C4 |
| 4 |
根據Servlet-charset=ISO8859-1把Unicode轉化為字節流 |
D6 D0 CE C4 |
| 5 |
把字節流輸出到IE中并設置IE的編碼屬性為Servlet-charset=ISO8859-1 |
D6 D0 CE C4 (GB2312) |
| 6 |
IE用“西歐字符”查看結果 |
亂碼（原因同表5） |
| 7 |
改變IE的頁面編碼為“簡體中文” |
“中文”（正確顯示） |
如果不指定Compile-charset或Servlet-charset，其默認值均為ISO8859-1。
當Compile-charset=Servlet-charset時，第2步和第4步能互逆，“抵消”，顯示結果均能正確。讀者可試著寫一下Compile-charset＜＞Servlet-charset時的情況，肯定是不正確的。
當輸出對象是數據庫時
輸出到數據庫時，原理與輸出到瀏覽器也是一樣的。本節只是Servlet為例，JSP的情況請讀者自行推導。
假設有一個Servlet，它能接收來自客戶端（IE，簡體中文）的漢字字符串，然后把它寫入到內碼為ISO8859-1的數據庫中，然后再從數據庫中取出這個字符串，顯示到客戶端。
表9 輸出對象是數據庫時的變化過程（1）
| 序號 |
步驟說明 |
結果 |
域 |
| 1 |
在IE中輸入“中文” |
D6 D0 CE C4 |
IE |
| 2 |
IE把字符串轉變成UTF，并送入傳輸流中 |
E4 B8 AD E6 96 87 |
| 3 |
Servlet接收到輸入流，用readUTF讀取 |
4E 2D 65 87(unicode) |
Servlet |
| 4 |
編程者在Servlet中必須把字符串根據GB2312還原為字節流 |
D6 D0 CE C4 |
| 5 |
編程者根據數據庫內碼ISO8859-1生成新的字符串 |
00 D6 00 D0 00 CE 00 C4 |
| 6 |
把新生成的字符串提交給JDBC |
00 D6 00 D0 00 CE 00 C4 |
| 7 |
JDBC檢測到數據庫內碼為ISO8859-1 |
00 D6 00 D0 00 CE 00 C4 |
JDBC |
| 8 |
JDBC把接收到的字符串按照ISO8859-1生成字節流 |
D6 D0 CE C4 |
| 9 |
JDBC把字節流寫入數據庫中 |
D6 D0 CE C4 |
| 10 |
完成數據存儲工作 |
D6 D0 CE C4 數據庫 |
|
以下是從數據庫中取出數的過程 |
| 11 |
JDBC從數據庫中取出字節流 |
D6 D0 CE C4 |
JDBC |
| 12 |
JDBC按照數據庫的字符集ISO8859-1生成字符串，并提交給Servlet |
00 D6 00 D0 00 CE 00 C4 (Unicode) |
|
| 13 |
Servlet獲得字符串 |
00 D6 00 D0 00 CE 00 C4 (Unicode) |
Servlet |
| 14 |
編程者必須根據數據庫的內碼ISO8859-1還原成原始字節流 |
D6 D0 CE C4 |
|
| 15 |
編程者必須根據客戶端字符集GB2312生成新的字符串 |
4E 2D 65 87
（Unicode） |
|
|
Servlet準備把字符串輸出到客戶端 |
| 16 |
Servlet根據＜Servlet-charset＞生成字節流 |
D6D0 CE C4 |
Servlet |
| 17 |
Servlet把字節流輸出到IE中，如果已指定＜Servlet-charset＞，還會設置IE的編碼為＜Servlet-charset＞ |
D6 D0 CE C4 |
| 18 |
IE根據指定的編碼或默認編碼查看結果 |
“中文”（正確顯示） |
IE |
解釋一下，表中第4第5步和第15第16步是用紅色標記的，表示要由編碼者來作轉換。第4、5兩步其實就是一句話：“new String(source.getBytes("GB2312"), "ISO8859-1")”。第15、16兩步也是一句話：“new String(source.getBytes("ISO8859-1"), "GB2312")”。親愛的讀者，你在這樣編寫代碼時是否意識到了其中的每一個細節呢？
至于客戶端內碼和數據庫內碼為其它值時的流程，和輸出對象是系統控制臺時的流程，請讀者自己想吧。明白了上述流程的原理，相信你可以輕松地寫出來。
行文至此，已可告一段落了。終點又回到了起點，對于編程者而言，幾乎是什么影響都沒有。
因為我們早就被告之要這么做了。
以下給出一個結論，作為結尾。
1、 在Jsp文件中，要指定contentType，其中，charset的值要與客戶端瀏覽器所用的字符集一樣；對于其中的字符串常量，不需做任何內碼轉換；對于字符串變量，要求能根據ContentType中指定的字符集還原成客戶端能識別的字節流，簡單地說，就是“字符串變量是基于＜Jsp-charset＞字符集的”；
2、 在Servlet中，必須用HttpServletResponse.setContentType()設置charset，且設置成與客戶端內碼一致；對于其中的字符串常量，需要在Javac編譯時指定encoding，這個encoding必須與編寫源文件的平臺的字符集一樣，一般說來都是GB2312或GBK；對于字符串變量，與JSP一樣，必須“是基于＜Servlet-charset＞字符集的”。
出處: CSDN
責任編輯: 方舟