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.Write的文件时,文件名中的空格将替换为下划线,当关联的应用程序打开时,会附加方括号中的数字:
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] ?
我如何摆脱下划线,为什么我得到[1]?
Thanks
6 个解决方案
#1
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.
这种文件名重写仅由浏览器完成,正如您在使用适当的工具检查收到的HTTP响应时所看到的,与所使用的浏览器无关。 IE首先将所请求的文件下载到其“Temporary Internet Files”文件夹系统(这不仅仅是一个,但这是另一个主题),为此目的,该文件会收到一个新名称,与“Content-Disposition”最佳匹配来自HTTP响应的建议。但是,如果实际用于此文件的实际“Temporary Internet Files”文件夹中已存在同名文件,则其名称将通过括号中的序列号扩展,如“[2]”。因为每个新的HTTP请求都会导致IE缓存机制重新计算实际的缓存文件夹,并且所选的下一个缓存文件夹可能还不包含具有该名称的文件,所以在下次下载文件或资源时,该数字似乎会消失同名。
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 :-(
如果下载的文件存储在某处,则通常会再次使用最初建议的文件名,具体取决于IE版本。一些版本和补丁级别似乎使用缓存文件夹文件名:-(
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.
(1)文件名将是缓存文件夹中文件的名称,而不是建议的名称。这甚至可能剥离扩展,即使已经选择正确处理文件,也会使某些应用程序混淆。
(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...
(2)如果互联网新手用户下载并打开文件进行编辑,然后只需按下应用程序的“保存”按钮,该文件就会被保存到IE缓存文件夹中,没有这种用户会找到这个文件再次。这些东西可以让人真正生气和绝望......
#2
Found the solution for this problem here
在这里找到了解决这个问题的方法
To solve problem for FF, add quotes around the filename as
要解决FF的问题,请在文件名周围添加引号
Response.AddHeader("Content-Disposition", "attachment; filename=\"" + filename + "\"");
Response.AddHeader(“Content-Disposition”,“attachment; filename = \”“+ filename +”\“”);
And for IE, replace spaces with '%20'
对于IE,用'%20'替换空格
filename = toDownload.Name.Replace(" ", "%20");
filename = toDownload.Name.Replace(“”,“%20”);
#3
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;
内容 - 处理:附件; filename =我的新文档.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!
FF36:提交下载文件“我的”:-( IE6:呈现“我的新文档.pdf”,但在打开时它可能显示为“我的新文档[1] .pdf”.IE8:呈现“My_New_Document.pdf” ,但也可以将“[1]”添加为IE6。ATTN:在保存文档时,IE会保留显示的名称,无论它直接打开时所选择的应用程序是什么!
First improvement:
Content-Disposition: attachment; filename="My New Document.pdf";
内容 - 处理:附件; filename =“我的新文档.pdf”;
FF36: Works as supposed, i. e. presents "My New Document.pdf". IE6+IE8: No change, just as before.
FF36:按照假设工作,我。即介绍“我的新文档.pdf”。 IE6 + IE8:没有变化,就像以前一样。
Second change:
Content-Disposition: attachment; filename="My%20New%20Document.pdf";
内容 - 处理:附件;文件名= “我%20New%20Document.pdf”;
(replace blanks by %20, as in URL encoding, and keep double quotes.)
(将%空格替换为空格,如URL编码,并保留双引号。)
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".
FF36:显示发回的内容,即“我的%20New%20Document.pdf”。不太好。 IE6 + IE8:呈现“我的新文档.pdf”,但发出“我的%20New%20Document.pdf”。
Third variation:
Content-Disposition: attachment; filename=My%20New%20Document.pdf;
内容 - 处理:附件;文件名=我%20New%20Document.pdf;
(Remove double quotes, but keep %20.)
(删除双引号,但保留%20。)
FF36: As above -- not nice. IE6+IE8: As above -- not that nice also.
FF36:如上所述 - 不太好。 IE6 + IE8:如上所述 - 也不是那么好。
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.
似乎至少所提出的方法并没有全部和永久地解决问题:它们也不能涵盖1个浏览器的所有情况,也不会覆盖所有浏览器的任何相同的一个选定情况。
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.
对我来说,最好的结果似乎可以使用周围的双引号:对于FF36和IE6可行,对于IE8(可能对于IE7),它至少与下划线稳定,i。即下载和保存呈现与下载和打开相同的文件名,除了“[1]”,我们无论如何都无法阻止。
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. :-)
有些人和Saint-Exupérys的小王“小王子”一起说,皇帝不能指望他的人民在他要求什么是根本不可能的时候跟随,导致他指挥太阳升起并设置它的时间自然恰巧这样做。就像这个国王在他的小行星越来越多地加速旋转时遇到了麻烦,这些人已经放弃了,只是在服务器端添加了下划线。 :-)
But the RFCs on this topic and what browser implementors offer is quite hard to overcome sometimes.
但有关此主题的RFC以及浏览器实现者提供的内容有时难以克服。
#4
Did you try replacing spaces with "%20" (without double qoutes) like in urls?
您是否尝试用URL中的“%20”替换空格(没有双qoutes)?
But you should consider to avoid spaces in filenames (in urls).
但是你应该考虑避免文件名中的空格(在url中)。
#5
Shouldn't you be using Response.Output.Write() instead, after HTMLEncoding the output? :
在HTMLEncoding输出之后,你不应该使用Response.Output.Write()吗? :
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.
编辑:下划线和文件名后面的[1]表示它是从Temporary internet files文件夹加载的。没有足够的信息来推断出为什么会发生这种情况,但也许这些信息会为您提供线索。
#6
Apparently this is an issue with IE7 and requires a hotfix: http://support.microsoft.com/kb/952730/en-us
显然这是IE7的一个问题,需要一个修补程序: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.
仍然不知道附加的数字 - 我想也许是因为IE临时下载文件夹中已存在同名文件,但情况并非如此。
#1
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.
这种文件名重写仅由浏览器完成,正如您在使用适当的工具检查收到的HTTP响应时所看到的,与所使用的浏览器无关。 IE首先将所请求的文件下载到其“Temporary Internet Files”文件夹系统(这不仅仅是一个,但这是另一个主题),为此目的,该文件会收到一个新名称,与“Content-Disposition”最佳匹配来自HTTP响应的建议。但是,如果实际用于此文件的实际“Temporary Internet Files”文件夹中已存在同名文件,则其名称将通过括号中的序列号扩展,如“[2]”。因为每个新的HTTP请求都会导致IE缓存机制重新计算实际的缓存文件夹,并且所选的下一个缓存文件夹可能还不包含具有该名称的文件,所以在下次下载文件或资源时,该数字似乎会消失同名。
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 :-(
如果下载的文件存储在某处,则通常会再次使用最初建议的文件名,具体取决于IE版本。一些版本和补丁级别似乎使用缓存文件夹文件名:-(
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.
(1)文件名将是缓存文件夹中文件的名称,而不是建议的名称。这甚至可能剥离扩展,即使已经选择正确处理文件,也会使某些应用程序混淆。
(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...
(2)如果互联网新手用户下载并打开文件进行编辑,然后只需按下应用程序的“保存”按钮,该文件就会被保存到IE缓存文件夹中,没有这种用户会找到这个文件再次。这些东西可以让人真正生气和绝望......
#2
Found the solution for this problem here
在这里找到了解决这个问题的方法
To solve problem for FF, add quotes around the filename as
要解决FF的问题,请在文件名周围添加引号
Response.AddHeader("Content-Disposition", "attachment; filename=\"" + filename + "\"");
Response.AddHeader(“Content-Disposition”,“attachment; filename = \”“+ filename +”\“”);
And for IE, replace spaces with '%20'
对于IE,用'%20'替换空格
filename = toDownload.Name.Replace(" ", "%20");
filename = toDownload.Name.Replace(“”,“%20”);
#3
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;
内容 - 处理:附件; filename =我的新文档.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!
FF36:提交下载文件“我的”:-( IE6:呈现“我的新文档.pdf”,但在打开时它可能显示为“我的新文档[1] .pdf”.IE8:呈现“My_New_Document.pdf” ,但也可以将“[1]”添加为IE6。ATTN:在保存文档时,IE会保留显示的名称,无论它直接打开时所选择的应用程序是什么!
First improvement:
Content-Disposition: attachment; filename="My New Document.pdf";
内容 - 处理:附件; filename =“我的新文档.pdf”;
FF36: Works as supposed, i. e. presents "My New Document.pdf". IE6+IE8: No change, just as before.
FF36:按照假设工作,我。即介绍“我的新文档.pdf”。 IE6 + IE8:没有变化,就像以前一样。
Second change:
Content-Disposition: attachment; filename="My%20New%20Document.pdf";
内容 - 处理:附件;文件名= “我%20New%20Document.pdf”;
(replace blanks by %20, as in URL encoding, and keep double quotes.)
(将%空格替换为空格,如URL编码,并保留双引号。)
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".
FF36:显示发回的内容,即“我的%20New%20Document.pdf”。不太好。 IE6 + IE8:呈现“我的新文档.pdf”,但发出“我的%20New%20Document.pdf”。
Third variation:
Content-Disposition: attachment; filename=My%20New%20Document.pdf;
内容 - 处理:附件;文件名=我%20New%20Document.pdf;
(Remove double quotes, but keep %20.)
(删除双引号,但保留%20。)
FF36: As above -- not nice. IE6+IE8: As above -- not that nice also.
FF36:如上所述 - 不太好。 IE6 + IE8:如上所述 - 也不是那么好。
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.
似乎至少所提出的方法并没有全部和永久地解决问题:它们也不能涵盖1个浏览器的所有情况,也不会覆盖所有浏览器的任何相同的一个选定情况。
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.
对我来说,最好的结果似乎可以使用周围的双引号:对于FF36和IE6可行,对于IE8(可能对于IE7),它至少与下划线稳定,i。即下载和保存呈现与下载和打开相同的文件名,除了“[1]”,我们无论如何都无法阻止。
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. :-)
有些人和Saint-Exupérys的小王“小王子”一起说,皇帝不能指望他的人民在他要求什么是根本不可能的时候跟随,导致他指挥太阳升起并设置它的时间自然恰巧这样做。就像这个国王在他的小行星越来越多地加速旋转时遇到了麻烦,这些人已经放弃了,只是在服务器端添加了下划线。 :-)
But the RFCs on this topic and what browser implementors offer is quite hard to overcome sometimes.
但有关此主题的RFC以及浏览器实现者提供的内容有时难以克服。
#4
Did you try replacing spaces with "%20" (without double qoutes) like in urls?
您是否尝试用URL中的“%20”替换空格(没有双qoutes)?
But you should consider to avoid spaces in filenames (in urls).
但是你应该考虑避免文件名中的空格(在url中)。
#5
Shouldn't you be using Response.Output.Write() instead, after HTMLEncoding the output? :
在HTMLEncoding输出之后,你不应该使用Response.Output.Write()吗? :
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.
编辑:下划线和文件名后面的[1]表示它是从Temporary internet files文件夹加载的。没有足够的信息来推断出为什么会发生这种情况,但也许这些信息会为您提供线索。
#6
Apparently this is an issue with IE7 and requires a hotfix: http://support.microsoft.com/kb/952730/en-us
显然这是IE7的一个问题,需要一个修补程序: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.
仍然不知道附加的数字 - 我想也许是因为IE临时下载文件夹中已存在同名文件,但情况并非如此。