文件名腐败的文件下载（IE）(File name corruption on file downlo

我实现了一个简单的文件上传，下载机制。当用户点击一个文件名，文件下载这些HTTP头：

HTTP/1.1 200 OK
Date: Tue, 30 Sep 2008 14:00:39 GMT
Server: Microsoft-IIS/6.0
Content-Disposition: attachment; filename=filename.doc;
Content-Type: application/octet-stream
Content-Length: 10754

我也支持日语文件名。为了做到这一点，我用编码这个Java方法的文件名：

private String encodeFileName(String name) throws Exception{
    String agent = request.getHeader("USER-AGENT");
    if(agent != null && agent.indexOf("MSIE") != -1){ // is IE
        StringBuffer res = new StringBuffer();
        char[] chArr = name.toCharArray();
        for(int j = 0; j < chArr.length; j++){
            if(chArr[j] < 128){ // plain ASCII char
                if (chArr[j] == '.' && j != name.lastIndexOf("."))
                    res.append("%2E");
                else
                    res.append(chArr[j]);
            }
            else{ // non-ASCII char
                byte[] byteArr = name.substring(j, j + 1).getBytes("UTF8");
                for(int i = 0; i < byteArr.length; i++){
                    // byte must be converted to unsigned int
                    res.append("%").append(Integer.toHexString((byteArr[i]) & 0xFF));
                }
            }
        }
        return res.toString();
    }
    // Firefox/Mozilla
    return MimeUtility.encodeText(name, "UTF8", "B");
}

它运作良好，到目前为止，直到有人发现它不长文件名很好地工作。例如： あああああああああああああああ2008.10.1あ.docああああああああああああああああああああああ2008.10.1あ.doc 。如果我改变单字节点的一个单字节下划线，或者如果我删除的第一个字符，它的工作原理确定。即，它取决于长度和编码URL-点字符的。下面是几个例子。

这是坏了（ あああああああああああああああ2008.10.1あ.doc ）：

Content-Disposition: attachment; filename=%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%822008%2E10%2E1%e3%81%82.doc;

这是OK（ あああああああああああああああ2008_10.1あ.doc ）：

Content-Disposition: attachment; filename=%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%822008_10%2E1%e3%81%82.doc;

这也是精（ あああああああああああああああ2008.10.1あ.doc ）：

Content-Disposition: attachment; filename=%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%82%e3%81%822008%2E10%2E1%e3%81%82.doc;

任何人有线索？

Answer 1:

Gmail中处理文件名逃逸有所不同：文件名是引用（双引号），和单字节周期是不是网址转义。这样一来，在这个问题的长文件名就可以了。

Content-Disposition: attachment; filename="%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%82%E3%81%822008.10.1%E3%81%82.doc"

然而，仍然有限制（显然IE只）上的文件名的字节长度（一个错误，我认为）。因此，即使文件名是由唯一的单字节字符，文件名的开头被截断。的限制是约160字节。

Answer 2:

如上所述，内容处理和Unicode是不可能得到工作的所有主流浏览器没有浏览器嗅探并返回为每个不同的头。

我的解决办法，以避免内容处置头完全和文件名添加到URL的末尾到浏览器欺骗，以为它直接获取文件。例如

http://www.xyz.com/cgi-bin/dynamic.php/あああああああああああああああ2008.10.1あ.doc

这自然假设你知道文件名时，你创建的链接，虽然快速重定向头可以设置它的需求。

Answer 3:

这里的主要问题是，IE不支持相关的RFC，在这里：RFC2231。请参见指针和测试用例。此外，您使用的IE（只使用百分之转义的UTF-8）有一些额外的问题解决方法; 它可能无法在所有区域设置工作（据我记得，该方法在韩国失败除非IE被配置为在URL中始终使用UTF-8这不是默认值），并且，如先前所提到的，有长度的限制（I听说是固定在IE8，但我没有尝试还）。