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

Question

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 and 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.

Answer 1

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...

Answer 2

quoting from http://social.msdn.microsoft.com/forums/en-US/iewebdevelopment/thread/cc3adbf7-2e77-4eea-92ee-53065dfc19cf/

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+"\"");

Answer 3

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.