Posted on 2011-08-21 23:09
ply 閱讀(681)
評論(0) 編輯 收藏
以前每次遇到這樣的問題，每次都不當回事，吃過不少苦頭。今天特意在網上搜了點東西，學習了一下，解決了問題，并記錄下來，方便以后查閱。
以下在MyEclipse中的jsp代碼：
<% @ page language="java" contentType="text/html;charset=UTF-8" import="java.util.*" pageEncoding="ISO-8859-1"%>
<%
//response.setCharacterEncoding("GBK");
%>
<html>
<body>
<center>Powered by: BlogJava Copyright © 一縷陽光</center><br>
</body>
</html>
保存時彈出問題的內容如下：
save could not be completed.
Reason:
Some characters could not be mapped using "ISO-8859-1" character encoding.
Either change the encoding or remove the characters which are not supported by the "ISO-8859-1" character encoding.
譯文：
不能被保存。
原因：有些字符與"ISO-8859-1"編碼方式不匹配。要么改變編碼方式，要么去掉不被"ISO-8859-1"編碼方式所支持的字符。
分析之后明白了，原來“一縷陽光”中文字符不被“ISO-8859-1”支持，同樣，把pageEncoding改成“GBK”后“Powered by: BlogJava Copyright © ”又不被“GBK”支持。最后把pageEncoding改成“UTF-8”后問題解決了。此外，有時打開導入或copy到文件里的java代碼，代碼里的中文是亂碼，這時需要把項目屬性里的Text file encoding改成“UTF-8”就ok了。(我是這樣改的，問題解決了)
下面的內容是在網上搜的東西，是關于上面的問題的一點擴展，很有用，隨學習之。
首先，說說JSP/Servlet中的幾個編碼的作用：
在JSP/Servlet中主要有以下幾個地方可以設置編碼，pageEncoding="UTF-8",contentType="text/html;charset=UTF-8"、request.setCharacterEncoding("UTF-8")和 response.setCharacterEncoding("UTF-8")，其中前兩個只能用于JSP中，而后兩個可以用于JSP和Servlet 中。
1、pageEncoding="UTF-8"的作用是設置JSP編譯成Servlet時使用的編碼。
眾所周知，JSP在服務器上是要先被編譯成Servlet的。pageEncoding="UTF-8"的作用就是告訴JSP編譯器在將JSP文件編譯成Servlet時使用的編碼。通常，在JSP內部定義的字符串（直接在JSP中定義，而不是從瀏覽器提交的數據）出現亂碼時，很多都是由于該參數設置錯誤引起的。例如，你的JSP文件的Properties-Text file encoding中是以GBK為編碼保存的，而在JSP頁面的page標簽中卻指定pageEncoding="UTF-8"，就會引起JSP內部定義的字符串為亂碼。
另外，該參數還有一個功能，就是在JSP中不指定contentType參數，也不使用response.setCharacterEncoding方法時，指定對服務器響應進行重新編碼的編碼。
2、contentType="text/html;charset=UTF-8"的作用是指定對服務器響應進行重新編碼的編碼。
在不使用response.setCharacterEncoding方法時，用該參數指定對服務器響應進行重新編碼的編碼。
3、request.setCharacterEncoding("UTF-8")的作用是設置對客戶端請求進行重新編碼的編碼。
該方法用來指定對瀏覽器發送來的數據進行重新編碼（或者稱為解碼）時，使用的編碼。
4、response.setCharacterEncoding("UTF-8")的作用是指定對服務器響應進行重新編碼的編碼。
服務器在將數據發送到瀏覽器前，對數據進行重新編碼時，使用的就是該編碼。
其次，要說一說瀏覽器是怎么樣對接收和發送的數據進行編碼的
response.setCharacterEncoding("UTF- 8")的作用是指定對服務器響應進行重新編碼的編碼。同時，瀏覽器也是根據這個參數來對其接收到的數據進行重新編碼（或者稱為解碼）。所以在無論你在 JSP中設置response.setCharacterEncoding("UTF-8")或者 response.setCharacterEncoding("GBK")，瀏覽器均能正確顯示中文（前提是你發送到瀏覽器的數據編碼是正確的，比如正 確設置了pageEncoding參數等）。讀者可以做個實驗，在JSP中設置response.setCharacterEncoding("UTF- 8")，在IE中顯示該頁面時，在IE的菜單中選擇"查看(V)"à"編碼(D)"中可以查看到是" Unicode（UTF-8）"，而在在JSP中設置response.setCharacterEncoding("GBK")，在IE中顯示該頁面 時，在IE的菜單中選擇"查看(V)"à"編碼(D)"中可以查看到是"簡體中文（GB2312）"。
瀏覽器在發送數據時，對URL和參數會進行URL編碼，對參數中的中文，瀏覽器也是使response.setCharacterEncoding參數來進行URL編碼的。以百度和 GOOGLE為例，如果你在百度中搜索"漢字"，百度會將其編碼為"%BA%BA%D7%D6"。而在GOOGLE中搜索"漢字"，GOOGLE會將其編 碼為"%E6%B1%89%E5%AD%97"，這是因為百度的response.setCharacterEncoding參數為GBK，而 GOOGLE的的response.setCharacterEncoding參數為UTF-8。
瀏覽器在接收服務器數據和發送數據到服務器時所使用的編碼是相同的，默認情況下均為JSP頁面的response.setCharacterEncoding參數（或者contentType和 pageEncoding參數），我們稱其為瀏覽器編碼。當然，在IE中可以修改瀏覽器編碼（在IE的菜單中選擇"查看(V)"à"編碼(D)"中修 改），但通常情況下，修改該參數會使原本正確的頁面中出現亂碼。一個有趣的例子是，在IE中瀏覽GOOGLE的主頁時，將瀏覽器編碼修改為"簡體中文 （GB2312）"，此時，頁面上的中文會變成亂碼，不理它，在文本框中輸入"漢字"，提交，GOOGLE會將其編碼為"%BA%BA%D7%D6"，可見，瀏覽器在對中文進行URL編碼時，使用的就是瀏覽器編碼。
弄清了瀏覽器是在接收和發送數據時，是如何對數據進行編碼的了，我們再來看看服務器是在接收和發送數據時，是如何對數據進行編碼的。
對于發送數據，服務器按照response.setCharacterEncoding—contentType—pageEncoding的優先順序，對要發送的數據進行編碼。
對于接收數據，要分三種情況。一種是瀏覽器直接用URL提交的數據，另外兩種是用表單的GET和POST方式提交的數據。
因為各種WEB服務器對這三種方式的處理也不相同，所以我們以Tomcat5.0為例。
無論使用那種方式提交，如果參數中包含中文，瀏覽器都會使用當前瀏覽器編碼對其進行URL編碼。
對于表單中POST方式提交的數據，只要在接收數據的JSP中正確request.setCharacterEncoding參數，即將對客戶端請求進行重 新編碼的編碼設置成瀏覽器編碼，就可以保證得到的參數編碼正確。有寫讀者可能會問，那如何得到瀏覽器編碼呢？上面我們提過了，在默認請情況下，瀏覽器編碼 就是你在響應該請求的JSP頁面中response.setCharacterEncoding設置的值。所以對于POST表單提交的數據，在獲得數據的 JSP頁面中request.setCharacterEncoding要和生成提交該表單的JSP頁面的 response.setCharacterEncoding設置成相同的值。
對于URL提交的數據和表單中GET方式提交的數據，在接收數 據的JSP中設置request.setCharacterEncoding參數是不行的，因為在Tomcat5.0中，默認情況下使用ISO- 8859-1對URL提交的數據和表單中GET方式提交的數據進行重新編碼（解碼），而不使用該參數對URL提交的數據和表單中GET方式提交的數據進行 重新編碼（解碼）。要解決該問題，應該在Tomcat的配置文件的Connector標簽中設置useBodyEncodingForURI或者 URIEncoding屬性，其中useBodyEncodingForURI參數表示是否用request.setCharacterEncoding 參數對URL提交的數據和表單中GET方式提交的數據進行重新編碼，在默認情況下，該參數為false（Tomcat4.0中該參數默認為 true）；URIEncoding參數指定對所有GET方式請求（包括URL提交的數據和表單中GET方式提交的數據）進行統一的重新編碼（解碼）的編 碼。URIEncoding和useBodyEncodingForURI區別是，URIEncoding是對所有GET方式的請求的數據進行統一的重新 編碼（解碼），而useBodyEncodingForURI則是根據響應該請求的頁面的request.setCharacterEncoding參數 對數據進行的重新編碼（解碼），不同的頁面可以有不同的重新編碼（解碼）的編碼。所以對于URL提交的數據和表單中GET方式提交的數據，可以修改 URIEncoding參數為瀏覽器編碼或者修改useBodyEncodingForURI為true，并且在獲得數據的JSP頁面中 request.setCharacterEncoding參數設置成瀏覽器編碼。
下面總結下，以Tomcat5.0為WEB服務器時，如何防止中文亂碼。
1、對于同一個應用，最好統一編碼，推薦為UTF-8，當然GBK也可以。
2、正確設置JSP的pageEncoding參數
3、在所有的JSP/Servlet中設置contentType="text/html;charset=UTF-8"或response.setCharacterEncoding("UTF-8")，從而間接實現對瀏覽器編碼的設置。
4、 對于請求，可以使用過濾器或者在每個JSP/Servlet中設置request.setCharacterEncoding("UTF-8")。同時， 要修改Tomcat的默認配置，推薦將useBodyEncodingForURI參數設置為true，也可以將URIEncoding參數設置為 UTF-8（有可能影響其他應用，所以不推薦）。
以上內容轉自：http://blog.csdn.net/nercon233/archive/2009/04/27/4129709.aspx
關於 contentType 和 pageEncoding 的差異 和 中文JSP頁的設定技巧:
contentType -- 指定的是JSP頁最終 Browser(客戶端)所見到的網頁內容的編碼.
就是 Mozilla的 Character encoding, 或者是 IE6的 encoding. 例如 JSPtw Forum 用的contentType就是 Big5.
pageEncoding -- 指定JSP編寫時所用的編碼
如果你的是 WIN98, 或 ME 的NOTEPAD記事本編寫JSP, 就一定是常用的是Big5 或 gb2312, 如果是用 WIN2k winXP的NOTEPAD時, SAVE時就可以選擇不同的編,碼, 包括 ANSI(BIG5/GB2312)或 UTF-8 或 UNIONCODE(估是 UCS 16).
因為 JSP要經過 兩次的"編碼", 第一階段會用 pageEncoding, 第二階段會用 utf-8 至utf-8, 第三階段就是由TOMCAT出來的網頁, 用的是contentType.
階段一是 JSPC的 JSP至JAVA(.java)原碼的"翻譯", 它會跟據 pageEncoding 的設定讀取JSP. 結果是 由指定的 pageEncoding(utf-8,Big5,gb2312)的JSP 翻譯成統一的utf-8 JAVA原碼(.java). 如果pageEncoding設定錯了, 或沒設定(預設 ISO8859-1), 出來的 在這個階段 就已是中文亂碼.
階段二是由 JAVAC的JAVA原碼至JAVA BYTECODE的編譯. 不論JSP的編寫時是用(utf-8,Big5,gb2312),經過階段一的結果全都是utf-8的ENCODING的JAVA原碼.
JAVAC用 utf-8的ENCODING讀取AVA原碼, 編譯成字串是 utf-8 ENCODING的二進制碼(.class). 這是 JAVA VIRTUAL MACNHINE 對常數字串在 二進制碼(JAVA BYTECODE)內表逹的規範.
階段三是TOMCAT(或其的application container)載入和執行 階段二得來的JAVA二進制碼, 輸出的結果( 也就是BROWSER(客戶端)) 見到的. 這時一早隱藏在階段一和二的參數contentType, 就發揮了功效. (見 階段一的
|
1
|
response.setContentType("text/html; charset=utf-8");
|
).
出來的可以是 utf-8, Big5, gb2312, 看的就是JSP
|
1
|
<%@ page session="false" pageEncoding="big5" contentType="text/html; charset=utf-8" %>
|
?contentType的設定.
**還有, pageEncoding 和contentType的預設都是 ISO8859-1. 而隨便設定了其中一個, 另一個就跟著一樣了(TOMCAT4.1.27是如此). 但這不是絕對, 看的各自JSPC的處理方式. 而pageEncoding不等於contentType, 更有利亞洲區的文字 CJKV系JSP網頁的開發和展示, (例pageEncoding=Big5 不等於 contentType=utf-8).
以上內容轉自：http://www.javaworld.com.tw/jute/post/view?bid=6&id=21986&tpg=1&ppg=1&sty=1&age=0#21986