accept-charset在现代浏览器中基本失效，因Chrome、Firefox等均强制用UTF-8编码application/x-www-form-urlencoded表单，仅IE7/8及极少数代理场景下有效；可靠方式是JavaScript手动控制编码并配合服务端解码。
不是被忽略，而是多数现代浏览器根本不会按它发送非 UTF-8 编码的表单数据 —— 即使你写了，实际发出的请求体大概率仍是 UTF-8。
为什么
在现代浏览器中基本失效
HTML5 规范已明确：当
没有显式设置
时，浏览器默认使用文档的字符编码（通常是 UTF-8）；但即使你设置了其他值（如
或
），主流浏览器（Chrome、Firefox、Safari、Edge）在提交
表单时，仍会把所有字段统一按 UTF-8 编码发送。
这是为了兼容服务器端普遍只处理 UTF-8 的现实，也避免因编码不一致导致乱码或解析失败。
仅在极老版本 IE（如 IE7/8）中，
对
有实际影响
对
类型，
完全无作用 —— 文件名和字段值编码由浏览器自主决定，且通常也是 UTF-8
如果页面本身是 UTF-8（
），浏览器更不会“倒退”去用 GBK 编码表单数据
还有没有实际用途
有，但非常有限，仅存在于两个边缘场景：
服务端明确要求接收 GBK 编码的
请求（例如某些遗留 Java Web 系统未配置
），此时可配合后端强制解码逻辑使用，但需前端额外干预（比如用
+
+
手动构造 GBK 字节流 —— 不推荐）
部分老旧代理或 WAF 设备会检查该属性并据此调整解码策略（极少见，且不可靠）
换句话说：**别指望靠它切换编码，它现在主要是个“向后兼容的装饰性属性”。**
真正可控的编码控制方式是什么
想确保表单以特定编码提交，唯一可靠路径是绕过原生表单提交，改用 JavaScript 手动控制：
用
获取字段，再用
构造查询字符串（默认 UTF-8）
若必须 GBK，需借助
（仅 UTF-8）或第三方库（如
）将字符串转为 GBK 字节，再用
发送
服务端必须明确声明接受该编码，并做对应解码（例如 Node.js 中用
）
注意：
的
是二进制安全的，但
对非 UTF-8 字符串支持不稳定，容易静默转码。
实际开发中，坚持全栈 UTF-8 是成本最低的选择；一旦引入
并依赖它生效，往往意味着你在对抗浏览器默认行为，而这种对抗几乎总是失败的 —— 尤其当用户用 Chrome 90+ 或 Safari 15+ 时，那个属性连调试器里都看不到实际影响。
accept-charset="GBK"accept-charsetaccept-charset"GBK""ISO-8859-1"application/x-www-form-urlencodedaccept-charsetapplication/x-www-form-urlencodedmultipart/form-dataaccept-charsetaccept-charsetx-www-form-urlencodedCharacterEncodingFilterFormDataBlobFileReadernew FormData(form)URLSearchParamsTextEncodericonv-litefetchArrayBuffericonv.decode(buf, 'gbk')fetchbodyXMLHttpRequest.send()accept-charset