tomcat 默认编码为 iso-8859-1，前台页面 <%@ page language="java" pageEncoding="gbk"%>.
我理解的是 get url的编码方式为 前台页面 pageEncoding="gbk"，后台解码方式为 iso-8859-1。
这种情况我用 new String(name.getBytes("iso-8859-1"),"gbk") 可以得到正确的中文。
当我改tomcat的默认编码 为 utf-8或者是 gbk时，前台也面也设为 pageEncoding="gbk或 utf-8"， 不用手动转码就可以得到正确中文。 ： 前 utf-8--后 utf-8， 前gbk --- 后 utf-8。
当前 为 utf-8 后台tomcat为 gbk 时，new String(name.getBytes("gbk"),"utf-8") 出现乱码，反之亦然。
我想确认下
1.前台页面 pageEncoding="gbk"，是否决定 get url的编码方式。 如果不是那又是谁再决定。
2.后台解码时 当前台没有手动 改变参数编码，这个时候前台编码用 pageEncoding="gbk，后台解码用tomcat默认编码，当前台用了 手动编码参数，如：
<% String name=java.net.URLEncoder.encode("编辑","gbk"); %> 时，则前台 pageEncoding="gbk 对于get url 不再起作用，后台依然用 tomcat默认编码，正确么? 如果不正确，请指正！
3.对于后台 网上说 tomcat 默认的是 iso-8859-1，那weblogic的默认编码是多少？ 或者是 weblogic的解码是依据哪种格式？
4.new String(字节码,"gbk") 的用意是 把字节码按gbk的方式解码，这时 解码出来的汉字是gbk编码格式的汉子，java文件本身的编码显示格式如果不是gbk，那么能正确显示么？
------解决方案--------------------------------------------------------
1.前台页面 pageEncoding="gbk"，是否决定 get url的编码方式。 如果不是那又是谁再决定。
不是，pageEncoding 指定的是 JSP 编译转换成为 Java 文件后的编码格式，这个根本没有必要去指定！
2.后台解码时 当前台没有手动 改变参数编码，这个时候前台编码用 pageEncoding="gbk，后台解码用tomcat默认编码，当前台用了 手动编码参数，如：
<% String name=java.net.URLEncoder.encode("编辑","gbk"); %> 时，则前台 pageEncoding="gbk 对于get url 不再起作用，后台依然用 tomcat默认编码，正确么? 如果不正确，请指正！
不正确。
使用 URLEncoder.encode 或者 JavaScript 的 encode 是正确的，根据 URI 规范 URI 中可用的字符是有限制的，并不是什么字符都能往上贴：
URI: RFC 2396 (http://tools.ietf.org/html/rfc2396)
URI 中允许的字符为：保留字|未保留字|转义编码字
保留字：";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
非保留字：字母 | 数字 | "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
转义编码字：不是保留字和非保留字的字符需要进行编码转义，数据中需要使用保留字时，保留字也需要进行转义。格式为 % HEX HEX
如果熟悉 HTTP 协议，那应该知道 GET 请求的 URI 是放在请求头的状态行中的。因此 URI 的解析主要看 Web 服务器采用哪种方式对 HTTP 请求状态行进行处理，并不是使用什么 pageEncoding 处理的！[/color]
3.对于后台 网上说 tomcat 默认的是 iso-8859-1，那weblogic的默认编码是多少？ 或者是 weblogic的解码是依据哪种格式？
没用过，没法回答你
4.new String(字节码,"gbk") 的用意是 把字节码按gbk的方式解码，这时 解码出来的汉字是gbk编码格式的汉子，java文件本身的编码显示格式如果不是gbk，那么能正确显示么？
不能，请不要想当然地把 new String(字节码,"gbk") 这个构造当作是一个编码转换工具，这个构造只能将指定编码的字节重新组装成为字符中，并不能把其他编码的字节转换成为指定编码的字符串。
关于这个问题详见之前回复的一个帖子：
http://topic.csdn.net/u/20080623/16/e0f44f00-eaf9-4d38-b325-a3cc443f2ec9
------解决方案--------------------------------------------------------
以前也研究过编码的问题，感觉还是最好不用get方法传中文。你IDE工具不同，默认解码方式也不尽相同。不注意的话就会出现乱码。还有就是测试web容器编码跟用户的web容器编码也不一定相同，在测试容器上改编码，在用户上面就不能随便改编码了，因为他上面有可能还运行其他的项目，这样容易造成其他项目不正常。我总结的就是传中文的话就用post方式。或者将汉字转换成code代码，在后台进行解析
------解决方案--------------------------------------------------------
URI 中允许的字符为：保留字|未保留字|转义编码字
保留字：";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
非保留字：字母 | 数字 | "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
转义编码字：不是保留字和非保留字的字符需要进行编码转义，数据中需要使用保留字时，保留字也需要进行转义。格式为 % HEX HEX
这个需要再次强调一下！可能有人会说，我在浏览器地址栏上有看到过中文的啊，比如：
这要被这迷惑了，我们看看具体发送给服务端的是什么数据：
从 HTTP 请求状态行中可以看出，这些中文字符是经过 URI 编码之后发送给服务器的。
浏览器地址上允许出现中文等非 URI 允许的字符是浏览器给我们的一种福利，记住是这是一种福利，而不是理所当然！