深入分析 Java Web 中的中文編碼問題

　　背景：

　　編碼問題一直困擾著程式開發人員，尤其是在 Java 中更加明顯，因為 Java 是跨平臺的語言，在不同平臺的編碼之間的切換較多。接下來將介紹 Java 編碼問題出現的根本原因；在 Java 中經常遇到的幾種編碼格式的區別；在 Java 中經常需要編碼的場景；出現中文問題的原因分析；在開發 Java Web 中可能存在編碼的幾個地方；一個 HTTP 請求怎麼控制編碼格式；如何避免出現中文編碼問題等。

　　1、幾種常見的編碼格式

　　1.1 為什麼要編碼

• 在計算機中儲存資訊的最小單元是 1 個位元組，即 8 個 bit， 所以能表示的字元範圍是 0 ~ 255 個。
• 要表示的符號太多，無法用 1 個位元組來完全表示。

　　1.2 如何翻譯

　　計算機中提供多種翻譯方式，常見的有 ASCII、ISO-8859-1、GB2312、GBK、UTF-8、UTF-16等。這些都規定了轉化的規則，按照這個規則就可以讓計算機正確的表示我們的字元。下面介紹這幾種編碼格式：

• ASCII 碼

  總共有 128 個，用 1 個位元組的低 7 位表示， 0 ~ 31 是控制字元如換行、回車、刪除等，32 ~ 126 是列印字元，可以通過鍵盤輸入並且能夠顯示出來。

• ISO-8859-1

  128 個字元顯然是不夠用的，所以 ISO 組織在 ASCII 的基礎上擴充套件，他們是 ISO-8859-1 至 ISO-8859-15，前者涵蓋大多數字符，應用最廣。ISO-8859-1 仍是單位元組編碼，它總歸能表示 256 個字元。

• GB2312

  它是雙位元組編碼，總的編碼範圍是 A1 ~ F7，其中 A1 ~ A9 是符號區，總共包含 682 個符號；B0 ~ F7 是漢字區，包含 6763 個漢字。

• GBk

  GBK 為《漢字內碼擴充套件規範》，為 GB2312 的擴充套件，它的編碼範圍是 8140 ~ FEFE（去掉XX7F），總共有 23940 個碼位，能表示 21003 個漢字，和 GB2312的編碼相容，不會有亂碼。

• UTF-16

  它具體定義了 Unicode 字元在計算機中的存取方法。UTF-16 用兩個位元組來表示 Unicode 的轉化格式，它採用定長的表示方法，即不論什麼字元用兩個位元組表示。兩個位元組是 16 個 bit，所以叫 UTF-16。它表示字元非常方便，沒兩個位元組表示一個字元，這就大大簡化了字串操作。

• UTF-8

  雖說 UTF-16 統一採用兩個位元組表示一個字元很簡單方便，但是很大一部分字元用一個位元組就可以表示，如果用兩個位元組表示，儲存空間放大了一倍，在網路頻寬有限的情況下會增加網路傳輸的流量。UTF-8 採用了一種變長技術，每個編碼區域有不同的字碼長度不同型別的字元可以由 1 ~ 6 個位元組組成。

  UTF-8 有以下編碼規則：

  • 如果是 1 個位元組，最高位（第 8 位）為 0，則表示這是一個 ASCII 字元（00 ~ 7F）
  • 如果是 1 個位元組，以 11 開頭，則連續的 1 的個數暗示這個字元的位元組數
  • 如果是 1 個位元組，以 10 開頭，表示它不是首位元組，則需要向前查詢才能得到當前字元的首位元組

  ​

　　2、在 Java 中需要編碼的場景

　　2.1 在 I/O 操作中存在的編碼

　　如上圖：Reader 類是在 Java 的 I/O 中讀取符的父類，而 InputStream 類是讀位元組的父類， InputStreamReader 類就是關聯位元組到字元的橋樑，它負責在 I/O 過程中處理讀取位元組到字元的轉換，而對具體位元組到字元的解碼實現，它又委託 StreamDecoder 去做，在 StreamDecoder 解碼過程中必須由使用者指定 Charset 編碼格式。值得注意的是，如果你沒有指定 Charset，則將使用本地環境中預設的字符集，如在中文環境中將使用 GBK 編碼。

