Tomcat里网页中文乱码，网页十次有八次是中文编码不一致造成的。剩下的乱码两次，八成是网页配置文件写错了地方。

我上周刚帮同事排查过一个。中文他页面里写得明明白白，乱码数据库连接也加了characterEncoding=utf8，网页可浏览器一打开，中文满屏的乱码“锟斤拷”。我打开他的网页server.xml一看，标签里压根没写URIEncoding。中文这就好比你把信写好了，乱码信封上却用英文写收件人地址，网页邮局可不就给你乱投递嘛。中文

解决乱码，乱码先分清是“请求乱码”还是“响应乱码”。响应乱码最直观——页面显示成“ä½ å¥½”这种。检查顺序：先看JSP页面本身的编码，再看response.setContentType。页面文件用UTF-8保存，但response里写的ISO-8859-1，那肯定乱。这个最简单，统一成UTF-8就行。

请求乱码更隐蔽。表单提交中文，后台拿到的是问号或者火星文。Tomcat 8以上版本默认URIEncoding就是UTF-8，但如果你用的是老版本，或者有人手贱改过server.xml，那就麻烦了。我见过一个生产环境，运维为了“优化性能”把URIEncoding改成了GBK，结果所有新页面的搜索功能全废了。改回UTF-8，重启，问题消失。

还有一类特殊情况——POST请求乱码但GET正常。这时候别去动server.xml，查web.xml里的CharacterEncodingFilter。Spring框架自带这个过滤器，但如果你没配置forceEncoding=true，它只会处理POST，GET还是走Tomcat默认。我之前踩过这个坑，加了forceEncoding后世界清净了。

另外说个冷门但真实的案例。有个项目用Tomcat 7，页面和代码全是UTF-8，唯独浏览器是IE11。每次提交中文，后台拿到的字符串末尾总多个“?”。查了半天，发现是IE的“以UTF-8发送URL”选项没勾选。这算浏览器端的坑，跟Tomcat没关系。但你要是只盯着服务器配置，永远找不到答案。所以排查乱码，前端后端都得看。

最后给你个偷懒技巧。如果项目里所有地方都设了UTF-8但还是乱，直接在catalina.sh里加一行JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=UTF-8"。这能兜底解决一部分JVM默认编码导致的乱码。但记住，这是治标不治本，真正的问题往往在你没注意到的某个filter或者连接池配置里。

乱码这东西，本质就是“编码”和“解码”的规矩没对齐。你写的时候用UTF-8，读的时候也得用UTF-8。中间任何一环用了别的字符集，数据就花了。排查时别慌，按“请求→响应→容器→JVM”的顺序捋一遍，最多半小时就能定位。要是超过一小时还没头绪，多半是有人在你不知道的地方改了什么配置——去问问运维吧，他们最清楚。