pageEncoding与contextType的一点总结

保存时弹出问题的内容如下：save couldnot be completed. Reason: Some characters could not be mappedusing 'ISO-8859-1' characterencoding. Either change the encoding or remove the characters whichare not supported bythe'ISO-8859-1' characterencoding.译文：不能被保存。原因：有些字符与'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 中。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方法时，指定对服务器响应进行重新编码的编码。contentType='text/html;charset=UTF-8'的作用是指定对服务器响应进行重新编码的编码。在不使用response.setCharacterEncoding方法时，用该参数指定对服务器响应进行重新编码的编码。request.setCharacterEncoding('UTF-8')的作用是设置对客户端请求进行重新编码的编码。该方法用来指定对浏览器发送来的数据进行重新编码（或者称为解码）时，使用的编码。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（有可能影响其他应用，所以不推荐）。關於 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, 就發揮了功效. (見 階段一的).出來的可以是 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).补充:在tomcat中如果在jsp中设定了pageEncoding，则contentType也跟着设定成相同的编码了，但是在resin中就不是，resin中还会用默认的，这点通过查看编译后的类servlet java文件就可以看到这一点，而问题恰恰就出在这里，所以，在jsp中，如果是在resin下最好还是明确的单独设定这2个属性。