转：HTTP ---HTTP头的编码问题（Content-Disposition）

最近在作项目时遇到了一个 case ：须要实现一个强制在浏览器中的下载功能（即强制让浏览器弹出下载对话框），而且文件名必须保持和用户以前上传时相同（可能包含非 ASCII 字符）。 前一个需求很容易实现：使用 HTTP Header 的 Content-Disposition: attachment 便可，还能够配合 Content-Type: application/octet-stream 来确保万无一失。然后一个需求就比较蛋疼了，牵扯到 Header 的编码问题（文件名是做为 filename 参数放在 Content-Disposition 里面的）。众所周知， HTTP Header 中的 Content-Type 能够指定内容的编码，可 Header 自己的编码又该如何制定？甚至， Header 到底是否容许非 ASCII 编码呢？ 若是听任编码问题无论，那么恭喜你，你必定会遇到在某个系统及浏览器下下载文件时文件名乱码的状况。若是你尝试搜索解决，那么再一次恭喜你，你会找到一堆自相矛盾的解决方案（我能够负责任地告诉你，其中的99%都是不符合标准的 trick 罢了）。让咱们来看看到底应该如何优雅完美地解决这个问题吧！ 为了探索这个问题，我走了很多弯路。从本身尝试，到 Google 、百度（分别尝试过中英文搜索），再到阅读 Discuz 等经典项目的源码，众说纷纭、莫衷一是。最后我才想到回归 RFC ，从标准文档中找办法，果真有所收获。因为探究过程实在太曲折，我就先把标准作法写下来。

应该这样设置 Content-Disposition ：

Content-Disposition: attachment;
                      filename="$encoded_fname";
                      filename*=utf-8''$encoded_fname

其中，$encoded_fname指的是将 UTF-8 编码的原始文件名按照  RFC 3986 进行百分号 urlencode 后获得的（ PHP 中使用 rawurlencode() 函数）。这几行也能够合并为一行，推荐使用一个空格隔开。 另外，为了兼容 IE6 ，请保证原始文件名必须包含英文扩展名！

好了，接下来咱们来看看为何要这么作以及为何能这么作。 首先，根据 HTTP 1.1 协议规范（ RFC 2616 Section 4 ）， HTTP 消息格式实际上是基于古老的 ARPA INTERNET TEXT MESSAGES （ RFC 822 Section 3 ），根据其规定，消息只能是 ASCII 编码的。 RFC 2616 Section 2.2 又一次强调， TEXT 中若要使用其余字符集，必须使用 RFC 2047 的规则将字符串编码为 ASCII 码（事实上这个规则本来是针对 MIME 的扩展，使用的是 base64 编码，格式与百分号编码有很大不一样）。总而言之，按照标准， HTTP Header 中的文本数据必须是 ASCII 编码的。

filename="TEXT"
 ;这是 RFC 2616 标准，TEXT必须是 ASCII 字符且被认为就是“原文”
filename*=charset'lang'encoded-text
 ;这是按照 RFC 2047 扩展后的，注意格式上的细微区别，采用 base64 编码（编码结果也是 ASCII 字符）

然而，事实上在1999年 HTTP 1.1 标准推出之时， Content-Dispostion 这个 Header 尚不是正式标准的一部分，只不过是由于被普遍使用而从 MIME 标准中直接借用过来了而已（ RFC 2616 Section 19.5.1 ）。于是几乎没有浏览器去支持 Content-Disposition 的多语言编码特性这样一个“扩展特性的扩展特性”（事实上， HTTP 1.1 草案中建议的使用 RFC 2047 来进行多语言编码的特性从未被主流浏览器支持过）。 但是这个问题却的确是现实须要的，因此浏览器就各自想出了一些办法：

• IE支持两种格式的混合版：filename="encoded_text" （这里采用的是百分号编码）。原本按照 RFC 2616 ，引号内的部分应当直接被看成内容，就算它“看起来像是编码后的字符串”；但是IE却会“自动”对这样的文件名进行解码——前提是该文件名必须有一个不会被编码的后缀名（即正常的英文字母后缀名）！
• 其余一些浏览器则支持一种更为粗暴的方式——容许在 filename="TEXT" 中直接使用 UTF-8 编码的字符串！

