RFC 5987与RFC 8187核心机制详解：HTTP头字段中的非ASCII字符传输

引言

在HTTP协议中，头字段（Header）是客户端与服务器交换元数据的关键载体。然而，在很长一段时间里，HTTP头字段的参数值被限制在ISO-8859-1字符集范围内，这意味着它只能表示基本的英文和西欧字符。这一限制给全球化的Web应用带来了一个非常实际的问题：当服务器试图通过Content-Disposition头告知浏览器一个包含中文、日文或特殊符号的文件名时，浏览器接收到的往往是一串乱码，或者干脆无法正确识别文件名。

为了解决这一痛点，互联网工程任务组（IETF）于2010年发布了RFC 5987，全称为”超文本传输协议（HTTP）头字段参数字符集与语言编码”（Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters）。该标准定义了一套规范的、向后兼容的机制，允许HTTP头字段的参数携带非ASCII字符，并能同时指明其使用的字符集和语言。

值得注意的是，RFC 5987本身已不再是现行标准。 2017年9月，IETF发布了RFC 8187，正式取代了RFC 5987，将其状态变更为”历史性”（Historic）。RFC 8187目前是”标准追踪”（Standards Track）文档，属于互联网拟议标准（Proposed Standard）。本文在阐述RFC 5987原始机制的基础上，也会重点说明RFC 8187带来的关键变化，因为后者才是当前实际应遵循的规范。尽管标准已更新，RFC 5987所定义的核心编码格式至今仍在各大浏览器和服务器中广泛使用，二者在语法格式上一脉相承。

编码格式解析

RFC 5987（以及继承其格式的RFC 8187）的核心思想是引入一种新的参数值表示法，通过特殊的语法结构来传达额外的元信息。其基本格式如下：

参数名*=字符集'语言'百分号编码后的值

这个格式由三个关键部分和一个特殊标识符组成，各部分之间用单引号（'）分隔：

1. 星号（*）标识符

参数名末尾的星号是区分普通参数和扩展参数的关键标志。当客户端（如浏览器）在响应头中看到filename*=而非filename=时，就会意识到这个参数值需要按照特殊规则进行解码处理。这种设计保证了向后兼容性：不理解该标准的旧客户端会忽略带星号的参数，转而读取不带星号的普通filename参数（如果服务器同时提供了两者的话）。

2. 字符集（Charset）

该字段指定了参数值所使用的字符编码。这是RFC 5987与RFC 8187的一个核心区别：

  • RFC 5987的原始要求：强制要求所有实现必须同时支持UTF-8和ISO-8859-1两种字符集。
  • RFC 8187的新规定：生产者（服务器）必须（MUST）使用UTF-8字符编码。扩展字符编码（mime-charset）虽然在语法上被保留以备将来使用，但实际发送方必须用UTF-8。同时，为了与旧代码兼容，接收端被鼓励（encouraged）也支持ISO-8859-1编码的解码。

在实际应用中，UTF-8因其对全球所有文字系统的全面支持而成为绝对主流，RFC 8187的更新正是对Web实际生态的确认和规范化。

3. 语言（Language）

这是一个可选字段，用于指定参数值的语言标签，其格式遵循BCP 47标准（如en代表英语，zh代表中文）。该字段可以为空（即两个单引号之间不写任何内容），此时语言信息被省略。语言标签的主要用途是帮助客户端进行本地化处理，例如在用户界面中选择合适的字体或进行文本排序，但在实际的文件名传输场景中，该字段常被留空。

4. 百分号编码后的值

这是实际内容的载体。其中所有的非ASCII字符必须使用百分号编码（Percent-Encoding）进行转义，而ASCII字符（字母、数字及特定安全字符）则可保持原样。

百分号编码的详细规则

百分号编码是RFC 5987/RFC 8187中最底层的转换机制，其规则看似简单，但细节处需要特别注意。具体编码过程如下：

对于参数值中的每一个字符，首先根据指定的字符集（按照RFC 8187应为UTF-8）将其编码为一个或多个字节，然后根据字节值的不同范围采取不同的处理方式：

  • 对于ASCII字母（A-Z，a-z）、数字（0-9）以及连字符（-）、点号（.）、下划线（_）、波浪号（~）这六个特殊字符：这些字符被视为安全字符，不进行编码，直接保留原样。
  • 对于其他所有字符（包括空格、标点符号及所有非ASCII字符）：将其每个字节转换为%HH的格式，其中HH是该字节的两位十六进制大写表示。

这一规则有一个非常重要的实际影响：文件扩展名（如.pdf、.txt）和常见的分隔符（如下划线）会被保留为可读形式，而不是被转换成冗长的百分号编码。这既保持了可读性，也减少了传输的数据量。

完整编解码流程演示

