实习的时候公司将一个某个关于下载的Bug交给了我来修，看了代码和日志后发现是Disposition字段的规范兼容性惹的锅，因为有些协议使用的是老协议，我们的项目没有对其进行兼容，最终我阅读RFC的规范参考Goole浏览器的源码将其解决。

Disposition头部字段介绍

Content-Disposition 是 HTTP 响应头（或请求头）中的一个字段，主要用于 控制客户端如何处理服务器返回的内容，例如：

是否直接显示内容（如浏览器内嵌显示 PDF）。
是否强制下载文件（弹出下载对话框）。
指定下载时的默认文件名。

语法格式：
```
Content-Disposition: inline | attachment; filename="filename.ext"
```
- inline：直接显示。
- attachment：强制下载。
- filename：关键参数，文件名。

RFC规范介绍

RFC是什么：

RFC（Request for Comments，征求意见稿） 是一系列由 互联网工程任务组（IETF, Internet Engineering Task Force） 发布的技术标准文档，用于定义互联网协议（如 TCP/IP、HTTP、DNS）、通信规范、API 设计等。RFC 文档是互联网基础设施的核心参考，许多网络协议和技术的实现都基于它们。

RFC的分类：

类型	说明	示例
标准（Standards Track）	正式成为互联网标准，如 TCP/IP、HTTP、SMTP。	RFC 793 (TCP)、RFC 9110 (HTTP/1.1)
实验性（Experimental）	尚未成熟的技术，可能被采纳或废弃。	RFC 2324 (HTCPCP，恶搞的“咖啡壶协议”)
信息性（Informational）	提供背景知识，非正式标准。	RFC 1855 (网络礼仪指南)
历史性（Historic）	已过时的协议或技术。	RFC 1149 (IP over Carrier Pigeon)
最佳实践（BCP, Best Current Practice）	推荐的操作方法，如安全实践。	RFC 6919 (DNSSEC 部署指南)

标题: “Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)”
发布: 2011年6月
状态: 现行标准（Proposed Standard）
核心作用:标准化HTTP响应头 Content-Disposition 的用法，用于指示浏览器如何处理服务器返回的内容（如直接显示或下载文件）。

当传输的filename是全英文时，使用filename参数直接用ASCII就能表示。

但是如果出现中英文混合，此时就无法表示了，所以它依赖RFC 5987。

作用:RFC6266 使用 RFC5987 定义的 filename* 参数格式来解决非ASCII文件名编码问题（如中文文件名）。其对非中文使用url encode+utf8转码的形式：
```
Content-Disposition: attachment; filename*=UTF-8''%E4%B8%AD%E6%96%87.txt
```

标题: “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text”
发布: 1996年11月
状态: 现行标准（Proposed Standard）
核心作用:
扩展电子邮件（MIME）头部字段，支持非ASCII字符（如中文、日文）的编码传输。

它处理中文的方式是将所有中文字符先转为Base64，然后加上特定的格式进行分段（如果太长）。

所以我们根据 RFC 2047 规范，对于被分割成多个编码段的连续文本，必须先合并所有分段内容，再进行整体解码，这是协议明确规定的强制性要求。

=?UTF-8?B?YW55?= =?UTF-8?B?IGNh?= =?UTF-8?B?cmU=?=

网易邮箱就是使用的RFC2027标准来传输下载附件时的filename。

Goole源码参考:如果你想要对上述协议的disposition标准都进行兼容，去模拟浏览器作为不同服务器的客户端，可以参考Goole源码的解决办法，它是严格按照协议上的规范来处理的。