accept-charset属性指定表单提交时字段值的字符编码，值为空格或逗号分隔的编码列表，浏览器按序选用首个能表示所有字符的编码；仅影响请求体编码，不作用于url或页面渲染。
form 元素的 accept-charset 属性怎么用
HTML5 表单默认使用页面的字符编码（通常是 UTF-8），但如果你的后端接收逻辑依赖特定编码（比如旧系统要求 GBK 或 ISO-8859-1），就得显式控制表单提交时的编码方式。accept-charset 就是干这个的，它告诉浏览器：「用这些编码之一来序列化表单字段」。
注意：accept-charset 不影响页面渲染或输入框内显示，只影响 POST 或 GET 提交时字段值的字节编码。
-
accept-charset值是空格或逗号分隔的编码列表，浏览器按顺序尝试，选第一个能表示所有输入字符的编码 - 如果没设，浏览器用文档的
charset（即<meta charset="UTF-8">或 HTTPContent-Type中的charset） - 常见写法：
accept-charset="UTF-8"、accept-charset="GBK ISO-8859-1"
为什么设置了 accept-charset 还乱码
典型现象：表单提交中文，后端收到的是 %C4%E3%BA%C3 类似乱码，或直接变成问号、方块。这通常不是 accept-charset 没生效，而是前后端编码约定不一致。
- 后端没按表单声明的编码解码——比如前端设了
accept-charset="GBK"，但后端用 UTF-8 解包请求体 - HTTP 请求头中
Content-Type缺失或错误，例如漏掉charset=GBK（对application/x-www-form-urlencoded影响不大，但对multipart/form-data很关键） - 服务器配置强制转码，如 Nginx 的
charset指令或 Apache 的AddDefaultCharset -
accept-charset对GET请求的 URL 编码无效——URL 查询参数始终按文档编码处理，该属性只作用于请求体
enctype 和 accept-charset 的关系
enctype 决定表单数据如何打包，accept-charset 决定文本字段值用什么编码转成字节。两者配合才有意义。
立即学习“前端免费学习笔记（深入）”；
-
enctype="application/x-www-form-urlencoded"（默认）：字段名和值都经 URL 编码，accept-charset控制原始字符串到字节的编码步骤 -
enctype="multipart/form-data"：每个字段单独封装，此时accept-charset仅影响文本字段的Content-Disposition参数编码（如filename），不控制字段值本身；值的编码由字段内容决定（例如文件二进制原样上传） -
enctype="text/plain"：几乎不用，且accept-charset对其无效（规范未定义行为）
<form action="/submit" method="post"
accept-charset="UTF-8"
enctype="application/x-www-form-urlencoded">
<input name="msg" value="你好">
<button type="submit">发送</button>
</form>
现代项目里其实很少需要手动设 accept-charset
除非你必须对接老系统或非标准后端，否则统一用 UTF-8 是最稳妥的选择。现在主流框架（Django、Spring Boot、Express）默认按 UTF-8 解析表单，只要确保：
- HTML 页面声明
<meta charset="UTF-8"> - 后端不覆盖请求编码（如 PHP 的
mb_internal_encoding('UTF-8')） - 数据库连接也用 UTF-8（比如 MySQL 的
utf8mb4） - 避免在 JS 中用
encodeURI()或encodeURIComponent()手动编码后再提交——这会双重编码
真正容易被忽略的是：表单里混入了通过 JS 动态插入的字段，而这些字段的值来自非 UTF-8 来源（比如旧版 Excel 导出的 CSV），这时光靠 accept-charset 无法挽救，得在 JS 层预处理。
