首页 > 解决方案 > http标头中非ASCII值的当前状态?

问题描述

我们有一位国际客户询问了一些 Safari 的行为

Content-Disposition: attachment; filename=<customer file name>.pdf

我们没有测试我们的 pdf 书写功能在国际上的使用,他们发现 Safari 对他们来说表现得很奇怪。这开始了我今天研究这个的迷你奥德赛。

具体来说,当客户在配置为英语的 mac 上安装 Safari 时,我们的日语命名的 pdf 保存得很好(使用 Asp.Net/IIS 的默认行为,将该字段序列化为原始 utf-8)。但是当他们将浏览器配置为日语时,文件名显示为每个序列化的 utf-8 字符都被视为 Ascii。

一些快速的谷歌搜索得到了对 Rfc5987 和 Rfc8187 的大量引用,以及这里和其他地方的大量帖子,这些帖子是关于如何通过 vis Content-Disposition: filename=...

问题是很多这些帖子都是从 2007 年到 2015 年。

我开始在最新的 Chrome 版本、最新的 Firefox 版本、IE 11 和 Edge 上尝试了很多 Rfc5987/8187 实施建议(我没有带 Safari 的 mac),这就是我发现的:

我试过了

在我手头的所有浏览器中,只是 filename* 值被完全忽略了。文件名=...; 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 尝试了上述所有方法。

谢谢

标签: asp.nethttputf-8safari

解决方案


很抱歉误报...原来获取数据的客户端代码正在使用 jquery ajax 调用,而读取标头的客户端代码做得不好。

我必须追踪并增强客户端解析器代码。


推荐阅读