When downloading a file with Response.Write spaces in the file name are replaced with underscores, and when the associated application opens, a number in square brackets is appended:
Response.AppendHeader("Content-disposition", "attachment; filename=this is the file.xml");
Response.Write(dr["InfopathDoc"]);
This results in this file name in the associated application:
this_is_the_file[1].xml
How can I get rid of the underscores and why do I get the [1] ?
Thanks
Did you try replacing spaces with "%20" (without double qoutes) like in urls?
But you should consider to avoid spaces in filenames (in urls).
Shouldn't you be using Response.Output.Write() instead, after HTMLEncoding the output? :
Response.Output.Write(Server.HtmlEncode(Convert.ToString(dr["InfopathDoc"])));
Edit: The underscores and the [1] appended to the filename suggest that it is being loaded from the Temporary internet files folder. There is insufficient information to deduce why this may be happening, but maybe this information will provide you a clue.
Apparently this is an issue with IE7 and requires a hotfix: http://support.microsoft.com/kb/952730/en-us
Still don't know about the number being appended though - I thought maybe it is because a file of the same name already exists in the IE temporary download folder, but that's not the case.
Found the solution for this problem here
To solve problem for FF, add quotes around the filename as
Response.AddHeader("Content-Disposition", "attachment; filename=\"" + filename + "\"");
And for IE, replace spaces with '%20'
filename = toDownload.Name.Replace(" ", "%20");
If anyone is still interested:
This kind of file name rewriting is done by the browser only as you can see when inspecting the received HTTP response with an appropriate tool, independent of the browser used. IE first downloads the requested file into its "Temporary Internet Files" folder system (which is not just one, but this is another topic), and for this purpose the file receives a new name, making best match to the "Content-Disposition" suggestion from the HTTP response. But if an equally named file is already present in the actual "Temporary Internet Files" folder actually used for this file, its name is extended by a sequenced number in brackets, like "[2]". Because every new HTTP request causes the IE cache mechanism to newly compute the actual cache folder, and the next cache folder chosen may not yet contain a file with that name, the number may seem to vanish at the next download of a file or resource with the same name.
If a downloaded file is stored somewhere, the originally suggested file name is used again usually, depending on the IE version. Some versions and patch levels seem to use the cache folder file name instead :-(
The problem starts to become annoying when the browser hands out a downloaded file to a chosen or automatically selected application. In this case the application is called to open the file directly from the cache, which is bad for at least 2 reasons:
(1) The file name will be the name of the file in the cache folder, not the suggested name. This may even strip the extension, which will confuse some applications even if they have been chosen for handling the file correctly.
(2) If an internet newbie user downloads and opens a file for editing and then simply presses the "Save" button of the application, the file is simply saved into the IE cache folder, and no user of this kind will ever find this file again. These are things which can turn people really angry and desperate...
On the net there are some solutions suggested to this kind of problem. Not all solutions work everywhere and for all browsers, but some solutions at least guarantee "save results" although they cannot keep the originally "suggested" filename for all clients:
First sight:
Content-Disposition: attachment; filename=My New Document.pdf;
FF36: Presents for download the file "My" :-( IE6: Presents "My New Document.pdf", but on opening it may appear as "My New Document[1].pdf". IE8: Presents "My_New_Document.pdf", but may also append "[1]" as IE6. ATTN: On saving the document, IE keeps the presented name, regardless of what it hands out to the selected application on direct opening!
First improvement:
Content-Disposition: attachment; filename="My New Document.pdf";
FF36: Works as supposed, i. e. presents "My New Document.pdf". IE6+IE8: No change, just as before.
Second change:
Content-Disposition: attachment; filename="My%20New%20Document.pdf";
(replace blanks by %20, as in URL encoding, and keep double quotes.)
FF36: Presents what was sent back, which is "My%20New%20Document.pdf". Not nice. IE6+IE8: Presents "My New Document.pdf", but hands out "My%20New%20Document.pdf".
Third variation:
Content-Disposition: attachment; filename=My%20New%20Document.pdf;
(Remove double quotes, but keep %20.)
FF36: As above -- not nice. IE6+IE8: As above -- not that nice also.
Conclusion:
It seems that at least the presented methods do not solve the problem all and forever: Neither do they cover all situations for 1 browser, nor do they cover all browsers for the any same one selected situation.
For me, the best result seems to be possible with surrounding double quotes: For FF36 and IE6 that works, and for IE8 (and probably for IE7) it is at least stable with the underscores, i. e. download & save render the same file name as download & open, except the "[1]" which we cannot prevent anyway.
Final remarks
Some people go with the little king of Saint-Exupérys "The Little Prince" which said that an emperor cannot really expect that his people follows when he demands what is simply not possible, causing him to command the sun to rise and set just when it naturally happens to do so. Like this king gets in trouble when his small planet accelerates its rotation more and more, these people have given up and simply add underscores on the server side already. :-)
But the RFCs on this topic and what browser implementors offer is quite hard to overcome sometimes.