表示字段

Content-Type、Content-Encoding、Content-Language、Content-Location——描述消息体的四个字段。

表示（representation） = 元数据 + 数据。表示字段描述的是「体里装的是什么」，与「资源是什么」分开——同一资源可有多个表示（不同语言、不同编码）。

Content-Type

Content-Type = media-type
media-type   = type "/" subtype parameters
type         = token
subtype      = token

指明体的媒体类型。缺失时接收方 MAY 自行嗅探或按 application/octet-stream 处理。

Content-Type: text/html; charset=UTF-8

值大小写不敏感，取自 IANA 字符集注册表。
对 text/* 尤为关键：缺失时各实现的默认值不一致（历史默认 ISO-8859-1，现代浏览器多按 UTF-8 或嗅探），是乱码的首要成因。
application/json 不接受 charset 参数——RFC 8259 规定 JSON 必须是 UTF-8，写 charset=UTF-8 无效但无害。

multipart/* 必需，且大小写敏感：

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXYZ

服务端应始终发送准确的 Content-Type。浏览器的 MIME 嗅探会把 text/plain 的内容当 HTML 执行，造成 XSS——用响应字段 X-Content-Type-Options: nosniff 关闭嗅探（非 HTTP 核心规范，但属必备实践）。

Content-Encoding = #content-coding
content-coding   = token

指明体已被施加的内容编码，接收方需逆序解码才能得到原始表示。

值	说明
`gzip`	RFC 1952，LZ77 + CRC32。别名 `x-gzip`
`deflate`	RFC 1950 zlib 格式。历史实现混淆（有的发裸 deflate），兼容性差
`br`	Brotli，RFC 7932。文本压缩率优于 gzip
`zstd`	Zstandard，RFC 8878
`compress`	LZW，已废弃。别名 `x-compress`
`identity`	不编码。仅可用于 `Accept-Encoding`，不得出现在 `Content-Encoding`

关键性质：

端到端——代理不得擅自改动（与逐跳的 Transfer-Encoding 相反）。
编码是表示的一部分：ETag 针对编码后的字节，gzip 版与非 gzip 版必须有不同的 ETag，且响应须带 Vary: Accept-Encoding。
多个编码按应用顺序列出：Content-Encoding: gzip, br 表示先 gzip 再 br（罕见）。
Content-Length 计的是编码后的长度。
客户端不支持所收编码时无法恢复；请求体编码不被支持则服务端返回 415 + Accept-Encoding。

Content-Language = #language-tag

标注表示的目标受众语言（RFC 5646 语言标签，大小写不敏感）：

Content-Language: zh-CN
Content-Language: en, de

Content-Location = absolute-URI / partial-URI

给出该特定表示的直接 URI。相对引用以请求目标 URI 为基准解析。

与 Location 的区别（高频混淆）：

典型用途：/article 内容协商后返回中文版，带 Content-Location: /article.zh.html 告知该版本的固定地址。

注意：Content-Location 不改变请求的目标 URI，也不改变缓存键——缓存仍以请求 URI 存储。

这些字段出现在请求里时，描述的是请求体：

POST /upload HTTP/1.1
Content-Type: image/png
Content-Encoding: gzip
Content-Length: 20480

服务端处理规则：

下一篇：内容协商——Accept 系列字段与 q 值排序规则。