应设为utf-8（全大写带连字符），仅当页面编码与期望提交编码不一致时才需显式设置，否则浏览器优先遵循或http头声明的编码，accept-charset仅为后备机制且在multipart/form-data中完全无效。
accept-charset 该设成什么值才有效
直接写 UTF-8 就行，但必须全大写带连字符：UTF-8，不是 utf8、utf-8（小写）或 UTF8。浏览器只认标准 IANA 字符集名称，UTF-8 是唯一被广泛支持的通用编码。其他如 GBK、ISO-8859-1 虽然语法合法，但现代页面基本不用，且服务端未必能正确解析。
form 提交时编码实际由谁决定
accept-charset 只是提示浏览器“用这个编码序列化表单数据”，真正起作用的前提是：表单内没有 <input> 或 <textarea></textarea> 的 name 属性含非 ASCII 字符，且页面本身 <meta charset> 或 HTTP Content-Type 声明了编码。否则浏览器会忽略 accept-charset，直接按页面编码提交。
- 页面声明了
<meta charset="UTF-8">→ 浏览器默认用 UTF-8 编码，accept-charset可省略 - 页面是 GBK 编码，但表单想强制用 UTF-8 → 必须显式写
accept-charset="UTF-8"，否则中文会双编码乱码 - 用了
method="get"→ 查询字符串在 URL 中，编码更敏感，accept-charset影响更明显
常见错误：乱码却查不到原因
典型现象是后端收到一堆 %E4%BD%A0%E5%A5%BD（UTF-8 URL 编码）但解出来是乱码，或直接出现 符号。这时候不是 accept-charset 没生效，而是：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 前端页面文件保存为 ANSI/GBK，但 meta 声明了
UTF-8→ 浏览器按声明解析 HTML，但表单输入框内容实际以 GBK 编码提交 - 后端没做
request.setCharacterEncoding("UTF-8")（Java）或没配encoding: utf8（Node.js body-parser）→ 解码阶段就错了 - 用了
enctype="multipart/form-data"→accept-charset完全无效，文件上传字段的文本参数编码由浏览器自主决定，不可控
要不要加 accept-charset 属性
绝大多数现代项目不需要显式设置：<form></form> 标签不写 accept-charset，只要页面是 UTF-8 编码（HTML 文件存为 UTF-8 + <meta charset="UTF-8">），提交就是安全的。加了反而容易因大小写或拼写出错引入问题。唯一需要加的场景是：页面编码和期望提交编码不一致，比如遗留系统页面是 GBK，但后端 API 只接受 UTF-8 表单数据。
这时候写 accept-charset="UTF-8" 是补救手段，但更推荐统一改为 UTF-8 页面编码——这才是根治方式。临时加属性容易漏测边界情况，比如含 file 类型 input 的表单，或者动态插入的字段。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
