accept-charset 属性实际很少起作用，仅在页面未声明编码时被参考；现代网页明确指定UTF-8后该属性被忽略，多值写法无效且浏览器不降级，乱码根源在于前后端编码不一致，应专注meta、HTTP头和后端解析三处统一UTF-8。
accept-charset 实际上很少起作用
它只在页面完全没声明自身编码时（既无 <meta charset>，HTTP Content-Type 头也没带 charset）才可能被浏览器参考。现代网页基本都明确指定了 UTF-8，此时 accept-charset 的值会被忽略——包括设成 GBK 或 ISO-8859-1，浏览器照样按页面实际编码（如 UTF-8）发送数据。
accept-charset="UTF-8, GBK" 这种写法无效
HTML5 规范要求多个值必须用空格分隔，逗号是错的；即使写成 accept-charset="UTF-8 GBK"，浏览器也不会“自动降级”到 GBK：它只会用页面当前编码提交，不会因服务端不支持 UTF-8 就改用 GBK。
- Chrome、Firefox 会直接忽略多值列表，只认第一个（如果页面本身是 UTF-8）
- IE/Edge 曾有特殊行为：设
accept-charset="ISO-8859-1"却发Windows-1252编码，属于历史兼容 bug - 服务端收到乱码，问题几乎从来不在这个属性，而在前后端编码约定不一致
验证表单实际提交编码的唯一可靠方式
打开浏览器 DevTools → Network → 找到对应 POST 请求 → 点开 “Headers” 查 Content-Type 头是否含 charset=...；再点开 “Payload” 或 “Form Data”，看原始字节值（比如中文显示为 %E4%BD%A0%E5%A5%BD 就是 UTF-8，%C4%E3%BA%C3 则是 GBK）。这比检查 accept-charset 属性值管用十倍。
真正该控制的地方在三处
删掉 accept-charset，专注以下三点：
立即学习“前端免费学习笔记（深入）”；
- HTML 页面顶部确保有
<meta charset="UTF-8"> - HTTP 响应头必须带
Content-Type: text/html; charset=UTF-8 - 后端解析时显式指定编码：Node.js 的
body-parser设encoding: 'utf8'，PHP 检查default_charset配置，Java Spring 启用CharacterEncodingFilter
accept-charset 是个容易让人误以为“设了就生效”的幻觉属性；实际生效的是页面元信息与服务端处理逻辑的一致性。
