http标头中非ascii值的当前状态? [英] Current state of non-ascii values in http headers?

问题描述

我们有一个国际客户询问有关Safari的某些行为

We had an international customer ask about some Safari behavior of

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

我们还没有测试过pdf书写功能的国际使用，他们发现Safari对它们的表现很奇怪.今天开始对我进行一次迷你冒险之旅.

We hadn't been testing international uses of our pdf writing functions, and they saw Safari behaving oddly for them. That started off a mini-odyssey for me today looking into this.

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

Specifically, when the customer had Safari on a mac configured for English, our Japanese-named pdf saved just fine (with the default behavior of Asp.Net/IIS, serializing that field as raw utf-8). But when they configured their browser to be in Japanese, the file name came out as each serialized utf-8 character being treated as Ascii.

一些快速使用Google搜索功能的人引用了很多有关Rfc5987和Rfc8187的内容，并在这里和其他地方发表了很多关于如何相对于Content-Disposition实现的文章:filename = ...

Some quick googling got piles of references to Rfc5987 and Rfc8187 and lots of posts here and elsewhere on how those get implemented vis a vis Content-Disposition: filename=...

问题很多，这些帖子来自2007-2015年.

Problem is a lot of those posts are from 2007-2015.

我开始在最新的Chrome版本，最新的Firefox版本，IE 11和Edge(我没有配备Safari的Mac)上尝试许多Rfc5987/8187实施建议，以下是我发现的内容:

I started trying out a lot of those Rfc5987/8187 implementation suggestions on the latest Chrome build, the latest Firefox build, IE 11 and Edge (I don't have a mac with Safari handy) and here's what I found:

• IE11和Edge可以识别filename =是否经过url编码并对其进行解码.其他浏览器不会.
• Mac上的IE11，Edge和Safari(以英语配置)将接受filename = raw utf-8，并将其正确处理为日语名称
• Safari(使用日语配置)以及Firefox和Chrome将采用filename = raw utf-8作为一串ascii字符
• 不是一个浏览器我已经实现了Rfc5987/8187的任何一个.不是功能.

• IE11 and Edge will recognize if filename= is url encoded and decode it. Other browsers won't.
• IE11, Edge, and Safari on mac (configured in English) will accept filename= raw utf-8 and will process it properly to a Japanese name
• Safari (configured with Japanese) and Firefox and Chrome will take filename = raw utf-8 as a string of ascii characters
• Not one browser I have implemented any of Rfc5987/8187. Not a feature.

我尝试过

• filename = [URL编码版本] .pdf;
• filename * = utf-8''[URL编码版本] .pdf(在小写字母不起作用时也为UTF-8)
• filename = [原始和网址编码] .pdf;filename * = utf-8''[URL编码] .pdf

在我手头的所有浏览器中，文件名*值都被完全忽略.filename = ...;filename * =将; filename * = ...运行到生成的文件名中.

Just filename* values were completely ignored in all the browser I had on hand. filename=...; filename*= ran the ;filename*=... into the resulting filename.

简而言之，没有一个浏览器可以实现Rfc 8187的任何版本.

In short not a single browser of the 4 appeared to implement any bit of Rfc 8187.

但是我看到了对Asp.Net Core(我们目前不使用)的引用，在其ContentDispositionHeader对象模型中有一个FileNameStar成员，所以让我认为必须实现Rfc 8187.

But I've seen references to Asp.Net Core (which we don't currently use) having a FileNameStar member in their ContentDispositionHeader object model, so that makes me think something out there must be implementing Rfc 8187.

但是我见过的所有帖子似乎在2015年左右都消失了，我发现其中的所有内容似乎都无法在可用的浏览器中正常工作.

But all of the posts I've seen seem to peter out around 2015 and none of the things I find in them appear to be working in the browsers I have available.

对于如何让浏览器处理Content-Disposition中的国际字符集(文件名=值)，还有人有什么新想法吗?

Does anyone have any more current ideas on how to get browsers to process international character sets in Content-Disposition: filename= values?

我的意思是，到目前为止，人们报告的唯一问题是将Firefox和Safari配置为 not 美国英语.在许多情况下，仅仅做自然而然的事情似乎是可行的.

I mean, so far the only problems people have reported are with Firefox and Safari configured to something not US English; just doing what comes naturally seems to be working in a lot of situations.

但是很高兴知道如何正确地"做到这一点.

But it would be nice to know how to do it "correctly."

编辑:我尝试过的输出示例

examples of output I tried

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

没有浏览器正确读取.所有人都只是将下载"替换为名称.

No browser read that correctly. All just substituted "download" as the name.

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的文件

All browsers tested produced a file named "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)尝试了上述所有方法.

Also tried all of the above with UTF-8 instead of utf-8.

谢谢

推荐答案

所有当前的浏览器都实现RFC 8187-您可能做错了.如果您发布了由代码生成的示例字段值，将会很有帮助.

All current browsers implement RFC 8187 - you probably did something wrong. It would be helpful if you posted an example field value generated by your code.

这篇关于http标头中非ascii值的当前状态?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！