　　如下面一段程式碼，實現了檔案的讀寫功能：

 String file = "c:/stream.txt"; 
 String charset = "UTF-8"; 
 // 寫字元換轉成位元組流
 FileOutputStream outputStream = new FileOutputStream(file); 
 OutputStreamWriter writer = new OutputStreamWriter( 
 outputStream, charset); 
 try { 
    writer.write("這是要儲存的中文字元"); 
 } finally { 
    writer.close(); 
 } 
 // 讀取位元組轉換成字元
 FileInputStream inputStream = new FileInputStream(file); 
 InputStreamReader reader = new InputStreamReader( 
 inputStream, charset); 
 StringBuffer buffer = new StringBuffer(); 
 char[] buf = new char[64]; 
 int count = 0; 
 try { 
    while ((count = reader.read(buf)) != -1) { 
        buffer.append(buffer, 0, count); 
    } 
 } finally { 
    reader.close(); 
 }

　　在我們的應用程式中涉及 I/O 操作時，只要注意指定統一的編解碼 Charset 字符集，一般不會出現亂碼問題。

　　2.2 在記憶體操作中的編碼

　　在記憶體中進行從字元到位元組的資料型別轉換。

　　1、String 類提供字串轉換到位元組的方法，也支援將位元組轉換成字串的建構函式。

String s  = "字串"；
byte[] b = s.getBytes("UTF-8");
String n = new String(b, "UTF-8");

　　2、Charset 提供 encode 與 decode，分別對應 char[] 到 byte[] 的編碼 和 byte[] 到 char[] 的解碼。

Charset charset = Charset.forName("UTF-8");
ByteBuffer byteBuffer = charset.encode(string);
CharBuffer charBuffer = charset.decode(byteBuffer);

　　...

　　3、在 Java 中如何編解碼

　　Java 編碼類圖

　　首先根據指定的 charsetName 通過 Charset.forName(charsetName) 設定 Charset 類，然後根據 Charset 建立 CharsetEncoder 物件，再呼叫 CharsetEncoder.encode 對字串進行編碼，不同的編碼型別都會對應到一個類中，實際的編碼過程是在這些類中完成的。下面是 String. getBytes(charsetName) 編碼過程的時序圖

　　Java 編碼時序圖

　　從上圖可以看出根據 charsetName 找到 Charset 類，然後根據這個字符集編碼生成 CharsetEncoder，這個類是所有字元編碼的父類，針對不同的字元編碼集在其子類中定義瞭如何實現編碼，有了 CharsetEncoder 物件後就可以呼叫 encode 方法去實現編碼了。這個是 String.getBytes 編碼方法，其它的如 StreamEncoder 中也是類似的方式。

　　經常會出現中文變成“？”很可能就是錯誤的使用了 ISO-8859-1 這個編碼導致的。中文字元經過 ISO-8859-1 編碼會丟失資訊，通常我們稱之為“黑洞”，它會把不認識的字元吸收掉。由於現在大部分基礎的 Java 框架或系統預設的字符集編碼都是 ISO-8859-1，所以很容易出現亂碼問題，後面將會分析不同的亂碼形式是怎麼出現的。

　　幾種編碼格式的比較

　　對中文字元後面四種編碼格式都能處理，GB2312 與 GBK 編碼規則類似，但是 GBK 範圍更大，它能處理所有漢字字元，所以 GB2312 與 GBK 比較應該選擇 GBK。UTF-16 與 UTF-8 都是處理 Unicode 編碼，它們的編碼規則不太相同，相對來說 UTF-16 編碼效率最高，字元到位元組相互轉換更簡單，進行字串操作也更好。它適合在本地磁碟和記憶體之間使用，可以進行字元和位元組之間快速切換，如 Java 的記憶體編碼就是採用 UTF-16 編碼。但是它不適合在網路之間傳輸，因為網路傳輸容易損壞位元組流，一旦位元組流損壞將很難恢復，想比較而言 UTF-8 更適合網路傳輸，對 ASCII 字元采用單位元組儲存，另外單個字元損壞也不會影響後面其它字元，在編碼效率上介於 GBK 和 UTF-16 之間，所以 UTF-8 在編碼效率上和編碼安全性上做了平衡，是理想的中文編碼方式。

　　4、在 Java Web 中涉及的編解碼

