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