accept-charset仍被支持但作用有限，仅在页面无明确字符编码声明时作为fallback机制生效；现代浏览器优先遵循或HTTP Content-Type头中的编码，它并非强制指令而是兼容性补丁。
form 元素的 accept-charset 属性是否还管用？
在现代浏览器中，accept-charset 仍被支持，但它的实际作用非常有限——它只影响表单提交时对非 UTF-8 字符的编码 fallback 行为，且仅当页面本身没有声明明确的字符编码（比如缺失 <meta charset="UTF-8">）时才可能生效。绝大多数情况下，浏览器会优先遵循文档的 charset 声明或 HTTP Content-Type 头中的编码信息。
所以别指望靠它“强制”改提交编码；它更像一个兼容性补丁，不是控制开关。
真正起决定作用的是页面本身的字符编码声明
表单提交使用的编码，99% 由 HTML 文档的字符编码决定。只要页面正确声明了 UTF-8，所有文本输入（包括中文、emoji、特殊符号）都会以 UTF-8 编码提交：
<meta charset="UTF-8">
这个 <meta> 标签必须放在 中，且越早越好（最好在第一行）。如果服务器返回的 HTTP 头里有 Content-Type: text/html; charset=GBK，那它会覆盖 <meta>，此时页面和提交都会走 GBK —— 这就是为什么本地打开 HTML 文件（无服务器）时 <meta> 尤其关键。
立即学习“前端免费学习笔记（深入）”；
- 用
curl -I或浏览器开发者工具的 Network → Headers 查看响应头里的charset - 避免在
里混用多个<meta charset>，后者不会覆盖前者 - 如果后端是 PHP，确保文件本身保存为 UTF-8 无 BOM 格式，否则
$_POST可能乱码
POST 提交时 enctype 会影响编码行为吗？
会，但只影响二进制数据的封装方式，不改变文本字段本身的字符编码逻辑：
-
enctype="application/x-www-form-urlencoded"（默认）：文本字段按页面编码 URL 编码，如name=%E4%BD%A0%E5%A5%BD -
enctype="multipart/form-data"：每个字段单独传输，文本部分仍遵循页面编码，但多了一个charset参数可显式声明（例如Content-Disposition: form-data; name="title"; filename="a.txt"; charset=utf-8），不过浏览器基本不填这个，服务端也不依赖它 -
enctype="text/plain"：仅用于调试，空格变空格、换行保留，不编码，但不推荐用于生产
也就是说：enctype 不是用来“选编码”的，而是“怎么打包”的选择。
后端接收时常见乱码根源在哪？
前端编码没问题，但后端拿到的是乱码，大概率卡在以下环节：
- Java Servlet：没调
request.setCharacterEncoding("UTF-8")，尤其 GET 请求需额外处理 URL 解码 - Node.js（原生）：
req.body是原始 Buffer，需手动toString('utf8')或用body-parser并配encoding: 'utf8' - Python Flask：默认用 UTF-8，但如果 Nginx 配置了
charset GBK，可能污染响应头，间接干扰客户端解析 - 数据库连接：MySQL 的
character_set_client和collation_connection若不是utf8mb4，存进去就变形
最易忽略的一点：表单提交是 UTF-8，但后端读取请求体时用了系统默认编码（如 Windows 的 GBK）解码——这比前端设置错更隐蔽，也更难排查。
