Why does HttpUtility.UrlEncode(HttpUtility.UrlDecode("%20")) return + instead of %20?

I'm having a problem with a file download where the download is replacing all the spaces with underscores.

Basically I'm getting a problem here:

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

The problem is that if someFileName had a space in it such as "check this out.txt" then the user would be prompted to download "check_this_out.txt".

I figured the best option would be to UrlEncode the filename so I tried

HttpUtility.UrlEncode(someFileName);

But it's replacing the spaces with plus signs, which stumped me. So then I just tried

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

and the decode works properly an开发者_运维知识库d gives me a space, but the encode takes the space and then gives me the plus sign again.

What am I missing here, is this correct? If so, how should I properly encode spaces into %20's, which is what I need.

Basically both %20 and + are valid ways of encoding a space. Obviously the UrlEncode method has to pick one of the options... if it chose to do the other way, someone else would have asked why UrlEncode(UrlDecode("+")) returned "%20"...

You could always encode it, then just do a straight string replace on "+" for "%20". I think that would work...

I figured the best option would be to UrlEncode the filename

That's not the right way to put out-of-band characters in a header parameter such as Content-Disposition-filename, and only works (sometimes) in IE due to a bug. Actually it's a bit of a perennial problem: there is no right way.

If you need to put special characters in the downloaded filename, you can't do it reliably with Content-Disposition-filename. Instead, omit the ‘filename’ parameter from the Content-Disposition-attachment header, and leave the filename you want in the trailing part of the URL. In the absence of a filename parameter the browser will take it from the URL path, where URL-encoding is the right way to tackle special characters.

Quoting from this link

I've come across this myself. If you are able to change the spaces to %20s then IE7 will convert them correctly. Firefox though will take them literally ( at least when using the Content-disposition header) so you will need to do this for requests from IE7 only.

We did the following in our app. ( a tomcat based document repository)

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

Hi I also faced same kind of problem when downloading the files having spaces in them.

Please see the link which best suites and gives the complete answer.

http://kb.mozillazine.org/Filenames_with_spaces_are_truncated_upon_download

For the sake of understanding I am just adding the ASP.net code how to solve this problem.

string document = @"C:\Documents and Settings\Gopal.Ampolu\My Documents\Downloads\" + "Disciplinary & Grievance Procedures..doc";
string filename = "Disciplinary & Grievance Procedures..doc";

Response.ContentType = mimeType;
Response.AddHeader("Content-Disposition", @"attachment; filename=""" + HttpUtility.UrlDecode(filename) + @"""");
Response.Flush();

From the above you can see that while adding header to the response, filename is enclosed with double quotes. Please make sure that the "filename" must be Decoded with UrlDecode.

One more option is also there, if you can intimate clients about windows hotfix update available at following:

Windows Hotfix Update for IE white space issue

It is client side, so may not be applicable to all the scenarios but still an option if feasible.