Java servlet 使用 PrintWriter 時的編碼與亂碼轉

在前面的網頁中的編碼與亂碼系列中（一、二、三、四、五），曾多次提到使用 servlet 方式構建的動態響應流，不過在那裏都是直接使用字節流的方式，不過，更爲常見的方式是使用字符流。而在前面，又談到了 Java 字節流與字符流的話題（一、二、三、四）。

有了前面的基礎，現在來說下 Java servlet 中使用字符流，也即是 PrintWriter 時的編碼與亂碼問題。

回顧字節流的情形

先回顧一下，在之前的字節流響應中，我們使用 String.getBytes 方法，然後總是顯式傳入編碼的參數，使它與 meta 中或者 header 的聲明一致。比如這樣：

或者這樣：

只要保持了一致，就不用擔心發生亂碼的問題。

使用 PrintWriter 字符流，缺省編碼

現在假如使用 PrintWriter 來作爲響應呢？比如這樣：

代碼中並沒有顯式傳入什麼編碼的參數，不像 String.getBytes 那樣。另一方面，我們知道，字符流最終還是要轉換成字節流，可是它到底使用了什麼編碼呢？是不是 Charset.defaultCharset 中的值呢？

就以上述代碼爲例，假如現在在瀏覽器中查看，會發現結果是這樣的：

可見 defaultCharset 缺省是 utf-8，前面說過，這其實來自於啓動 tomcat server 時所傳入的參數 –Dfile.encoding，（見前面篇章 Java 字節流與字符流（3））：

但漢字卻沒有正確輸出，可見 PrintWriter 並沒有採用這個缺省值。查看 header 中的響應：

也沒有任何編碼的指示。

雖然 meta 中聲明是 utf-8，輸出的缺省字符集的值也是 utf-8，可是從最終結果不難看出 PrintWriter 並沒有採納這個值來轉換字節流。（實際上它根本不會試圖去理解這個）。

看一看它的文檔說明，會發現情況有點不一樣：

原來沒有指定時，PrintWriter 不是用 Charset.defaultCharset 中的值，而是用 response.getCharacterEncoding 方法中所返回的值，而沒有指定的話，那個方法其實就返回一個缺省值：ISO-8859-1。

再看看 getCharacterEncoding 方法：

可以看到它的值又是來源於顯式的 response.setCharacterEncoding 或 response.setContentType 方法，或者是隱式的 setLocale 方法。（顯式的具有更高的優先級）假如沒有，就用缺省的 ISO-8859-1。

它還提到 RFC 2047 標準，打開看看，是關於 MIME 中非 ASCII 文本的消息頭擴展（MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text）的。文中有一處提到如果字符集編碼缺失，推薦用 iso8859 系列：