想要强制下载资源而不是直接在Web浏览器中呈现资源的Web应用程序在表单的HTTP响应中发出Content-Disposition报头:

Content-Disposition:附件;filename = filename

filename参数可用于建议浏览器将资源下载到的文件的名称。然而,RFC 2183 (Content-Disposition)在2.3节(文件名参数)中规定文件名只能使用US-ASCII字符:

当前[RFC 2045]语法限制 参数值(因此 内容-处置文件名)到 us - ascii。我们认可伟大的 允许任意的可取性 文件名中的字符集,但它是 超出了本文档的范围 定义必要的机制。

然而,有经验证据表明,目前大多数流行的Web浏览器似乎允许非us - ascii字符,但(由于缺乏标准)在文件名的编码方案和字符集规范上存在分歧。问题是,如果文件名“naïvefile”(不带引号,第三个字母是U+00EF)需要编码到Content-Disposition报头中,那么流行的浏览器采用了哪些不同的方案和编码?

为了解决这个问题,流行的浏览器是:

谷歌Chrome Safari Internet Explorer或Edge 火狐 歌剧


当前回答

我最终在“download.php”脚本中编写了以下代码(基于这篇博文和这些测试用例)。

$il1_filename = utf8_decode($filename);
$to_underscore = "\"\\#*;:|<>/?";
$safe_filename = strtr($il1_filename, $to_underscore, str_repeat("_", strlen($to_underscore)));

header("Content-Disposition: attachment; filename=\"$safe_filename\""
.( $safe_filename === $filename ? "" : "; filename*=UTF-8''".rawurlencode($filename) ));

只要只使用iso-latin1和“safe”字符,就使用标准的filename="…";如果不是,它会添加文件名*=UTF-8 " url编码的方式。根据这个具体的测试用例,它应该从MSIE9起,并在最近的FF, Chrome, Safari;在较低的MSIE版本中,它应该提供包含ISO8859-1版本的文件名,在非此编码的字符上使用下划线。

最后注意:最大值。在apache上,每个报头字段的大小为8190字节。UTF-8每个字符最多可以有四个字节;在rawurlencode之后,每个字符是x3 = 12字节。非常低效,但理论上仍然可以在文件名中有超过600个“smiles”%F0%9F%98%81。

其他回答

我通常对文件名进行url编码(使用%xx),它似乎在所有浏览器中都可以工作。你还是得做些检查。

在提议的RFC 5987“超文本传输协议(HTTP)报头字段参数的字符集和语言编码”中对此进行了讨论,包括浏览器测试和向后兼容性的链接。

RFC 2183表示这样的报头应该根据RFC 2184进行编码,RFC 2184已被RFC 2231废止,上面的RFC草案涵盖了这一点。

我最终在“download.php”脚本中编写了以下代码(基于这篇博文和这些测试用例)。

$il1_filename = utf8_decode($filename);
$to_underscore = "\"\\#*;:|<>/?";
$safe_filename = strtr($il1_filename, $to_underscore, str_repeat("_", strlen($to_underscore)));

header("Content-Disposition: attachment; filename=\"$safe_filename\""
.( $safe_filename === $filename ? "" : "; filename*=UTF-8''".rawurlencode($filename) ));

只要只使用iso-latin1和“safe”字符,就使用标准的filename="…";如果不是,它会添加文件名*=UTF-8 " url编码的方式。根据这个具体的测试用例,它应该从MSIE9起,并在最近的FF, Chrome, Safari;在较低的MSIE版本中,它应该提供包含ISO8859-1版本的文件名,在非此编码的字符上使用下划线。

最后注意:最大值。在apache上,每个报头字段的大小为8190字节。UTF-8每个字符最多可以有四个字节;在rawurlencode之后,每个字符是x3 = 12字节。非常低效,但理论上仍然可以在文件名中有超过600个“smiles”%F0%9F%98%81。

以下文件链接自Jim在回答中提到的RFC草案,进一步解决了这个问题,在这里值得直接注意:

HTTP内容处理头和rfc2231 /2047编码的测试用例

只是一个更新,因为我今天为了回应一个客户的问题而尝试了所有这些东西

With the exception of Safari configured for Japanese, all browsers our customer tested worked best with filename=text.pdf - where text is a customer value serialized by ASP.Net/IIS in utf-8 without url encoding. For some reason, Safari configured for English would accept and properly save a file with utf-8 Japanese name but that same browser configured for Japanese would save the file with the utf-8 chars uninterpreted. All other browsers tested seemed to work best/fine (regardless of language configuration) with the filename utf-8 encoded without url encoding. I could not find a single browser implementing Rfc5987/8187 at all. I tested with the latest Chrome, Firefox builds plus IE 11 and Edge. I tried setting the header with just filename*=utf-8''texturlencoded.pdf, setting it with both filename=text.pdf; filename*=utf-8''texturlencoded.pdf. Not one feature of Rfc5987/8187 appeared to be getting processed correctly in any of the above.