写了无数次JSP作业，每次表单提交中文给服务器，返回来的不是“张三”而是“寮犱笁”，甚至一整排问号。网上搜解决方案，有人让你在页面顶部加一行代码，有人让你改配置文件，抄了一堆，换个环境又挂。问题到底出在哪？
这个标题里有个关键词——理解原理。只有搞清楚“浏览器提交中文→服务器接收→页面显示”这条链路上每一环做了什么转换，你才能在不同容器、不同版本、不同部署环境下一次定位乱码根源，而不是靠配置碎片碰运气。这篇我会完全围绕内置对象request展开：为什么POST和GET的乱码解法完全不同，为什么那一行经典代码必须放在取值之前，为什么改了Tomcat配置在某些情况又失效。把这几个点吃透，JSP乱码基本就告别你了。
1. 动手之前先看本质：乱码的根源是“编码→解码”的不一致
1.1 一个乱码例子背后，浏览器和服务器各自做了什么
假设JSP页面里有一个表单：
<form action="show.jsp" method="post"> <input type="text" name="username" /> <input type="submit" value="提交" /> </form>你在输入框里敲了“张三”，点提交。很多人以为“张三”这两个汉字直接传给了服务器，其实不是。HTTP协议传输的是字节，不是字符。浏览器拿到“张三”这两个Unicode字符后，必须按照某套规则把它们变成字节流，这个过程叫编码；服务器收到字节流后，要按某套规则把字节还原成字符，这个过程叫解码。
如果浏览器编码用的规则和服务器解码用的规则是同一个，那什么都没发生，中文正确还原；一旦两边的规则不一致，出来的就是乱码。这就是乱码问题的唯一根源——编码与解码不对称。
说得更直白一点：这就好比我把“苹果”说成了英文“apple”，你却按法语的发音规则去听，听到的自然是另一个词。字符编码同理，“张三”的UTF-8字节是E5 BC A0 E4 B8 89，按GBK去解码，得到的就是“寮犱笁”。你看到的每一个乱码字符，都不是凭空产生的，而是同一串字节换了一把错误的“钥匙”解出来的。
1.2 三把常见的“钥匙”：ISO-8859-1、GBK、UTF-8
做JSP开发，你迟早会跟这三套编码打交道：
| 编码名称 | 特点 | 能表示中文吗 | 典型场景 |
|---|---|---|---|
| ISO-8859-1 | 单字节编码，也叫Latin-1，一个字符占1字节 | 不能 | 老系统、Tomcat默认URI编码（旧版本） |
| GBK | 中文编码，一个汉字占2字节 | 能 | 国内老项目、Windows本地文件 |
| UTF-8 | 变长编码，一个汉字通常占3字节 | 能 | 现代项目通用标准，国际化首选 |
我见过不少初学JSP的人，写代码时图省事，几套编码混着用：页面声明用UTF-8，数据库连接串里写GBK，Tomcat配置不设置服务器默认编码，最后全靠一个个“补丁”去救。这种项目能跑起来依赖的是“恰好没碰到中文”，一旦碰到复杂字符，立刻露馅。
所以，在进入任何解决方案之前，先建立一条编码自查链路：浏览器用什么编码发出去的？服务器用什么编码解的？这两个必须对齐。后面的所有代码、配置，都是为了让这两把钥匙对齐。
2. 从浏览器到服务器的两次关键转换：为什么同一个乱码问题分两种解法
2.1 GET与POST：请求参数走的根本不是同一条路
在HTTP协议里，POST请求的表单数据放在请求体（Body）里，而GET请求的参数拼在URL后面，比如：
http://localhost:8080/demo/show.jsp?username=张三这两条路径在Tomcat内部的解析流程完全不同。POST的请求体在到达你的JSP代码时，你可以通过一个API去指定按什么编码来读；而GET的URL在Tomcat解析请求行的那一刻就已经被解码了，那时候你的request对象还没创建出来，你根本来不及干预。
这就是为什么网上所有教程都会告诉你两句话：
- POST乱码：在取值之前调用
request.setCharacterEncoding("UTF-8")； - GET乱码：调那行代码没用，要改Tomcat配置或手动转码。
很多人只记住了这两句话，却不知道为什么。于是出现两种情况：一是POST乱码解决了，换到GET又乱，以为代码抄错；二是压根没分清自己的表单是GET还是POST，把方案混着用，越试越乱。
2.2 只有搞懂“上层已经解码”这件事，你才能定位问题方向
以Tomcat为例，它处理一个GET请求的节奏是这样：
- 收到HTTP请求头，里面有请求行：
GET /demo/show.jsp?username=张三 HTTP/1.1； - Tomcat的Connector组件解析请求行，按配置好的URIEncoding把URL里的参数解码成Java字符串；
- 此时才封装出request对象，交给JSP/Servlet去处理。
也就是说，当你拿着request.getParameter("username")去取值的时候，“张三”早就在第2步被解码过了。你在第3步再调用request.setCharacterEncoding("UTF-8")，管的是未来请求体的解码规则，但对已经从URL里解出来的字符串毫无影响。这个“时间差”是所有GET乱码问题的最底层原因。
POST请求就完全不一样。请求体里的字节流还“原封未动”地躺在缓冲区里，request对象创建之后再设置解码规则，Tomcat读取请求体时就能按新的规则去解。因此request.setCharacterEncoding()必须写在getParameter()之前——顺序错了，缓冲区里的数据已经按默认编码消费掉了，再设置就晚了。
把这个底层时序搞清楚，再去理解后面的每一个方案，你会发现这些代码和配置都不是孤立记忆的，而是顺着这条链路自然推导出来的。
3. POST乱码的最简解法：setCharacterEncoding的调用时机是生死线
3.1 一行代码的正确姿势与工作原理
对于POST提交，最经典的解决方案就是在接收参数之前，先指定请求体的解码字符集：
<%@ page contentType="text/html; charset=UTF-8" %> <% request.setCharacterEncoding("UTF-8"); String username = request.getParameter("username"); out.println("你好，" + username); %>浏览器在提交表单时，默认会以页面的字符编码来编码表单数据。如果你的页面是UTF-8，那浏览器发出来的请求体就是UTF-8编码的字节流。此时request.setCharacterEncoding("UTF-8")在读取请求体之前设置解码规则，服务器就会用UTF-8去解析那串字节，中文自然就正确还原了。
这里有一个细节值得注意：setCharacterEncoding只影响请求体的解码，所以它对POST表单参数有效，对GET参数无效。当你看到有人说“我设置了这行代码，GET乱码还是解决不了”时，不用怀疑，就是这个原因。
3.2 实测：把setCharacterEncoding放在getParameter后面会怎样
很多初学JSP的同学习惯先把所有参数取出来，回头再加编码设置。我给你还原一下这个经典翻车现场：
<% // 错误示范：先取值，后设置编码 String username = request.getParameter("username"); request.setCharacterEncoding("UTF-8"); // 此时已经晚了 out.println("你好，" + username); %>这么写，getParameter()先被调用，Tomcat此时按照默认编码（旧版本Tomcat是ISO-8859-1）读取并解码了请求体，把每个中文字符都解成了两个独立的乱码字符。等你去设置UTF-8时，数据已经“固化”了，你再怎么设置都无济于事。
所以这里最稳妥的习惯不是“记得放在getParameter前面”，而是放在整个JSP页面脚本代码的最顶部，最好紧跟page指令之后。原因很简单：你无法保证页面后面哪一行代码会最先触发参数读取，与其纠结顺序，不如强制统一。我在带团队时定的规矩就是：所有接收参数的JSP或Servlet，第一行必须先设置编码，谁违反谁review不过。
3.3 一个容易被忽略的开关：CharacterEncodingFilter过滤器
如果你的项目已经到了能用Filter的程度（比如基于Servlet规范开发，或者干脆用了Spring MVC），那么官方推荐的做法不是在每一个Servlet里反复写setCharacterEncoding，而是注册一个字符编码过滤器：
<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>注意forceEncoding这个参数要设为true。Spring的CharacterEncodingFilter在forceEncoding=true时，会把request的编码设置和response的编码设置同时强制执行。如果漏了这个参数，某些情况下response还是用的容器默认编码，照样可能出现响应乱码。这个细节我以前踩过，因为默认值是false。
4. GET乱码的三层修复思路：从最底层配置到代码兜底
4.1 改变Tomcat默认URI编码：一劳永逸但需要环境权限
GET参数是拼在URL里的，而URL的解码由Tomcat的Connector负责。所以最直接的修复方式，是让Tomcat在解析URL时就使用UTF-8。在Tomcat的conf/server.xml里，找到Connector节点，加上URIEncoding属性：
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" />加了这一行之后，Tomcat解析请求行里的参数时，统一按UTF-8解码。这样你的request.getParameter()在GET场景下拿到的就是正确的中文，不需要写任何额外代码。
关于这个配置，有几个版本差异你需要知道：Tomcat 8.0及以上版本默认就是URIEncoding="UTF-8"，所以新版本环境里GET一般不乱码；而Tomcat 7及更早版本默认是ISO-8859-1，GET参数一到手就是乱的。很多旧教程教你的“必须修改server.xml才能解决GET乱码”，本质上是基于老版本的默认行为。如果你用的是新版本Tomcat，不需要改也行；但如果在老版本容器上部署，这一行仍然是最彻底的方案。
4.2 不改服务器配置的代码兜底方案：ISO-8859-1还原法
如果项目部署在现场，你没有权限修改Tomcat的server.xml，或者容器根本不由你控制，那还有一套纯代码层面的兜底方案。
原理是这样的：在旧版本Tomcat默认配置下，Tomcat已经把URL中的字节按ISO-8859-1解码成了Java字符串。ISO-8859-1是单字节编码，每个字节都会被无损耗地映射成一个Unicode字符（码点范围0~255）。这反而给了我们一个机会：既然字节没有丢，我们只要拿到这个字符串，反推出原始字节，再用UTF-8重新解码，就能还原出正确的中文。
具体代码如下：
<% String keyword = request.getParameter("keyword"); if (keyword != null) { // 反推原始字节：把ISO-8859-1解出来的字符串还原成字节 byte[] bytes = keyword.getBytes("ISO-8859-1"); // 再用UTF-8重新解码 keyword = new String(bytes, "UTF-8"); } out.println("你搜索的是：" + keyword); %>这个方法在默认ISO-8859-1的旧Tomcat环境下非常有效。但要注意，如果你的Tomcat已经改成了UTF-8默认编码，再用这套方案就会把原本正确的中文字符按ISO-8859-1反推，反而变成乱码。所以这是兜底方案，不是通用方案——用之前务必先确认当前容器的URIEncoding是什么。
4.3 最好的GET方式：提交彻底避免歧义
说实话，对于包含中文的GET请求，从工程实践角度看，最优解往往是避免让浏览器直接拼接中文字符。
一是把表单method设为post，让参数走请求体，交给setCharacterEncoding处理。二是如果必须用GET（比如分享一个链接），可以显式对参数做URL编码：
<a href="show.jsp?keyword=<%= URLEncoder.encode("手机", "UTF-8") %>">搜索手机</a>这样浏览器实际上收到的是形如keyword=%E6%89%8B%E6%9C%BA的纯ASCII字符串，不涉及任何中文歧义。服务器拿到后调用URLDecoder.decode(keyword, "UTF-8")即可还原。这个方法在不同容器、不同编码配置下都稳定，因为编码行为被显式固定了。
5. 响应乱码：request解对了，页面还是乱码怎么办
5.1 服务器输出到浏览器的编码链路
很多新手容易原地懵圈的一个场景是：request.getParameter()打印出来明明是对的，但把值写到页面上之后，浏览器又显示乱码。这说明问题不在请求方向，而在响应方向。
服务器把“你好”这个字符串输出给浏览器时，也要先编码成字节流；浏览器拿到字节流后，需要知道按什么编码来展示。如果服务器编码用UTF-8，浏览器却以为页面是GBK，同样的“编码解码不对称”问题会再一次出现。
JSP页面里那行经典声明，其实就是在同时管这两件事：
<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>pageEncoding告诉JSP容器，这个JSP文件本身是用什么编码保存的，容器编译这个文件时应该按什么编码去读它，决定“服务器把字符串编码成字节时”用什么编码；contentType里的charset会写进HTTP响应头Content-Type，告诉浏览器“我输出的字节应该按什么编码来解”。
如果你在JSP里动态输出内容，也可以手动设置响应编码：
<% response.setCharacterEncoding("UTF-8"); // 注意：setCharacterEncoding要在getWriter()之前调用才有意义 out.println("你好，" + username); %>这里有一个很容易踩的坑：如果同时调用setContentType("text/html;charset=UTF-8")和setCharacterEncoding("UTF-8")，顺序有讲究。setContentType会让charset同时覆盖response的编码，所以通常推荐先setCharacterEncoding，再setContentType，或者干脆只调用setContentType，让字符集跟着内容类型一起生效。我见过有同学写反了顺序，结果设置了半天，响应头里的charset还是旧的。
5.2 request和response一起检查的标准动作
结合上面的分析，一个稳健的JSP处理页面开头应该长这样：
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %> <% request.setCharacterEncoding("UTF-8"); response.setCharacterEncoding("UTF-8"); response.setContentType("text/html; charset=UTF-8"); String username = request.getParameter("username"); out.println("你好，" + username); %>我不是让你背这段代码，而是让你理解每一行的职责：
pageEncoding="UTF-8"：保证JSP文件本身按UTF-8编译；request.setCharacterEncoding("UTF-8")：保证POST请求体按UTF-8解码；response.setCharacterEncoding("UTF-8")：保证服务器输出流按UTF-8编码；response.setContentType("text/html; charset=UTF-8")：告诉浏览器按UTF-8展示页面。
四个动作，分别锁死了“文件读取、请求解码、响应编码、浏览器解码”四个环节。这四个环节全部对齐，乱码才真正从根上消失。
6. 一条从JSP到生产环境的编码自查清单
6.1 用一个表理清所有环节的编码职责
在实际项目中，我调试乱码问题从来不会去背代码片段，而是按这张表逐项排查：
| 环节 | 控制机制 | 常见默认值（旧Tomcat） | 常见默认值（新Tomcat） | 应该设置成 |
|---|---|---|---|---|
| JSP文件读取 | pageEncoding | 默认ISO-8859-1 | 默认ISO-8859-1 | UTF-8 |
| 响应Content-Type | contentType | 无明确charset | 无明确charset | text/html; charset=UTF-8 |
| POST请求体解码 | request.setCharacterEncoding | 无（按容器默认） | 无（按容器默认） | UTF-8 |
| GET请求URL解码 | Connector的URIEncoding | ISO-8859-1 | UTF-8 | UTF-8 |
| 动态输出编码 | response.setCharacterEncoding | ISO-8859-1 | ISO-8859-1 | UTF-8 |
排查乱码时，你完全可以按照“请求进来”的顺序，自上而下对照这张表：浏览器发起的编码对不对？Tomcat解析URL的编码对不对？request读请求体的编码对不对？服务器输出的编码对不对？浏览器显示页面的编码对不对？哪一环不对称，就修哪一环，修完再看效果。
6.2 生产环境的“组合拳”：页面、容器、过滤器一次配齐
如果你在搭建一个真实项目，而不是交作业，我强烈建议从一开始就把编码规范定死，而不是写到哪儿、乱到哪儿再去打补丁。我常用的标准配置是下面这套组合：
第一步，所有JSP页面的头部统一写：
<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>这是页面层的底线，保证JSP文件本身和浏览器展示都按UTF-8走。
第二步，如果是纯Servlet或自定义Filter的项目，写一个编码过滤器，对所有请求和响应强制设置：
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; req.setCharacterEncoding("UTF-8"); resp.setCharacterEncoding("UTF-8"); resp.setContentType("text/html; charset=UTF-8"); chain.doFilter(req, resp); }在web.xml里映射到/*。这样所有进入项目的请求，都在处理之前就被统一成了UTF-8，个别Servlet里写不写编码设置都不影响大局。
第三步，把Tomcat的Connector配置为UTF-8：
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" />以上三件事做完，你的项目从JSP文件、到请求解码、到响应输出、到浏览器展示，全链路都是UTF-8，后续就不用再被乱码问题反复折磨。
6.3 我实际调试乱码问题时的判断顺序
最后分享一个我调试乱码问题的实际操作顺序。遇到乱码，我不会立刻改代码、改配置，而是先确定“乱在哪个方向”：
- 打开浏览器开发者工具，看Network面板里请求头的
Content-Type，确认浏览器发出的编码； - 看响应头里的
Content-Type，确认服务器声明的编码； - 看页面顶层还是有部分区域乱码，判断是整个页面编码不对，还是只有动态参数不对；
- 动态参数不对，进一步判断是POST还是GET请求，分别走不同的解法；
- 全部排查完，再决定改页面、改请求、改响应还是改容器配置。
这个顺序帮我省了大量无效试错时间。乱码这种问题，代码本身通常没有“对错”之分，只有“跟环境配不配套”之分。理解背后的编码链路之后，你自然就能判断出该在哪个环节下刀。
我个人强烈建议，把这类问题当成理解HTTP请求处理流程的敲门砖。JSP内置对象其实是一套很好用的调试窗口：request能让你看到请求处理到哪个阶段，response能让你控制输出方向的行为。乱码虽然是个烦人的小问题，但顺着它把整条链路理清，你对JSP的生命周期、Tomcat的解析机制、编码体系的认识都会上一个台阶。以后遇到更复杂的字符集问题（比如数据库中文乱码、文件上传文件名乱码），你会发现自己已经具备了解决问题的底层框架，而不是到处复制粘贴代码。