为了更直观地展示整个过程，我们以传输一个中文文件名年度报告.pdf为例，详细展示服务器端的编码流程和客户端解码流程。

服务器端编码流程

第一步：确定字符集
根据RFC 8187的强制要求，服务器选择UTF-8作为字符编码。若使用旧实现遵循RFC 5987，同样应优先选择UTF-8以确保最大兼容性。

第二步：对参数字符串进行字符集编码
将原始字符串年度报告.pdf按UTF-8编码转换为字节序列。其中每个中文字符在UTF-8中占用三个字节：

  • 年 → E5 B9 B4
  • 度 → E5 BA A6
  • 报 → E6 8A A5
  • 告 → E5 91 8A
  • .pdf → 2E 70 64 66（ASCII字符，保持不变）

第三步：执行百分号编码
按照百分号编码规则处理上述字节序列。非ASCII字节全部转换为%HH格式，而ASCII部分直接保留：

  • E5 B9 B4 → %E5%B9%B4
  • E5 BA A6 → %E5%BA%A6
  • E6 8A A5 → %E6%8A%A5
  • E5 91 8A → %E5%91%8A
  • .pdf → .pdf（直接保留）

最终得到的编码字符串为：%E5%B9%B4%E5%BA%A6%E6%8A%A5%E5%91%8A.pdf

第四步：组装完整的头字段
将参数名、字符集、语言和编码值按照格式拼接。本例中语言字段留空：

Content-Disposition: attachment; filename*=UTF-8''%E5%B9%B4%E5%BA%A6%E6%8A%A5%E5%91%8A.pdf

至此，服务器完成了全部的编码工作，可以把这个响应头发送给客户端。

客户端解码流程

当浏览器（或任何HTTP客户端）接收到上述响应头时，会按照以下步骤还原原始文件名。

第一步：识别扩展参数
客户端在解析Content-Disposition头时，发现filename参数名带有星号（filename*=），于是触发扩展参数解码逻辑。如果客户端同时发现了不带星号的普通filename参数，它会优先使用带星号的扩展版本。

第二步：解析三元组
客户端按顺序解析出三个组成部分：

  • 字符集：UTF-8
  • 语言：“（空字符串）
  • 编码值：%E5%B9%B4%E5%BA%A6%E6%8A%A5%E5%91%8A.pdf

第三步：百分号解码
客户端遍历编码值字符串，将所有%HH格式的三字符序列还原为对应的字节值，而未被编码的ASCII字符（如.pdf）则直接转换为对应的ASCII字节。经过此步骤，得到原始字节序列：

E5 B9 B4 E5 BA A6 E6 8A A5 E5 91 8A 2E 70 64 66

第四步：按字符集解码字节序列
客户端使用第一步解析出的字符集UTF-8，将上述字节序列解码为Unicode字符串。解码结果即为服务器期望传输的原始文件名：年度报告.pdf。

至此，客户端成功还原了包含非ASCII字符的文件名，整个过程无信息丢失。

RFC 8187对RFC 5987的完整变更清单

定性说明： RFC 8187并非对RFC 5987的重写或颠覆，而是一次精确化的更新。两者在核心编码机制（百分号编码格式、星号标识符、语言标签等）上完全一致。RFC 8187最重要的贡献是将字符集从”二选一”收紧为”强制UTF-8″，同时清理了HTTP上下文中不适用的MIME遗留特性。

变更总览

变更项RFC 5987（旧，已废弃）RFC 8187（新，现行标准）对开发者的影响
字符集要求发送方可选UTF-8或ISO-8859-1，接收方两者都得支持发送方必须用UTF-8，接收方至少支持UTF-8文件名统一用UTF-8编码，无需再纠结选哪个字符集
花括号允许出现在参数值中明确排除，不允许使用基本无影响（文件名里极少用花括号）
引号字符串参数值可用引号括起来明确禁止，必须用无引号形式不要写成 filename*="..."，写成 filename*=... 即可
参数延续支持长参数拆分成多段传输彻底移除无影响（HTTP场景下没人用这个功能）
编码词语言规范引入了部分MIME邮件头特性明确排除无影响（HTTP头里从未用过这个功能）

变更一：字符集要求收紧（核心变更）

这是RFC 5987与RFC 8187之间最本质的区别：

RFC 5987RFC 8187
发送方允许在UTF-8和ISO-8859-1之间二选一必须（MUST）使用UTF-8，别无选择
接收方必须同时支持UTF-8和ISO-8859-1解码必须支持UTF-8解码，同时被鼓励也支持ISO-8859-1解码（以兼容旧系统）

为什么这样改？

ISO-8859-1（Latin-1）是一个单字节字符集，总共只能表示256个字符，根本不支持中文、日文、韩文、阿拉伯文等绝大多数非西欧文字。如果服务器选择用ISO-8859-1传输中文文件名，结果是乱码或程序报错。所谓”二选一”在实践上是个伪选项——对于非西欧语言，你只能选UTF-8。RFC 8187只是把这个事实写进了规范，杜绝了选错的可能性。

