Accept-Charset 是什么
Accept-Charset 是历史遗留的请求头，用于声明客户端可接受的字符集。RFC 9110 §12.5.2 明确把它标为已弃用（deprecated）：UTF-8 成为事实标准后，按字符集协商响应已无实际意义，主流浏览器也不再发送它。新系统不应实现这套协商逻辑。
基本信息
| 名称 | Accept-Charset |
|---|---|
| 方向 | 请求头 |
| 规范 | RFC 9110 §12.5.2（deprecated） |
| 语法 | Accept-Charset: utf-8, iso-8859-1;q=0.5 |
| 现状 | 浏览器不再发送，服务器应忽略 |
| 真正权威的声明 | Content-Type 的 charset 参数 |
典型使用场景
- 老系统兼容排查：解释某些页面编码异常的原因
- 抓包分析：判断某个陌生请求头是否值得关注
- 新项目设计：明确不要实现字符集协商
- 编码问题定位：确认真正生效的是响应头里的 charset
- 迁移评审：清理历史遗留的多套编码分支
- 一致性检查：确认响应编码与内容一致，避免解析歧义
历史写法与现代做法
历史写法与现代做法
# 历史写法（现代浏览器不再发送该头）
Accept-Charset: utf-8, iso-8859-1;q=0.5
# 现在的做法：响应统一声明 UTF-8，并保证页面内声明一致
Content-Type: text/html; charset=utf-8
# 页面里保持同样的编码声明，避免两处不一致
# <meta charset="utf-8">编码相关的声明位置
| 位置 | 作用 | 现状 |
|---|---|---|
| Content-Type 的 charset | 响应实体编码 | 权威依据，必须与内容一致 |
| Accept-Charset | 请求声明可接受字符集 | 已弃用，服务器应忽略 |
| 页面内的 meta charset | HTML 内声明编码 | 应与响应头保持一致 |
| Content-Encoding | 压缩编码，如 gzip | 与字符集无关 |
Content-Encoding 管压缩、Content-Type 的 charset 管字符编码，两者常被混为一谈；乱码看 charset，传输体积看 Content-Encoding。
只在个别老客户端上必须支持转码时，建议在响应层统一 UTF-8，避免为兼容维护多套编码分支。
服务端忽略 Accept-Charset 属于符合规范的做法，不必为它做特殊处理。
编码不一致的典型症状是乱码与截断，排查时先确认响应头与页面内声明是否一致。
老系统的编码问题往往叠加了数据库连接字符集与模板渲染等多层因素，单看请求头很难定位。