【发布时间】：2026-02-06 20:10:01
【问题描述】：
我们有一位国际客户询问了一些 Safari 的行为
Content-Disposition: attachment; filename=<customer file name>.pdf
我们没有测试过我们的 pdf 书写功能在国际上的使用，他们发现 Safari 对他们来说表现得很奇怪。这开始了我今天研究这个的迷你奥德赛。
具体来说，当客户在 Mac 上配置了英文版的 Safari 时，我们的日文 pdf 保存得很好（使用 Asp.Net/IIS 的默认行为，将该字段序列化为原始 utf-8）。但是当他们将浏览器配置为日语时，文件名显示为每个序列化的 utf-8 字符都被视为 Ascii。
一些快速的谷歌搜索得到了大量对 Rfc5987 和 Rfc8187 的引用，以及这里和其他地方的大量帖子，这些帖子是关于如何通过 Content-Disposition 实现的：filename=...
问题是其中很多帖子都是 2007-2015 年的。
我开始在最新的 Chrome 版本、最新的 Firefox 版本、IE 11 和 Edge（我没有带 Safari 的 mac）上尝试了很多 Rfc5987/8187 实施建议，这就是我发现的：
- IE11 和 Edge 将识别 filename= 是否为 url 编码并对其进行解码。其他浏览器不会。
- Mac 上的 IE11、Edge 和 Safari（以英文配置）将接受 filename= raw utf-8 并将其正确处理为日文名称
- Safari（用日语配置）和 Firefox 和 Chrome 将 filename = raw utf-8 作为 ascii 字符的字符串
- 不是一个浏览器我已经实现了任何 Rfc5987/8187。不是功能。
我试过了
- filename=[url 编码版本].pdf;
- filename*=utf-8''[url 编码版本].pdf（当小写不工作时也是 UTF-8）
- filename=[原始和 url 编码].pdf;文件名*=utf-8''[url 编码].pdf
在我手头的所有浏览器中，完全忽略了文件名* 值。文件名=...; filename*= 将 ;filename*=... 运行到生成的文件名中。
简而言之，这 4 个浏览器中没有一个浏览器实现了 Rfc 8187 的任何部分。
但我已经看到对 Asp.Net Core（我们目前不使用）的引用在其 ContentDispositionHeader 对象模型中有一个 FileNameStar 成员，所以这让我觉得肯定有一些东西在实现 Rfc 8187。
但我看到的所有帖子似乎都在 2015 年左右逐渐消失，我在其中找到的所有内容似乎都无法在我可用的浏览器中运行。
是否有人对如何让浏览器处理 Content-Disposition: filename= values 中的国际字符集有更多最新想法？
我的意思是，到目前为止，人们报告的唯一问题是 Firefox 和 Safari 配置为不是美国英语；只做自然而然的事情似乎在很多情况下都有效。
但如果知道如何“正确”地做到这一点，那就太好了。
编辑：我尝试过的输出示例
Content-Disposition: attachment; filename*=utf-8''%e6%8e%a1%e7%94%a8%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e5%90%84%e7%a8%ae%e6%9b%b8%e9%a1%9e.pdf
没有浏览器正确读取。都只是将“下载”替换为名称。
Content-Disposition: attachment; filename=Fred.pdf; filename*=utf-8''%e6%8e%a1%e7%94%a8%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e5%90%84%e7%a8%ae%e6%9b%b8%e9%a1%9e.pdf
所有测试的浏览器都生成了一个名为“Fred.pdf; filename*=utf-8''blahblahblah”的文件
Content-Disposition: attachment; filename="Fred.pdf"; filename*=utf-8''%e6%8e%a1%e7%94%a8%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e5%90%84%e7%a8%ae%e6%9b%b8%e9%a1%9e.pdf
同上例。
还使用 UTF-8 而不是 utf-8 尝试了上述所有方法。
谢谢
【问题讨论】：