Java servlet 使用 PrintWriter 時(shí)的編碼與亂碼的示例代碼

更新時(shí)間：2017年11月07日 09:32:26 作者：肖國(guó)棟的i自留地

本篇文章主要介紹了Java servlet 使用 PrintWriter 時(shí)的編碼與亂碼的示例代碼，探討了 PrintWriter 的缺省編碼與普通字符流的缺省編碼的差異，具有一定的參考價(jià)值，有興趣的可以了解一下

在前面的網(wǎng)頁(yè)中的編碼與亂碼系列中，曾多次提到使用 servlet 方式構(gòu)建的動(dòng)態(tài)響應(yīng)流，不過(guò)在那里都是直接使用字節(jié)流的方式，不過(guò)，更為常見的方式是使用字符流。而在前面，又談到了 Java 字節(jié)流與字符流的話題。

有了前面的基礎(chǔ)，現(xiàn)在來(lái)說(shuō)下 Java servlet 中使用字符流，也即是 PrintWriter 時(shí)的編碼與亂碼問(wèn)題。

回顧字節(jié)流的情形

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

或者這樣：

只要保持了一致，就不用擔(dān)心發(fā)生亂碼的問(wèn)題。

使用 PrintWriter 字符流，缺省編碼

現(xiàn)在假如使用 PrintWriter 來(lái)作為響應(yīng)呢？比如這樣：

代碼中并沒(méi)有顯式傳入什么編碼的參數(shù)，不像 String.getBytes 那樣。另一方面，我們知道，字符流最終還是要轉(zhuǎn)換成字節(jié)流，可是它到底使用了什么編碼呢？是不是 Charset.defaultCharset 中的值呢？

就以上述代碼為例，假如現(xiàn)在在瀏覽器中查看，會(huì)發(fā)現(xiàn)結(jié)果是這樣的：

可見 defaultCharset 缺省是 utf-8，前面說(shuō)過(guò)，這其實(shí)來(lái)自于啟動(dòng) tomcat server 時(shí)所傳入的參數(shù) –Dfile.encoding：

但漢字卻沒(méi)有正確輸出，可見 PrintWriter 并沒(méi)有采用這個(gè)缺省值。查看 header 中的響應(yīng)：

也沒(méi)有任何編碼的指示。

雖然 meta 中聲明是 utf-8，輸出的缺省字符集的值也是 utf-8，可是從最終結(jié)果不難看出 PrintWriter 并沒(méi)有采納這個(gè)值來(lái)轉(zhuǎn)換字節(jié)流。（實(shí)際上它根本不會(huì)試圖去理解這個(gè)）。

看一看它的文檔說(shuō)明，會(huì)發(fā)現(xiàn)情況有點(diǎn)不一樣：

原來(lái)沒(méi)有指定時(shí)，PrintWriter 不是用 Charset.defaultCharset 中的值，而是用 response.getCharacterEncoding 方法中所返回的值，而沒(méi)有指定的話，那個(gè)方法其實(shí)就返回一個(gè)缺省值：ISO-8859-1。

再看看 getCharacterEncoding 方法：

可以看到它的值又是來(lái)源于顯式的 response.setCharacterEncoding 或 response.setContentType 方法，或者是隱式的 setLocale 方法。（顯式的具有更高的優(yōu)先級(jí)）假如沒(méi)有，就用缺省的 ISO-8859-1。

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