　　對於使用中文來說，有 I/O 的地方就會涉及到編碼，前面已經提到了 I/O 操作會引起編碼，而大部分 I/O 引起的亂碼都是網路 I/O，因為現在幾乎所有的應用程式都涉及到網路操作，而資料經過網路傳輸都是以位元組為單位的，所以所有的資料都必須能夠被序列化為位元組。在 Java 中資料被序列化必須繼承 Serializable 介面。

　　一段文字它的實際大小應該怎麼計算，我曾經碰到過一個問題：就是要想辦法壓縮 Cookie 大小，減少網路傳輸量，當時有選擇不同的壓縮演算法，發現壓縮後字元數是減少了，但是並沒有減少位元組數。所謂的壓縮只是將多個單位元組字元通過編碼轉變成一個多位元組字元。減少的是 String.length()，而並沒有減少最終的位元組數。例如將“ab”兩個字元通過某種編碼轉變成一個奇怪的字元，雖然字元數從兩個變成一個，但是如果採用 UTF-8 編碼這個奇怪的字元最後經過編碼可能又會變成三個或更多的位元組。同樣的道理比如整型數字 1234567 如果當成字元來儲存，採用 UTF-8 來編碼佔用 7 個 byte，採用 UTF-16 編碼將會佔用 14 個 byte，但是把它當成 int 型數字來儲存只需要 4 個 byte 來儲存。所以看一段文字的大小，看字元本身的長度是沒有意義的，即使是一樣的字元采用不同的編碼最終儲存的大小也會不同，所以從字元到位元組一定要看編碼型別。

　　我們能夠看到的漢字都是以字元形式出現的，例如在 Java 中“淘寶”兩個字元，它在計算機中的數值 10 進位制是 28120 和 23453，16 進位制是 6bd8 和 5d9d，也就是這兩個字元是由這兩個數字唯一表示的。Java 中一個 char 是 16 個 bit 相當於兩個位元組，所以兩個漢字用 char 表示在記憶體中佔用相當於四個位元組的空間。

　　這兩個問題搞清楚後，我們看一下 Java Web 中那些地方可能會存在編碼轉換？

　　使用者從瀏覽器端發起一個 HTTP 請求，需要存在編碼的地方是 URL、Cookie、Parameter。伺服器端接受到 HTTP 請求後要解析 HTTP 協議，其中 URI、Cookie 和 POST 表單引數需要解碼，伺服器端可能還需要讀取資料庫中的資料，本地或網路中其它地方的文字檔案，這些資料都可能存在編碼問題，當 Servlet 處理完所有請求的資料後，需要將這些資料再編碼通過 Socket 傳送到使用者請求的瀏覽器裡，再經過瀏覽器解碼成為文字。這些過程如下圖所示：

　　一次 HTTP 請求的編碼示例

　　4.1 URL 的編解碼

　　使用者提交一個 URL，這個 URL 中可能存在中文，因此需要編碼，如何對這個 URL 進行編碼？根據什麼規則來編碼？有如何來解碼？如下圖一個 URL：

　　上圖中以 Tomcat 作為 Servlet Engine 為例，它們分別對應到下面這些配置檔案中：

　　Port 對應在 Tomcat 的 <Connector port="8080"/> 中配置，而 Context Path 在 <Context path="/examples"/> 中配置，Servlet Path 在 Web 應用的 web.xml 中的

