为什么HttpUtility.UrlEncode(HttpUtility.UrlDecode("%20"))返回+而不是%20？

Question

我遇到文件下载问题,下载正在用下划线替换所有空格.

基本上我在这里遇到问题:

Response.AddHeader("Content-Disposition", 
    "attachment; filename=" + someFileName);

问题是如果someFileName中有一个空格,例如"check this out.txt",则会提示用户下载"check_this_out.txt".

我认为最好的选择是UrlEncode文件名,所以我试过

HttpUtility.UrlEncode(someFileName);

但它正在用加号取代空间,这让我很难过.那么我就试过了

HttpUtility.UrlEncode(HttpUtility.UrlDecode("%20"))

并且解码工作正常并给我一个空间,但编码占用空间然后再次给我加号.

我在这里缺少什么,这是正确的吗？如果是这样,我应该如何正确地将空格编码为%20,这就是我需要的.

Answer 1

基本上,%20和+都是编码空间的有效方法.显然,UrlEncode方法必须选择其中一个选项...如果它选择以其他方式执行,其他人会问为什么UrlEncode(UrlDecode("+"))返回"%20"...

您可以随时对其进行编码,然后在"+"上为"%20"执行直接字符串替换.我认为这会奏效......

Answer 2

我认为最好的选择是UrlEncode文件名

这不是将带外字符放在诸如Content-Disposition-filename之类的头参数中的正确方法,并且由于错误而仅在IE中工作(有时).实际上这是一个长期存在的问题:没有正确的方法.

如果您需要在下载的文件名中放入特殊字符,则无法使用Content-Disposition-filename可靠地执行此操作.相反,省略Content-Disposition-attachment标头中的'filename'参数,并将所需的文件名保留在URL的尾部.如果没有文件名参数,浏览器将从URL路径中获取它,其中URL编码是处理特殊字符的正确方法.

Answer 3

引用此链接

我自己也遇到过这种情况.如果您能够将空格更改为%20s,则IE7将正确转换它们.虽然Firefox会逐字逐句地使用它们(至少在使用Content-disposition标头时),因此您只需要对来自IE7的请求执行此操作.

我们在应用程序中执行了以下操作.(基于tomcat的文档存储库)

String userAgent = request.getHeader("User-Agent");
if (userAgent.contains("MSIE 7.0")) {
    filename = filename.replace(" ", "%20");    
}         
response.addHeader("Content-disposition",
    "attachment;filename=\"" + filename + "\"");