解决前台请求后台乱码的问题

一：GET 请求乱码

造成原因

• 浏览器请求文字编码和页面编码保持一致，页面编码一般都是 UTF-8 ，GET 方式也是使用 UTF-8，Tomcat 接收请求没有设置编码默认使用 ISO-8859-1，传入中文参数后台接收自然乱码

方案一

ISO-8859-1 是单字节编码，可以用 new String 的方式转换

String value = request.getParameter("name");
value = new String(value.getBytes("ISO-8859-1"), "UTF-8");

方案二（Tomcat）

可以在 server.xml 文件指定编码

将 Connector connectionTimeout=“20000” port=“8080” protocol=“HTTP/1.1” redirectPort=“8443”

修改成 Connector connectionTimeout=“20000” port=“8080” protocol=“HTTP/1.1” redirectPort=“8443” URIEncoding=“UTF-8”

使用这种方式带来的问题是在你本地上这么做没有问题，你无论怎么去修改你tomcat上的配置都没问题，但是测试环境和生产环境的服务器不是说改就能改的，特别是有些公司的服务器是租赁的，那么在我们不知道测试环境和生产环境服务器配置的时候就要使用以下的方法来解决 GET 请求的中文乱码问题。

方案三

前台对字符进行编码

var value = encodeURI(encodeURI(“xxx”))

后台对字符进行解码

String xxx = URLDecoder.decode(request.getParameter(“xxx”), “UTF-8”);

因为 GET 请求的参数在请求行上，我们不能像解决 POST 一样使用 request.setCharacterEncoding(“UTF-8”)，这种方式是修改方法体的编码方式，所以需要前台编码、后台解码的工作。

这里前台需要编码两次，因为第一次编码，生成了含有 % 开头的字符，在浏览器里面 % 是一个转义字符，浏览器提交到服务器时会将这一串编码后的字符 % 与 % 之间的编码，两位两位取出后进行解码，然后再传递给处理页面，所以编码一次不够，编码两次以后后台拿到的才是正确的字符，才能进行解码的操作！

二：POST 请求乱码：使用过滤器即可解决

三：log4j 在 Linux 下显示乱码解决方法：log4j 配置文件中加一句话即可解决：log4j.appender.logfile.encoding=UTF-8