accept-charset基本无效，仅当页面无且HTTP响应头缺失charset时才可能被参考；现代项目普遍声明UTF-8，浏览器直接忽略该属性，实际提交编码由页面编码决定。
别设 accept-charset，它基本不生效，还容易误导你排查方向。
为什么 accept-charset 几乎没用
这个属性只在页面完全没声明编码时（既无 ，HTTP 响应头也缺失 charset=）才可能被浏览器参考。而现代项目几乎都明确写了 ，此时浏览器直接忽略 accept-charset 的值——哪怕你写成 accept-charset="GBK"，它照样按 UTF-8 提交。
常见误判现象：
- 后端收到乱码，第一反应去改
accept-charset，结果毫无变化 - 写
accept-charset="UTF-8, GBK"以为能“自动降级”，但浏览器根本不认逗号分隔（HTML5 要求空格），且不会切换编码 - 在 IE/Edge 里设
ISO-8859-1却发 Windows-1252 字节，属于历史兼容 bug，不可靠
怎么验证表单实际提交的编码
打开 DevTools → Network → 找到对应 POST 请求 → 看两处原始数据：
-
Headers标签页里查Content-Type是否含charset=utf-8（application/x-www-form-urlencoded默认不带 charset，以页面编码为准） -
Payload或Form Data标签页里看中文是否显示为%E4%BD%A0%E5%A5%BD（UTF-8）还是%C4%E3%BA%C3（GBK）
这才是唯一可信的判断依据，比检查 accept-charset 属性值管用十倍。
真正该统一的三处地方
删掉所有 accept-charset，盯紧以下三点：
- HTML 页面顶部必须有且仅有一个
，放在最前面（不能被注释或 JS 动态插入） - HTTP 响应头必须包含
Content-Type: text/html; charset=UTF-8；Nginx 配charset utf-8;，Apache 配AddDefaultCharset UTF-8 - 后端解析时显式指定 UTF-8：
body-parser设encoding: 'utf8'，PHP 检查default_charset = "UTF-8"，Spring Boot 启用CharacterEncodingFilter
enctype 和 accept-charset 的关系
accept-charset 对不同 enctype 的影响完全不同：
-
enctype="application/x-www-form-urlencoded"（默认）：只影响表单字段值的 URL 编码字节，由页面编码决定，accept-charset无效 -
enctype="multipart/form-data"：只影响Content-Disposition中的filename字段编码，不影响字段值本身；多数浏览器仍按页面编码处理 -
enctype="text/plain"：规范未定义行为，各浏览器实现不一，accept-charset无实际作用
GET 表单的 URL 查询参数编码也不受 accept-charset 控制，它取决于浏览器对当前页面编码的理解。
复杂点在于：前后端编码链路上任何一环脱节（比如 Nginx 把 UTF-8 响应转成了 Latin-1，或前端用 new FormData() + fetch 却没设 Content-Type 头导致自动切 multipart），都会造成乱码——而这些和 accept-charset 完全无关。
