乱码的产生是因为编码解码采用了不同的标准，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正确解码
解决方案：1.request.setCharacterEncoding ()
2.在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默认