这两类浏览器的行为是彼此互不兼容的。因此你能够判断 UA 而后对IE使用前一种办法，其余浏览器使用后一种，这样即可以达到通常状况下可以 just work 的效果（ Discuz 就是这么作的）。不过对于 Opera 和 Safari ，这样作可能不必定有效。 时代在进步，2010年 RFC 5987 发布，正式规定了 HTTP Header 中多语言编码的处理方式，应当采用相似 MIME 扩展的 parameter*=charset'lang'value 的格式，可是其中 value 应根据 RFC 3986 Section 2.1 使用百分号进行编码，而且规定浏览器至少应该支持 ASCII 和 UTF-8 。随后，2011年 RFC 6266 发布，正式将 Content-Disposition 归入 HTTP 标准，并再次强调了 RFC 5987 中多语言编码的方法，还给出了一个范例用于解决向后兼容的问题——就是我在一开始给出的例子：

Content-Disposition: attachment;
                      filename="encoded_text";
                      filename*=utf-8''encoded_text

在这个例子中，对于较新的 Firefox 、 Chrome 、 Opera 、 Safari 等浏览器，都支持新标准规定的 filename* ，而且会优先使用，因此尽管 filename=”encoded_text” 不被它们支持，仍然不会有问题；至于使用 UTF-8 只是由于它是标准中强制要求必须支持的。而对于旧版本的IE浏览器，它们没法识别后面的 filename* ，会自动忽略并使用旧的 filename 。这样一来就完美解决了多浏览器的多语言兼容问题，既不须要 UA 判断，也符合标准。 P.S. 为何 PHP 要使用 rawurlencode() 函数呢？由于这才是真正符合 RFC 3986 的“百分号URL编码”，只是因为历史缘由，以前先有了一个 urlencode() 函数用于实现 HTTP POST 中的相似的编码规则，故而只好用这么一个奇怪的名字。二者的区别在于前者会把空格编码为%20，然后者则会编码为+号。若是使用后者，那么IE6在下载带有空格的文件名时空格会变为加号。通常状况下，你是不会用到 urlencode() 这个函数的（ Discuz 某些版本中错误地使用它来进行文件名编码，从而致使空格变加号的BUG）。 via:Robot Shell

 

Content-disposition 是 MIME 协议的扩展，MIME 协议指示 MIME 用户代理如何显示附加的文件。当 Internet Explorer 接收到头时，它会激活文件下载对话框，它的文件名框自动填充了头中指定的文件名。（请注意，这是设计致使的；没法使用此功能将文档保存到用户的计算机上，而不向用户询问保存位置。）
Content-Disposition就是当用户想把请求所得的内容存为一个文件的时候提供一个默认的文件名。具体的定义以下

Content-Disposition: attachment; filename=“filename.xls”

 

固然filename参数能够包含路径信息，但User-Agnet会忽略掉这些信息，只会把路径信息的最后一部分作为文件名。当你在响应类型为application/octet- stream状况下使用了这个头信息的话，那就意味着你不想直接显示内容，而是弹出一个”文件下载”的对话框，接下来就是由你来决定“打开”仍是“保存”了。

如:Response.AppendHeader("Content-Disposition","attachment;filename=MyExcel.xls");

 

Content disposition 容许 servlet 指定文档表示的信息

HTTP response header中的content-disposition 容许 servlet 指定文档表示的信息。使用这种header ，你就能够将文档指定成单独打开（而不是在浏览器中打开），还能够根据用户的操做来显示。若是用户要保存文档，你还能够为该文档建议一个文件名。这个建议 名称会出如今 Save As 对话框的“文件名”栏中。若是没有指定，则对话框中就会出现 servlet 的名字。
servlet 中，将 header 设置成下面这样：
response.setHeader("Content-disposition","attachment;filename="+ "Example.xls" );
response.setHeader("Content-Disposition", "inline; filename="fliename);//点击打开会在ie中打开。 
须要说明的有三点： 
(1) 中文文件名须要进行iso8859-1转码方可正确显示：
fileName = new String(fileName.getBytes("GBK"),"iso8859-1");
(2)传递的文件名，须要包含后缀名（若是此文件有后缀名），不然丢失文件的属性，而不能自行选择相关程序打开。
(3)有下载前询问（是打开文件仍是保存到计算机）和经过IE浏览器直接选择相关应用程序插件打开两种方式，前者如上代码所示，后者以下：
response.setHeader("Content-disposition","filename="+ "Example.xls" );