我们有一个国际客户询问一些Safari的行为
Content-Disposition: attachment; filename=<customer file name>.pdf
我们没有测试过我们的pdf书写功能的国际用途,他们看到Safari对他们表现得很奇怪。对我来说,这开始了一个迷你奥德赛。
具体来说,当客户在配置为英语的mac上使用Safari时,我们日语命名的pdf保存得很好(使用Asp.Net/IIS的默认行为,将该字段序列化为原始utf-8)。但是当他们将浏览器配置为日语时,文件名就会出现,因为每个序列化的utf-8字符都被视为Ascii。
一些快速的谷歌搜索引用了大量的参考Rfc5987和Rfc8187和许多帖子在这里和其他地方如何实现如何实现内容 - 处置:filename = ...
问题是很多帖子都来自2007-2015。
我开始尝试在最新的Chrome版本,最新的Firefox版本,IE 11和Edge(我没有带有Safari的mac)的Rfc5987 / 8187实施建议,这就是我发现的:
我试过了
在我手边的所有浏览器中,只有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。
谢谢
所有当前的浏览器都实现了RFC 8187 - 您可能做错了什么。如果您发布了代码生成的示例字段值,将会很有帮助。
抱歉,误报...原来客户端代码获取数据是使用jquery ajax调用,读取头文件的客户端代码没有做得好。
我不得不追踪并增强客户端解析器代码。