<servlet-mapping> 
        <servlet-name>junshanExample</servlet-name> 
        <url-pattern>/servlets/servlet/*</url-pattern> 
 </servlet-mapping>

　　<url-pattern> 中配置，PathInfo 是我們請求的具體的 Servlet，QueryString 是要傳遞的引數，注意這裡是在瀏覽器裡直接輸入 URL 所以是通過 Get 方法請求的，如果是 POST 方法請求的話，QueryString 將通過表單方式提交到伺服器端。

　　上圖中 PathInfo 和 QueryString 出現了中文，當我們在瀏覽器中直接輸入這個 URL 時，在瀏覽器端和服務端會如何編碼和解析這個 URL 呢？為了驗證瀏覽器是怎麼編碼 URL 的我選擇的是360極速瀏覽器並通過 Postman 外掛觀察我們請求的 URL 的實際的內容，以下是 URL：

　　HTTP://localhost:8080/examples/servlets/servlet/君山?author=君山

　　君山的編碼結果是：e5 90 9b e5 b1 b1，和《深入分析 Java Web 技術內幕》中的結果不一樣，這是因為我使用的瀏覽器和外掛和原作者是有區別的，那麼這些瀏覽器之間的預設編碼是不一樣的，原文中的結果是：

　　君山的編碼結果分別是：e5 90 9b e5 b1 b1，be fd c9 bd，查閱上一屆的編碼可知，PathInfo 是 UTF-8 編碼而 QueryString 是經過 GBK 編碼，至於為什麼會有“%”？查閱 URL 的編碼規範 RFC3986 可知瀏覽器編碼 URL 是將非 ASCII 字元按照某種編碼格式編碼成 16 進位制數字然後將每個 16 進製表示的位元組前加上“%”，所以最終的 URL 就成了上圖的格式了。

　　從上面測試結果可知瀏覽器對 PathInfo 和 QueryString 的編碼是不一樣的，不同瀏覽器對 PathInfo 也可能不一樣，這就對伺服器的解碼造成很大的困難，下面我們以 Tomcat 為例看一下，Tomcat 接受到這個 URL 是如何解碼的。

　　解析請求的 URL 是在 org.apache.coyote.HTTP11.InternalInputBuffer 的 parseRequestLine 方法中，這個方法把傳過來的 URL 的 byte[] 設定到 org.apache.coyote.Request 的相應的屬性中。這裡的 URL 仍然是 byte 格式，轉成 char 是在 org.apache.catalina.connector.CoyoteAdapter 的 convertURI 方法中完成的：

protected void convertURI(MessageBytes uri, Request request) 
 throws Exception { 
        ByteChunk bc = uri.getByteChunk(); 
        int length = bc.getLength(); 
        CharChunk cc = uri.getCharChunk(); 
        cc.allocate(length, -1); 
        String enc = connector.getURIEncoding(); 
        if (enc != null) { 
            B2CConverter conv = request.getURIConverter(); 
            try { 
                if (conv == null) { 
                    conv = new B2CConverter(enc); 
                    request.setURIConverter(conv); 
                } 
            } catch (IOException e) {...} 
            if (conv != null) { 
                try { 
                    conv.convert(bc, cc, cc.getBuffer().length - 
 cc.getEnd()); 
                    uri.setChars(cc.getBuffer(), cc.getStart(), 
 cc.getLength()); 
                    return; 
                } catch (IOException e) {...} 
            } 
        } 
        // Default encoding: fast conversion 
        byte[] bbuf = bc.getBuffer(); 
        char[] cbuf = cc.getBuffer(); 
        int start = bc.getStart(); 
        for (int i = 0; i < length; i++) { 
            cbuf[i] = (char) (bbuf[i + start] & 0xff); 
        } 
        uri.setChars(cbuf, 0, length); 
 }

　　從上面的程式碼中可以知道對 URL 的 URI 部分進行解碼的字符集是在 connector 的 <Connector URIEncoding=”UTF-8”/> 中定義的，如果沒有定義，那麼將以預設編碼 ISO-8859-1 解析。所以如果有中文 URL 時最好把 URIEncoding 設定成 UTF-8 編碼。

　　QueryString 又如何解析？ GET 方式 HTTP 請求的 QueryString 與 POST 方式 HTTP 請求的表單引數都是作為 Parameters 儲存，都是通過 request.getParameter 獲取引數值。對它們的解碼是在 request.getParameter 方法第一次被呼叫時進行的。request.getParameter 方法被呼叫時將會呼叫 org.apache.catalina.connector.Request 的 parseParameters 方法。這個方法將會對 GET 和 POST 方式傳遞的引數進行解碼，但是它們的解碼字符集有可能不一樣。POST 表單的解碼將在後面介紹，QueryString 的解碼字符集是在哪定義的呢？它本身是通過 HTTP 的 Header 傳到服務端的，並且也在 URL 中，是否和 URI 的解碼字符集一樣呢？從前面瀏覽器對 PathInfo 和 QueryString 的編碼採取不同的編碼格式不同可以猜測到解碼字符集肯定也不會是一致的。的確是這樣 QueryString 的解碼字符集要麼是 Header 中 ContentType 中定義的 Charset 要麼就是預設的 ISO-8859-1，要使用 ContentType 中定義的編碼就要設定 connector 的 <Connector URIEncoding=”UTF-8” useBodyEncodingForURI=”true”/> 中的 useBodyEncodingForURI 設定為 true。這個配置項的名字有點讓人產生混淆，它並不是對整個 URI 都採用 BodyEncoding 進行解碼而僅僅是對 QueryString 使用 BodyEncoding 解碼，這一點還要特別注意。

　　從上面的 URL 編碼和解碼過程來看，比較複雜，而且編碼和解碼並不是我們在應用程式中能完全控制的，所以在我們的應用程式中應該儘量避免在 URL 中使用非 ASCII 字元，不然很可能會碰到亂碼問題，當然在我們的伺服器端最好設定 <Connector/> 中的 URIEncoding 和 useBodyEncodingForURI 兩個引數。

　　4.2 HTTP Header 的編解碼

　　當客戶端發起一個 HTTP 請求除了上面的 URL 外還可能會在 Header 中傳遞其它引數如 Cookie、redirectPath 等，這些使用者設定的值很可能也會存在編碼問題，Tomcat 對它們又是怎麼解碼的呢？

　　對 Header 中的項進行解碼也是在呼叫 request.getHeader 是進行的，如果請求的 Header 項沒有解碼則呼叫 MessageBytes 的 toString 方法，這個方法將從 byte 到 char 的轉化使用的預設編碼也是 ISO-8859-1，而我們也不能設定 Header 的其它解碼格式，所以如果你設定　Header 中有非 ASCII 字元解碼肯定會有亂碼。

　　我們在新增 Header 時也是同樣的道理，不要在 Header 中傳遞非 ASCII 字元，如果一定要傳遞的話，我們可以先將這些字元用 org.apache.catalina.util.URLEncoder 編碼然後再新增到 Header 中，這樣在瀏覽器到伺服器的傳遞過程中就不會丟失資訊了，如果我們要訪問這些項時再按照相應的字符集解碼就好了。

　　4.3 POST 表單的編解碼

　　在前面提到了 POST 表單提交的引數的解碼是在第一次呼叫 request.getParameter 發生的，POST 表單引數傳遞方式與 QueryString 不同，它是通過 HTTP 的 BODY 傳遞到服務端的。當我們在頁面上點選 submit 按鈕時瀏覽器首先將根據 ContentType 的 Charset 編碼格式對錶單填的引數進行編碼然後提交到伺服器端，在伺服器端同樣也是用 ContentType 中字符集進行解碼。所以通過 POST 表單提交的引數一般不會出現問題，而且這個字符集編碼是我們自己設定的，可以通過 request.setCharacterEncoding(charset) 來設定。

　　另外針對 multipart/form-data 型別的引數，也就是上傳的檔案編碼同樣也是使用 ContentType 定義的字符集編碼，值得注意的地方是上傳檔案是用位元組流的方式傳輸到伺服器的本地臨時目錄，這個過程並沒有涉及到字元編碼，而真正編碼是在將檔案內容新增到 parameters 中，如果用這個編碼不能編碼時將會用預設編碼 ISO-8859-1 來編碼。

　　4.4 HTTP BODY 的編解碼

　　當使用者請求的資源已經成功獲取後，這些內容將通過 Response 返回給客戶端瀏覽器，這個過程先要經過編碼再到瀏覽器進行解碼。這個過程的編解碼字符集可以通過 response.setCharacterEncoding 來設定，它將會覆蓋 request.getCharacterEncoding 的值，並且通過 Header 的 Content-Type 返回客戶端，瀏覽器接受到返回的 socket 流時將通過 Content-Type 的 charset 來解碼，如果返回的 HTTP Header 中 Content-Type 沒有設定 charset，那麼瀏覽器將根據 Html 的 <meta HTTP-equiv="Content-Type" content="text/html; charset=GBK" /> 中的 charset 來解碼。如果也沒有定義的話，那麼瀏覽器將使用預設的編碼來解碼。

　　4.5 其它需要編碼的地方

　　除了 URL 和引數編碼問題外，在服務端還有很多地方可能存在編碼，如可能需要讀取 xml、velocity 模版引擎、JSP 或者從資料庫讀取資料等。
xml 檔案可以通過設定頭來制定編碼格式

<?xml version="1.0" encoding="UTF-8"?>

　　Velocity 模版設定編碼格式：

services.VelocityService.input.encoding=UTF-8

　　JSP 設定編碼格式：

 <%@page contentType="text/html; charset=UTF-8"%>

　　訪問資料庫都是通過客戶端 JDBC 驅動來完成，用 JDBC 來存取資料要和資料的內建編碼保持一致，可以通過設定 JDBC URL 來制定如 MySQL：url="jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=GBK"。

　　5、常見問題分析

　　下面看一下，當我們碰到一些亂碼時，應該怎麼處理這些問題？出現亂碼問題唯一的原因都是在 char 到 byte 或 byte 到 char 轉換中編碼和解碼的字符集不一致導致的，由於往往一次操作涉及到多次編解碼，所以出現亂碼時很難查詢到底是哪個環節出現了問題，下面就幾種常見的現象進行分析。

　　5.1 中文變成了看不懂的字元

　　例如，字串“淘！我喜歡！”變成了“Ì Ô £ ¡Î Ò Ï²»¶ £ ¡”編碼過程如下圖所示：

　　字串在解碼時所用的字符集與編碼字符集不一致導致漢字變成了看不懂的亂碼，而且是一個漢字字元變成兩個亂碼字元。

　　5.2 一個漢字變成一個問號

　　例如，字串“淘！我喜歡！”變成了“？？？？？？”編碼過程如下圖所示:

　　將中文和中文符號經過不支援中文的 ISO-8859-1 編碼後，所有字元變成了“？”，這是因為用 ISO-8859-1 進行編解碼時遇到不在碼值範圍內的字元時統一用 3f 表示，這也就是通常所說的“黑洞”，所有 ISO-8859-1 不認識的字元都變成了“？”。

　　5.3 一個漢字變成兩個問號

　　例如，字串“淘！我喜歡！”變成了“？？？？？？？？？？？？”編碼過程如下圖所示:

　　這種情況比較複雜，中文經過多次編碼，但是其中有一次編碼或者解碼不對仍然會出現中文字元變成“？”現象，出現這種情況要仔細檢視中間的編碼環節，找出出現編碼錯誤的地方。

　　5.4 一種不正常的正確編碼

　　還有一種情況是在我們通過 request.getParameter 獲取引數值時，當我們直接呼叫

　　String value = request.getParameter(name); 會出現亂碼，但是如果用下面的方式

　　String value = String(request.getParameter(name).getBytes(" ISO-8859-1"), "GBK");

　　解析時取得的 value 會是正確的漢字字元，這種情況是怎麼造成的呢？

　　看下如所示：

　　這種情況是這樣的，ISO-8859-1 字符集的編碼範圍是 0000-00FF，正好和一個位元組的編碼範圍相對應。這種特性保證了使用 ISO-8859-1 進行編碼和解碼可以保持編碼數值“不變”。雖然中文字元在經過網路傳輸時，被錯誤地“拆”成了兩個歐洲字元，但由於輸出時也是用 ISO-8859-1，結果被“拆”開的中文字的兩半又被合併在一起，從而又剛好組成了一個正確的漢字。雖然最終能取得正確的漢字，但是還是不建議用這種不正常的方式取得引數值，因為這中間增加了一次額外的編碼與解碼，這種情況出現亂碼時因為 Tomcat 的配置檔案中 useBodyEncodingForURI 配置項沒有設定為”true”，從而造成第一次解析式用 ISO-8859-1 來解析才造成亂碼的。

　　6、總結

　　本文首先總結了幾種常見編碼格式的區別，然後介紹了支援中文的幾種編碼格式，並比較了它們的使用場景。接著介紹了 Java 那些地方會涉及到編碼問題，已經 Java 中如何對編碼的支援。並以網路 I/O 為例重點介紹了 HTTP 請求中的存在編碼的地方，以及 Tomcat 對 HTTP 協議的解析，最後分析了我們平常遇到的亂碼問題出現的原因。

　　綜上所述，要解決中文問題，首先要搞清楚哪些地方會引起字元到位元組的編碼以及位元組到字元的解碼，最常見的地方就是讀取會儲存資料到磁碟，或者資料要經過網路傳輸。然後針對這些地方搞清楚操作這些資料的框架的或系統是如何控制編碼的，正確設定編碼格式，避免使用軟體預設的或者是作業系統平臺預設的編碼格式。

　　註明：文章大部分參考書籍《深入 Java Web 技術內幕》第三章，自己有刪減，二次轉載請也務必註明此出處。