表单提交乱码是html编码声明、表单序列化规则、http请求头、服务端解码四者不一致导致的连锁反应；需确保前端页面charset、accept-charset（仅对非multipart post/get有效）、enctype行为、后端解码方式严格匹配，ajax则由js完全控制编码。
表单提交乱码不是单一环节的问题，而是 HTML 编码声明、表单序列化规则、HTTP 请求头、服务端解码四者不一致导致的连锁反应。直接写 accept-charset="UTF-8" 或只改后端 setCharacterEncoding("UTF-8") 都可能无效。
form 的 enctype 决定数据怎么打包，不是字符集
enctype 控制的是「字段如何被组织进请求体」，和字符编码无关：
-
enctype="application/x-www-form-urlencoded"：默认值，所有字段名/值做 URL 编码（如中文变%E4%BD%A0），拼成键值对字符串；它依赖页面或accept-charset指定的字符集来决定“先按什么编码把文字转字节，再 URL 编码” -
enctype="multipart/form-data"：每个字段独立分块，原样传输字节，accept-charset完全被忽略；此时字符集由浏览器按页面<meta charset>或响应头推断，但后端必须用 multipart 解析器（如 Java 的request.getPart()，Node.js 的multer）才能拿到文本字段 -
enctype="text/plain"：几乎不用，不编码空格和换行，服务端极难解析，且不参与字符集协商
accept-charset 是后备机制，不是强制指令
accept-charset 只在以下条件同时满足时起作用：
- 表单以
GET或POST提交（非 AJAX） - 未通过
enctype="multipart/form-data"覆盖 - HTTP 请求头中未显式设置
Content-Type字符集（比如没手动加charset=UTF-8）
它本质是告诉浏览器：“如果页面本身编码和后端期望不一致，请优先按这个来编码字段值”。例如页面是 <meta charset="GBK">锛屼絾鍚庣
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
