首先我們來看一張由eclipse生成的jsp文件的頭：

圖1:JSP文件編碼

如上圖所示jsp中的三個編碼，

①代表的是服務器響應客戶端請求的編碼方式。服務器會用它來設置http響應頭的content-type。就好比在Servlet中用response.setContentType("text/html;charset=utf-8")的作用。可以在瀏覽器的Header中響應頭中的Content-Type中看到。

②pageEnconding的編碼是值jsp文件本身被編碼的編碼格式。因為jsp最終會被編譯成clss的字節碼，而字節碼是Unicode編碼的，所以必須知道格式才能轉換。如果沒有設置，eclipse會按iso-8859-1的編碼方式對其編碼。如果1沒有設置，那么就會使用2pageEncoding的編碼來設置。

③中的content也是設置瀏覽器的解碼格式的，但是它的優先級沒有Header中的Content-Type優先級高，所以只要在Header中設置了Content-Type，那么就基本不會使用meta中的content了。

下面通過一個非常簡單的例子來測試一下：

pageEncoding="UTF-8"%>

html?PUBLIC?"-//W3C//DTD?HTML?4.01?Transitional//EN"?"http://www.w3.org/TR/html4/loose.dtd">

encoding

您好！

非常簡單，運行沒有亂碼。用Firefox的debug看一下請求頭如下：

圖2：Header1

如果您有興趣，可以嘗試著把圖1中①的編碼contentType去掉，發現還是沒有亂碼，查看響應頭信息，Content-Type的編碼依然是utf-8,這是因為如果沒有設置圖1中①的編碼contentType默認使用的就是圖1中②pageEncoding的編碼方式。

還可以嘗試著把③中的編碼改為iso-8859-1之類的與中文不兼容的編碼，發現仍然沒有亂碼，查看請求頭信息Content-Type的編碼依然是utf-8，并且比meta中編碼的優先級高所以瀏覽器還是使用響應頭中的utf-8的方式來解碼。

現在我們把中①的編碼contentType編碼改為GBK，如下圖：

圖3：contentType-GBK

在Firefox debug中查看請求頭信息Content-Type的編碼，發現Content-Type的編碼是GBK這樣證明①的編碼contentType是設置響應頭中的Content_Type。但是奇怪的是并沒有產生亂碼，服務器明明是utf-8編碼，響應頭是GBK為什么沒有出現亂碼呢？暫時無解。

但是我們把中①的編碼contentType編碼改為iso-8859-1不兼容中文的編碼方式，發現就出現亂碼了。

關于圖3中沒有出現亂碼的原因，也許我們能夠從瀏覽器的解碼過程中找到一些提示，請參考：

總結

以上是生活随笔為你收集整理的jsp java乱码转换_Java Web 编码问题一：jsp的编码问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。