jsp include 乱码问题的解决

 jsp include 乱码问题的解决
jsp include 的文件有时候会出现乱码，经过测试发现如下方法可以修改。
第一种情况可以修改被include的文件：
1.当jsp include动态文件时（jsp文件）可以在被include的jsp文件头部加上代码：

有没有试过EncodingFilter？

在weblogic里面是不能在include page里面再定义contentType的
如果熟悉http，熟悉servlet，明白其中原理，永远都不会遇到乱码问题。
大概说说get和post两种方式：
get需要手工编码解码，手工的意义是编解码过程不是web server来做，甚至web server都不知道你用了什么字符集，但是你自己应该知道。或者程序里用代码，或者客户端浏览器。如果是程序编解码，应该知道对应于各种字符集，编解码规则是怎样的，如果不知道，jdk中提供了java.net.URLDecoder和java.net.URLEncoder两个类，它们都分别有两个带参数和不带参数的编解码方法，不带参数的，使用平台默认的字符集，带参数的，传入的参数作为字符集。其中使用平台默认的含义，不是指java文件编码的字符集，这个默认都是utf8（因此在java里面可以用中文命名类、变量等；可以将utf8兼容的任何语言的字符串保存在String中），而是与语言有关的，比如中文平台下，很可能是gbk，英文平台下可能为iso-8859-1。编解码使用的字符集理论上要一致（兼容也可以，比如gbk和gb2312，但gb2312对应于gbk的补集的内容会是乱码）。为了保持一致的编码解码字符集，需要在方法传入时显式指定一致的字符集。jdk不推荐使用无参的方法，原因就是你可能在一个平台下编译，一个平台下测试，一个平台下部署，如果这些平台的默认字符集不相同，乱码就会出现了。另一种是客户端浏览器的编解码，不同的浏览器不尽相同，比如ie选项里面的“发送utf-8 url”，在ie页面右键选择“编码”等等就是做的这样的事。
然后说说post的情况，post的http消息体是二进制的，编码可以是浏览器、程序员，解码是web server做的事，但是程序员可以干涉。servlet规范要求的默认字符集是iso-8859-1，为什么会有这样的规则，使用中文不是很麻烦吗？自己想想吧，原因可以理解为商品的标签上是rmb100，那你不会花rmb200来买它。那么如何干涉web server用指定的字符集去解码呢？举个例子，一个html page，如果有下面的指定：

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 

首先浏览器会以utf8将http消息体编码后发送给web server，web server接收到后其实是并不知道是哪种字符集，这个时候它会按一定规则去这些地方找字符集：http消息头的locale、http消息头的Accept-Language、http消息头的Accept-Charset、request.getCharacterEncoding()方法（有优先关系的，具体的记不住了），如果找不到的话，就默认了（iso-8859-1），如果接收的时候是用的utf8或其它不是iso-8859-1的字符集，那么乱码就出现了。前面提到的http消息头，是浏览器发送过来的，这里面又有一些规则，国际化，包括spring，就是在这里面做的文章。先不管http消息头规则，我们知道web server会去找request.getCharacterEncoding()方法，那么我们可以干涉的地方就出现了，与之对应的request.setCharacterEncoding()方法，让我们设置正确的字符集，然后再被web server利用此字符集解码，然后我们就可以得到post过去的被正确解码的数据了。dengyin2000同学所说用filter其实就是利用了这点来干涉，解决问题的。

希望这个大概的解释能有一些帮助，在网上看到其它文章，要么是没有说到问题本质，要么根本就是在乱说。

在weblogic里面是不能在include page里面再定义contentType的




如果熟悉http，熟悉servlet，明白其中原理，永远都不会遇到乱码问题。


大概说说get和post两种方式：

get需要手工编码解码，手工的意义是编解码过程不是web server来做，甚至web server都不知道你用了什么字符集，但是你自己应该知道。或者程序里用代码，或者客户端浏览器。如果是程序编解码，应该知道对应于各种字符集，编解码规则是怎样的，如果不知道，jdk中提供了java.net.URLDecoder和java.net.URLEncoder两个类，它们都分别有两个带参数和不带参数的编解码方法，不带参数的，使用平台默认的字符集，带参数的，传入的参数作为字符集。其中使用平台默认的含义，不是指java文件编码的字符集，这个默认都是utf8（因此在java里面可以用中文命名类、变量等；可以将utf8兼容的任何语言的字符串保存在String中），而是与语言有关的，比如中文平台下，很可能是gbk，英文平台下可能为iso-8859-1。编解码使用的字符集理论上要一致（兼容也可以，比如gbk和gb2312，但gb2312对应于gbk的补集的内容会是乱码）。为了保持一致的编码解码字符集，需要在方法传入时显式指定一致的字符集。jdk不推荐使用无参的方法，原因就是你可能在一个平台下编译，一个平台下测试，一个平台下部署，如果这些平台的默认字符集不相同，乱码就会出现了。另一种是客户端浏览器的编解码，不同的浏览器不尽相同，比如ie选项里面的“发送utf-8 url”，在ie页面右键选择“编码”等等就是做的这样的事。

然后说说post的情况，post的http消息体是二进制的，编码可以是浏览器、程序员，解码是web server做的事，但是程序员可以干涉。servlet规范要求的默认字符集是iso-8859-1，为什么会有这样的规则，使用中文不是很麻烦吗？自己想想吧，原因可以理解为商品的标签上是rmb100，那你不会花rmb200来买它。那么如何干涉web server用指定的字符集去解码呢？举个例子，一个html page，如果有下面的指定：

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 

首先浏览器会以utf8将http消息体编码后发送给web server，web server接收到后其实是并不知道是哪种字符集，这个时候它会按一定规则去这些地方找字符集：http消息头的locale、http消息头的Accept-Language、http消息头的Accept-Charset、request.getCharacterEncoding()方法（有优先关系的，具体的记不住了），如果找不到的话，就默认了（iso-8859-1），如果接收的时候是用的utf8或其它不是iso-8859-1的字符集，那么乱码就出现了。前面提到的http消息头，是浏览器发送过来的，这里面又有一些规则，国际化，包括spring，就是在这里面做的文章。先不管http消息头规则，我们知道web server会去找request.getCharacterEncoding()方法，那么我们可以干涉的地方就出现了，与之对应的request.setCharacterEncoding()方法，让我们设置正确的字符集，然后再被web server利用此字符集解码，然后我们就可以得到post过去的被正确解码的数据了。dengyin2000同学所说用filter其实就是利用了这点来干涉，解决问题的。

希望这个大概的解释能有一些帮助，在网上看到其它文章，要么是没有说到问题本质，要么根本就是在乱说。

啊B， 你的帖子被水了！！！

我发现liquidthinker同学没有理清现在我们关注的问题,现在我们关注的是编译期组合出来的文件乱码问题,而不是客户与服务器交互时的乱码问题.