表单中文乱码是浏览器编码、传输解码、服务端解析三者不一致导致的连锁反应；必须从前端meta charset="UTF-8"（位置靠前、无BOM）、HTTP响应头Content-Type: text/html; charset=UTF-8、后端request.setCharacterEncoding("UTF-8")（POST）或Tomcat URIEncoding="UTF-8"（GET）三方面严格对齐UTF-8，缺一不可。
直接说结论：表单中文乱码不是单一环节出错，而是浏览器编码、传输解码、服务端解析三者不一致导致的连锁反应；必须从前端声明、传输路径、后端配置三个层面同步对齐 UTF-8，缺一不可。
HTML 页面必须显式声明 meta charset="UTF-8"
这是整个链路的起点，没它，后面全白搭。很多乱码问题其实就卡在这一步。
-
meta标签必须写在<head>内且**位置靠前**（最好紧贴<head>开始，前面不能有注释或空行） - 只认
UTF-8（带短横、大写 U/T/F，小写无效；utf8、UTF8、utf-8都不行） - 确保 HTML 文件本身是 UTF-8 编码保存，且**不含 BOM**（VS Code 保存时选 “UTF-8” 而非 “UTF-8 with BOM”）
- 如果用 Nginx/Apache/Express 等服务器托管，还需确认 HTTP 响应头
Content-Type: text/html; charset=UTF-8已生效（优先级高于meta，但两者必须一致）
GET 请求乱码只能靠 Tomcat 的 URIEncoding="UTF-8"
request.setCharacterEncoding("UTF-8") 对 GET 参数完全无效——它只管 POST 请求体，不管 URL 查询字符串。URL 解码发生在 Servlet 接收请求之前，由 Tomcat connector 层完成。
- 必须修改
$CATALINA_HOME/conf/server.xml中的<Connector>标签，添加属性：URIEncoding="UTF-8" - 不是
encoding，不是useBodyEncodingForURI，也不是uriEncoding（大小写敏感） - 改完必须重启 Tomcat；Spring Boot 内嵌 Tomcat 则配
server.tomcat.uri-encoding=UTF-8 - 手动转码如
new String(param.getBytes("ISO-8859-1"), "UTF-8")是临时补丁，易漏、难维护，不解决根本
POST 请求要确保 request.setCharacterEncoding() 生效
这个调用看似简单，但极易因执行时机或前置操作失效。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 必须在第一次调用
request.getParameter()、getInputStream()或getReader()**之前** 执行 - 不能写在获取参数之后，也不能写在 Filter 中但被其他 Filter 提前读了 body
- 推荐统一用 Filter 处理：
if ("POST".equalsIgnoreCase(request.getMethod())) { request.setCharacterEncoding("UTF-8"); } - Spring MVC 用户应启用
CharacterEncodingFilter，并设forceEncoding=true，否则仅对 request body 生效，不强制 response
移动端和 AJAX 场景下 accept-charset 基本不可靠
现代浏览器（Chrome/Firefox）忽略 <form accept-charset="UTF-8">；iOS Safari 和部分 Android WebView 对它的支持极差，甚至 fallback 到 ISO-8859-1 或 GBK，反而加剧乱码。
- 不要依赖
accept-charset控制编码，它只是历史遗留属性 - JS 发起的
fetch()或XMLHttpRequest默认用 UTF-8 编码 body，但需确保后端响应头也带charset=UTF-8 - 用
FormData提交时无需额外处理；拼接URLSearchParams时encodeURIComponent()默认 UTF-8，也无需改 - 真正关键的是：HTML 页面本身的
meta+ 服务器响应头 + 后端解码配置三者严格对齐
最容易被忽略的一点：乱码常出现在“局部刷新”或“HTMX/AJAX 替换片段”场景里——此时新 HTML 片段可能没带 meta charset，或服务端返回时漏了 Content-Type 头。只要片段 HTML 不独立声明编码，浏览器就会沿用主页面的解析逻辑，一旦主页面编码异常或片段被错误缓存，乱码立刻复现。