对于英文文件名，ASCII本身就是UTF-8的子集，用UTF-8编码后字节序列完全一致，不需要额外处理，所以也不受影响。

变更二：排除花括号（{ 和 }）

在RFC 5987中，花括号被列为允许字符。但HTTP头字段的底层语法规则（定义在RFC 7230的token规则中）本身就不允许花括号出现在参数值里。RFC 8187所做的只是移除冲突项，让标准与HTTP底层语法保持一致。

对开发者的影响： 基本为零。文件名里极少用到花括号，即使用了，主流浏览器本来也不一定正确处理，本就不该用。

变更三：禁用引号字符串（quoted-string）

在旧规范中，扩展参数值既可以用无引号的token形式写，也可以用带引号的quoted-string形式写：

  • ✅ 允许：filename*=UTF-8''%E5%B9%B4%E5%BA%A6.pdf
  • ✅ 也允许：filename*="UTF-8''%E5%B9%B4%E5%BA%A6.pdf"

RFC 8187明确禁止带引号的写法，统一要求使用无引号形式：

  • ✅ 正确：filename*=UTF-8''%E5%B9%B4%E5%BA%A6.pdf
  • ❌ 错误：filename*="UTF-8''%E5%B9%B4%E5%BA%A6.pdf"

为什么这样改？ 保留两种写法会给HTTP解析器带来不必要的复杂性和歧义。统一成一种写法更清晰。

注意： RFC文档同时提到，”使用通用解析器的实现可能会在格式无效的情况下仍然接受带引号的格式”——这是一种务实措辞，意思是标准规定不该这么写，但现有软件可能仍然能读出来，不代表你可以这么发。

补充说明：什么是 RFC 7230 中的 token？

在理解”禁用引号字符串”这条变更时，需要先弄清楚一个基础概念——HTTP 协议中的 token 到底是什么。这一定义来自 RFC 7230（超文本传输协议/1.1：报文语法与路由），它是所有 HTTP 头字段解析的底层语法基础。

token 的定义

在 RFC 7230 中，token 被定义为一种最基本的语法单元，用于表示头字段中的简单值。它的规则是：

token 是一串不含分隔符（分隔符包括空格和各类标点符号）的字符序列。

更具体地说，一个合法的 token 只能包含以下字符：

  • 字母：A-Z，a-z
  • 数字：0-9
  • 特定符号：!、#、$、%、&、'、*、+、-、.、^、_、`、|、~

token 不允许的字符

以下字符被称为分隔符，它们不能出现在 token 中：

  • 空格
  • 引号 "
  • 括号 (、)
  • 花括号 {、}
  • 尖括号 <、>
  • 方括号 [、]
  • 等号 =
  • 逗号 ,
  • 分号 ;
  • 冒号 :
  • 斜杠 /
  • 问号 ?
  • @ 符号
  • 以及控制字符（不可打印的字符）

直观的例子

写法是否 token原因
text✅ 是纯字母
report.pdf✅ 是字母加 .，.在允许列表中
my-file✅ 是-在允许列表中
file_v2✅ 是_在允许列表中
"report.pdf"❌ 不是带引号，引号是分隔符
my file.pdf❌ 不是带空格，空格是分隔符
{id}❌ 不是花括号是分隔符
file=123❌ 不是=是分隔符
text/html❌ 不是/是分隔符

为什么 HTTP 要定义 token？

HTTP 头字段的格式是：

字段名: 字段值

其中，字段名本身必须是一个 token（所以 Content-Type 合法，而 Content Type 不合法，因为后者包含空格）。对于字段值，可以是一个 token，也可以是一个 quoted-string（带引号的字符串），具体取决于该字段的定义。

举个例子：

Content-Type: text/html
              ^^^^^^^^  ↑
              token     token

text 和 html 都是合法的 token。但如果字段值包含空格或特殊符号，就需要用引号括起来，比如：

Content-Disposition: attachment; filename="my file.pdf"
                                         ^^^^^^^^^^^^^^
                                         这是 quoted-string，不是 token

RFC 8187 为什么要引用 token 规则？

RFC 8187 在定义扩展参数格式时，借用了 RFC 7230 中的 token 概念。它规定扩展参数值必须满足 token 的语法要求，即：

  • 不能有空格
  • 不能有引号
  • 不能有分隔符

这就是为什么百分号编码的值（如 %E5%B9%B4%E5%BA%A6.pdf）是合法的——% 在 token 的允许列表中，它不包含空格、引号或分隔符。

如果参数值中包含空格，就必须先进行百分号编码，把空格转成 %20，这样整个字符串才是一个合法的 token。这正是百分号编码的另一个重要作用：把”不符合 token 规则”的原始内容，转换成”符合 token 规则”的形式。

