Tomcat乱码，乱码十有八九是解决编码不一致造成的。你往浏览器里塞了一串UTF-8的乱码字节，Tomcat却按ISO-8859-1去读，解决那不乱才怪。乱码我见过太多人折腾半天，解决最后发现只是乱码漏了一个URIEncoding。

先看最常见的解决情况——GET请求的URL参数乱码。比如你在地址栏输入?乱码name=张三，后台接出来是解决å¼ ä¸‰。这问题出在Tomcat8.0之前，乱码默认用ISO-8859-1解析URI。解决解决很简单，乱码打开server.xml，解决找到Connector标签，乱码加一句URIEncoding="UTF-8"。改完重启，基本就清净了。要是你用的Tomcat8.5以上，默认已经是UTF-8，还乱码就得查别的地方。

POST请求的乱码又是另一码事。表单提交的数据，Tomcat用request.getParameter()读取时，会按request的编码来解码。如果你没设置，默认又是ISO-8859-1。这时候最粗暴的办法是在代码里加request.setCharacterEncoding("UTF-8")，但必须放在第一次getParameter之前。更省心的做法是装个字符编码过滤器，Spring的CharacterEncodingFilter就能干这活，配置一下forceEncoding=true，让请求和响应都强制走UTF-8。

还有一种情况特别坑——响应乱码。你后台返回的JSON明明是对的，浏览器却显示一堆问号。检查一下response.setContentType("text/html;charset=UTF-8")有没有设置。有时候是页面本身的meta标签声明了GBK，但服务器吐的是UTF-8，两边打架。我习惯在开发时统一用UTF-8，从JSP页面到数据库连接串，再到Tomcat配置，全部一个编码，省得来回猜。

数据库那块也容易出幺蛾子。MySQL连接串没加characterEncoding=utf8，存进去的中文取出来全变???。这个不算Tomcat的锅，但排查乱码问题时，八成会撞上。你改了Tomcat的编码，数据库还是错的，照样白搭。

最后说个真实案例。前阵子帮人调一个老项目，Tomcat7 + JSP + Oracle，页面提交中文到后台，控制台打印全是?????。查了半天，发现JSP页面顶部没写pageEncoding，Eclipse默认用GBK保存文件，而Tomcat又按UTF-8解析。文件本身编码和声明不一致，这种问题最隐蔽。解决办法是把JSP文件另存为UTF-8，同时加上<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>。顺手把IDE的默认编码也改成UTF-8，不然下次新建文件又踩坑。

乱码这东西，本质就是编码链条上某个环节断了。你按图索骥，从浏览器到服务器再到数据库，挨个确认统一用UTF-8，基本能治九成以上的毛病。剩下那一成，多半是文件本身存坏了——那种情况，直接重写文件比改配置快。