表单中文乱码根本原因是链路中任一环编码不一致导致字节错解；最常见的是浏览器utf-8编码的%e4%bd%a0被tomcat默认iso-8859-1错误解为%c4%e3，须统一html页面（meta+文件+bom+响应头）、form accept-charset、tomcat uriencoding及后端处理逻辑。
表单提交后中文乱码，根本不是“前端没写 accept-charset”或“后端没设编码”单点问题，而是整个链路中任意一环的编码声明/处理不一致导致的字节错解。最常见的情况是：你看到 %E4%BD%A0（正确 UTF-8 URL 编码），却收到 %C4%E3（ISO-8859-1 解出来的错误结果）——这说明请求在抵达 Servlet 之前，就已经被中间某层按错误编码解释过了。
检查 HTML 页面本身的编码声明是否生效
很多开发者以为写了 <meta charset="UTF-8"> 就万事大吉，但这个标签必须满足三个硬性条件才真正起作用：
-
<meta charset="UTF-8">必须出现在标签内，且位于前 1024 字节中（浏览器只扫描开头这部分） - HTML 文件本身保存为纯 UTF-8（不含 BOM）。VS Code 默认“UTF-8 with BOM”，会导致
ef bb bf出现在文件头，使<meta>失效，浏览器 fallback 到 ISO-8859-1 - 服务器返回的 HTTP 响应头
Content-Type不能覆盖它。例如 Nginx 配置了charset gbk;，哪怕页面写了 UTF-8 meta，也会被强制覆盖
验证方式：curl -I https://yoursite.com/form.html 看响应头是否有 Content-Type: text/html; charset=UTF-8；再用 head -c 3 index.html | xxd 确认无 ef bb bf；最后在 Chrome DevTools 的 Network → Headers → Response Headers 里双重确认。
form 元素的 accept-charset 在移动端基本不可靠
iOS Safari 完全忽略 accept-charset，直接 fallback 到页面当前编码（也就是上面那个 <meta> 声明的编码）；Android WebView（尤其旧 ROM）可能继承系统默认 GBK，即使写了 accept-charset="UTF-8" 也无效。
所以不要依赖它做兼容保障。正确做法是：
- 确保页面本身是 UTF-8（文件 + meta + HTTP 头三者统一）
-
<form accept-charset="UTF-8"></form>可以写，但仅作语义提示，小写、只写UTF-8（utf8或UTF8无效） - 如果必须支持老 Android WebView，且无法控制服务器配置，可考虑 JS 拦截 submit，用
URLSearchParams手动拼 query string 并fetch()提交，绕过 form 自动编码逻辑
Java 后端 request.setCharacterEncoding() 对 POST body 无效
这是最容易踩的坑：request.setCharacterEncoding("UTF-8") 只影响 getParameter() 系列方法读取的 URL-encoded 数据（比如 application/x-www-form-urlencoded），对 multipart/form-data（含文件上传）完全无效。
如果你用的是 <input type="file"> 或 FormData 提交，后端拿到的中文乱码，根本不是编码设置问题，而是：
- Tomcat 的
URIEncoding="UTF-8"对 POST body 无作用 -
getParameter()在 multipart 场景下返回 null 或乱码，必须改用getPart()或第三方库（如 Apache Commons FileUpload）解析原始流 - Spring MVC 的
CharacterEncodingFilter默认也不处理 multipart，需额外配置MultipartResolver并确保其底层使用 UTF-8 解析
简单验证：打印 request.getContentType()，如果是 multipart/form-data; boundary=...，就别再调 setCharacterEncoding() 了——它不会生效。
GET 请求的中文乱码必须从 Tomcat connector 入手
GET 参数在 URL 中，Tomcat 默认用 ISO-8859-1 解码，request.setCharacterEncoding() 完全无效。修复只有一条路径：
- 修改
server.xml中的<connector></connector>标签，显式添加URIEncoding="UTF-8" - 重启 Tomcat（不重启不生效）
- 注意：这个设置只对 GET 的 URL 查询参数有效，不影响 POST body
如果无法修改服务器配置（如云托管环境），唯一退路是前端对 GET 参数手动两次编码：encodeURIComponent(encodeURIComponent("你好"))，后端再用 URLDecoder.decode(param, "UTF-8") 解两次——但这属于补丁，不是正解。
真正难搞的从来不是某个函数怎么调，而是你不知道哪一层偷偷把字节当成了别的编码来读。尤其是混合了 form submit、AJAX、FormData、文件上传、Nginx 转发、Tomcat connector、Spring Filter 的场景，每一层都可能独立决定用什么编码去解释同一段字节。排查时一定要分清：这是 URL 解码问题？HTTP body 解析问题？还是 multipart boundary 识别失败导致整个请求体被当作文本流粗暴读取？
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
