javaWeb乱码原因分析与解决方案

       乱码的产生是因为编码解码采用了不同的标准，eg：utf-8，ascii，iso8859-1。
       前提知识：计算机只能识别二进制文件，需要将文字符号转化为二进制数据，这一过程叫做编码；而将二进制数据转换成我们看得动的字符，这一过程叫做解码。
       字符集（Charset）是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称。
       字符编码（Character Encoding）是一套法则，使用该法则能够对自然语言的字符的一个集合（如字母表或音节表），与其他东西的一个集合（如号码或电脉冲）进行配对。

---

在网页开发中，乱码的产生有两个方面：

• 请求参数乱码(服务器解析浏览器发送的信息乱码)
• 响应体乱码(浏览器解析服务器响应信息乱码)

1.请求参数乱码

• get:
  原因：请求参数在url中，tomcat收到url后，将其解码（用iso8859-1），封装成request对象.
  恢复原理：`

//s1是服务器用iso8859-1解码得到的请求参数
new String(s1.getBytes("ISO-8859-1"),"utf-8");
//将s1重新用ISO-8859-1编码，在将其以utf-8正确解码

解决方案：在tomcat服务器的配置文件servlet.xml中，在8080端口（默认）处，添加URIEncoding=“UTF-8”。设置服务器编解码为utf-8.

• post:
  原因：请求带来的数据在请求中，而tomcat不会立刻对其解码。一旦调用request.getParameter(),就将请求全部解析
  解决方案：request.setCharacterEncoding (“utf-8”)

2.响应乱码

       原因：浏览器不知道响应内容是什么编码，用默认编码解析
解决：response.setContentType();

ps:response.setCharacterEncoding()设置服务器发送到浏览器的编码方式。

      如果上述方法在idea不行，在tomcat中可行，看看是否在idea中vm参数中有-Dfile.encoding=UTF-8（不确保正确）

       若idea控制台连接tomcat时乱码，将tomcat的logging.properties中的编码utf-8改成GBK
       控制台或tomcat乱码原因：windows下控制台默认编码GBK，而tomcat控制台日志编码为utf-8默认