对开发者的实际意义

了解 token 的规则后，就明白为什么 RFC 8187 强调”扩展参数值只能以 token 形式出现”了——因为 HTTP 底层语法只认 token 和 quoted-string 两种基本形式，而 RFC 8187 选择了 token 这一种，主动排除了 quoted-string，以此消除解析歧义。开发者只需记住：不要在扩展参数值外面加引号，也不要包含空格，如果不确定，用百分号编码就行了。

变更四：移除”参数延续”（Parameter Continuations）

这是从MIME（电子邮件）标准继承来的一个功能。在邮件系统中，单行头字段长度有限制（通常不超过998个字符），所以RFC 2231提供了一种机制：把一个很长的参数值拆成多段发送，接收端再拼接还原。

例如，长文件名可以拆成多行发：

filename*0*=UTF-8''%E5%B9%B4%E5%BA%A6
filename*1*=%E6%8A%A5%E5%91%8A.pdf

接收端把*0*、*1*按顺序拼接起来，得到完整的年度报告.pdf。

HTTP不需要这个功能，原因有三：

  1. HTTP头字段的实际长度限制远大于邮件系统（通常至少8KB），足够容纳绝大多数文件名。
  2. 这个机制实现极其复杂，却几乎没有实际使用场景。
  3. 没有任何主流的HTTP客户端或服务器实现过这个功能。

RFC 8187直接将其彻底移除，规定扩展参数必须单行完整传输，不允许分片。

变更五：移除”编码词中的语言规范”

在MIME标准中，有一种叫做encoded-word的格式（形如=?UTF-8?Q?=E5=B9=B4?=），它可以携带字符集和语言信息。RFC 5987从RFC 2231引入时，顺便把与这类格式相关的语言处理规则也带了进来。

问题是：HTTP头字段里从来没有正式支持过encoded-word格式，这个功能在HTTP的上下文里完全用不上。RFC 8187明确排除了这些规则，避免开发者混淆。

对开发者的影响： 你从未用过这个功能，以后也用不到，无需关心。

语言标签的特殊处理

虽然语言标签在实际的文件名传输中常被忽略，但标准对它的处理有明确的规定。在编码端，语言标签是一个可选字段，如果不需要指定语言，可以留空。在解码端，客户端应当正确解析语言标签，并在需要时将其用于本地化处理，但不应将其作为文件名的一部分。例如，如果一个头的值为filename*=UTF-8'zh'%E5%B9%B4%E5%BA%A6，解码后得到的文件名应为年度，而语言标签zh仅作为元数据使用，不会出现在最终的文件名中。

向后兼容性设计

扩展参数（带星号）的设计巧妙地解决了新旧系统并存的问题。服务器可以同时发送两个版本的参数：一个是传统的、不编码的filename参数（可能包含乱码或纯ASCII版本）；另一个是符合标准的filename*参数。支持新标准的客户端会自动识别并优先使用带星号的版本，而老旧客户端则会忽略带星号的参数，降级使用普通版本。这种渐进增强的策略使得标准能够在实际应用中平滑部署。

实践中的注意事项

了解标准的演进关系可以帮助开发者在实际项目中做出更好的技术决策：

  1. 服务器端应遵循RFC 8187：新实现应使用UTF-8作为字符集发送带星号的参数。如果仍使用ISO-8859-1，虽然部分客户端能解码，但不符合最新规范要求，可能在新环境中出现兼容性问题。
  2. 客户端应兼容两者：主流的浏览器和HTTP客户端库基本都已同时支持RFC 5987和RFC 8187的规范。即使服务器仍发送ISO-8859-1编码的旧格式，现代客户端通常也能正确解码。不过，UTF-8编码的参数能确保在所有现代客户端上获得一致的处理。
  3. 优先使用扩展参数：无论遵循哪个规范，只要参数值可能包含非ASCII字符，都应使用带星号（*）的扩展参数形式，而不是普通的filename参数。

结语

RFC 5987通过一套精心设计的编码机制，在不破坏HTTP协议基本语法和向后兼容性的前提下，优雅地解决了头字段参数传输非ASCII字符的长期难题。其核心的”字符集声明 + 百分号编码”组合既保持了通用性，又具备充分的扩展能力。随后的RFC 8187在此基础上进行了关键性更新，通过强制使用UTF-8和精简冗余特性，进一步规范了标准的实践路径，使国际化参数处理更加一致和可靠。理解这一机制的编解码细节及其演进脉络，对于Web开发人员正确实现文件下载功能、处理国际化内容具有重要的实践意义。如今，RFC 8187所定义的格式已成为现代Web应用中处理国际化HTTP头字段的事实标准。

作者

老丹

关注我
其他文章