表单中文参数乱码主因是前后端编码链路不统一：浏览器按UTF-8 URL编码（如%E4%B8%AD%E6%96%87），而Tomcat默认用ISO-8859-1解码；须在server.xml的Connector中添加URIEncoding="UTF-8"并重启，且HTML文件、响应头、meta charset三者必须同为UTF-8。
表单中文参数乱码，不是前端没写 meta charset="UTF-8"，而是这个声明只管页面渲染和键盘输入的原始字节来源，不直接控制表单提交时的编码行为——真正起作用的是表单数据打包方式（enctype）和浏览器对非 ASCII 字符的 URL 编码逻辑，两者必须和后端解码链路对齐。
form 的 enctype 属性决定 POST 数据怎么打包
enctype 不是“字符编码”，而是数据序列化格式。它直接影响中文参数能否被完整、无损地送入请求体：
-
application/x-www-form-urlencoded（默认）：把中文转成%E4%B8%AD%E6%96%87这类 URL 编码，但前提是页面本身是 UTF-8 编码（靠meta charset="UTF-8"保证），否则输入框里打的“你好”可能一开始就是 GBK 字节，再编码就错上加错 -
multipart/form-data：每个字段单独封装，中文作为原始字节流传输，不经过 URL 编码；但必须配合<input type="file">才有意义，纯文本字段用它反而增加解析负担 -
text/plain：几乎不用；空格变空行，中文直接裸传，服务端极难可靠解析
注意：enctype 只对 method="POST" 生效；GET 表单永远走 URL 编码，不受此属性影响。
accept-charset 属性能覆盖页面编码，但很少需要
accept-charset 写在 <form></form> 标签上，告诉浏览器“这个表单里的所有输入值，按这个字符集去编码”，优先级高于 meta charset。但它实际作用有限：
立即学习“前端免费学习笔记（深入）”；
- 如果页面已经是
UTF-8，且没写accept-charset，浏览器就用 UTF-8 编码表单值 - 如果写了
accept-charset="GBK"，而页面是 UTF-8，用户输入的中文会被强制按 GBK 解释成字节，再 URL 编码 —— 后端若按 UTF-8 解，必然乱码 - 现代开发中基本不用它；统一用
meta charset="UTF-8"+ UTF-8 文件保存 + 后端 UTF-8 解码更可靠
GET 表单中文乱码，99% 是 Tomcat connector 没配 URIEncoding
GET 提交的中文参数出现在 URL 查询字符串里（如 ?name=%E4%B8%AD%E6%96%87），浏览器发出去前已用 UTF-8 编码，但 Tomcat 默认用 ISO-8859-1 解——这就是乱码根源：
- 改
$CATALINA_HOME/conf/server.xml里的<connector></connector>，加URIEncoding="UTF-8"（必须是大写短横，不能是utf-8或UTF8） - Spring Boot 用户在
application.properties加server.tomcat.uri-encoding=UTF-8 -
request.setCharacterEncoding("UTF-8")对 GET 完全无效，别浪费时间
这个配置必须重启服务器才生效，改完不重启等于没改。
文件保存编码、HTTP 响应头、meta charset 必须三者一致
哪怕表单逻辑全对，只要这三个地方有一个是 GBK，中文参数就可能在某个环节被错误重解释：
- HTML 文件本身要存为 UTF-8（VS Code 选 “Save with Encoding → UTF-8”，**不要选 “UTF-8 with BOM”**；BOM 会干扰某些老 WebView）
- HTTP 响应头要有
Content-Type: text/html; charset=UTF-8（Nginx 加charset utf-8;，Express 用res.set("Content-Type", "text/html; charset=utf-8")） -
<meta charset="UTF-8">必须放在最开头（<meta charset="UTF-8"> <title></title>），否则可能被前 1024 字节外的 BOM 或注释干扰
最容易被忽略的是文件实际编码和编辑器显示编码不一致——VS Code 左下角显示 “UTF-8”，不代表文件真是 UTF-8；用 file -i index.html 看真实编码，比编辑器界面更可信。
