如何在HTTP中编码Content-Disposition头文件名参数？

@TomZ:我在IE7和IE8中测试过,结果发现我不需要转义撇号(').你有失败的例子吗？

@Dave Van den Eynde:根据RFC6266将两个文件名组合在一行上除了Android和IE7 + 8之外,我已更新代码以反映这一点.感谢您的建议.

@Thilo:不知道GoodReader或任何其他非浏览器.使用Android方法可能会有一些运气.

@Alex Zhukovskiy:我不知道为什么,但正如在Connect上所讨论的那样,它看起来效果不是很好.

没有可互操作的方法来编码非ASCII名称Content-Disposition.浏览器兼容性很乱.

使用UTF-8 的理论上正确的语法Content-Disposition非常奇怪:( filename*=UTF-8''foo%c3%a4是的,这是一个星号,除了中间的空单引号外没有引号)

这个标题有点不太标准(HTTP/1.1规范承认它存在,但不要求客户端支持它).

有一个简单且非常强大的替代方法:使用包含所需文件名的URL.

当最后一个斜杠后面的名称是你想要的名字时,你不需要任何额外的标题!

这个技巧有效:

/real_script.php/fake_filename.doc

如果您的服务器支持URL重写(例如mod_rewrite在Apache中),那么您可以完全隐藏脚本部分.

URL中的字符应为UTF-8,逐字节urlencoded:

/mot%C3%B6rhead   # motörhead

在提出的RFC 5987 "用于超文本传输​​协议(HTTP)标头字段参数的字符集和语言编码"中讨论了这一点,包括浏览器测试和向后兼容性的链接.

RFC 2183表明此类标头应根据RFC 2184进行编码,RFC 2184已被上述RFC草案所涵盖.

RFC 6266描述了" 在超文本传输​​协议(HTTP)中使用内容 - 处置标头字段 ".引用:

6.国际化考虑因素

使用[ RFC5987 ]中定义的编码的" filename*"参数(第4.3节)允许服务器传输ISO-8859-1字符集之​​外的字符,还可以选择指定正在使用的语言.

在他们的示例部分中:

此示例与上面的示例相同,但添加"filename"参数是为了与未实现RFC 5987的用户代理兼容 :

Content-Disposition: attachment;
                     filename="EURO rates";
                     filename*=utf-8''%e2%82%ac%20rates

注意:那些不支持RFC 5987编码的用户代理filename*在" filename" 之后发生时忽略" ".

在附录D中,还有一长串建议可以提高互操作性.它还指向一个比较实现的站点.适用于常见文件名的当前全通测试包括:

attwithisofnplain:带有双引号且无编码的普通ISO-8859-1文件名.这需要一个文件名,该文件名都是ISO-8859-1,并且不包含百分号,至少不在十六进制数字前面.

attfnboth:上述顺序中的两个参数.应该适用于大多数浏览器上的大多数文件名,尽管IE8将使用" filename"参数.

这RFC 5987又引用了RFC 2231,它描述了实际的格式.2231主要用于邮件,5987告诉我们哪些部分也可用于HTTP标头.不要将此与multipart/form-dataHTTP 主体内使用的MIME标头混淆,后者由RFC 2388(特别是第4.4节)和HTML 5草案管理.

以下文件与Jim在他的回答中提到的RFC草案相关联,进一步解决了这个问题,这里绝对值得直接注意:

HTTP Content-Disposition标头和RFC 2231/2047编码的测试用例

在asp.net mvc2我使用这样的东西:

return File(
    tempFile
    , "application/octet-stream"
    , HttpUtility.UrlPathEncode(fileName)
    );

我想如果你不使用mvc(2)你可以使用编码文件名

HttpUtility.UrlPathEncode(fileName)

我使用以下代码片段进行编码(假设fileName包含文件的文件名和扩展名,即:test.txt):

PHP:

if ( strpos ( $_SERVER [ 'HTTP_USER_AGENT' ], "MSIE" ) > 0 )
{
     header ( 'Content-Disposition: attachment; filename="' . rawurlencode ( $fileName ) . '"' );
}
else
{
     header( 'Content-Disposition: attachment; filename*=UTF-8\'\'' . rawurlencode ( $fileName ) );
}

fileName = request.getHeader ( "user-agent" ).contains ( "MSIE" ) ? URLEncoder.encode ( fileName, "utf-8") : MimeUtility.encodeWord ( fileName );
response.setHeader ( "Content-disposition", "attachment; filename=\"" + fileName + "\"");

public static class HttpRequestMessageExtensions
{
    public static HttpResponseMessage CreateFileResponse(this HttpRequestMessage request, byte[] data, string filename, string mediaType)
    {
        HttpResponseMessage response = new HttpResponseMessage(HttpStatusCode.OK);
        var stream = new MemoryStream(data);
        stream.Position = 0;

        response.Content = new StreamContent(stream);

        response.Content.Headers.ContentType = 
            new MediaTypeHeaderValue(mediaType);

        // URL-Encode filename
        // Fixes behavior in IE, that filenames with non US-ASCII characters
        // stay correct (not "_utf-8_.......=_=").
        var encodedFilename = HttpUtility.UrlEncode(filename, Encoding.UTF8);

        response.Content.Headers.ContentDisposition =
            new ContentDispositionHeaderValue("attachment") { FileName = encodedFilename };
        return response;
    }
}

Content-Disposition: attachment; filename="My Report.doc"

$filename = $_GET['file']; //this string from $_GET is already decoded
if (strstr($_SERVER['HTTP_USER_AGENT'],"MSIE"))
  $filename = rawurlencode($filename);
header('Content-Disposition: attachment; filename="'.$filename.'"');

var fileName = 'my file(2).txt';
var header = "Content-Disposition: attachment; filename*=UTF-8''" 
             + encodeRFC5987ValueChars(fileName);

function encodeRFC5987ValueChars (str) {
    return encodeURIComponent(str).
        // Note that although RFC3986 reserves "!", RFC5987 does not,
        // so we do not need to escape it
        replace(/['()]/g, escape). // i.e., %27 %28 %29
        replace(/\*/g, '%2A').
            // The following are not required for percent-encoding per RFC5987, 
            // so we can allow for a little better readability over the wire: |`^
            replace(/%(?:7C|60|5E)/g, unescape);
}