5

我正在尝试下载一个 excel 文件（使用 C#\ASP.NET 动态生成），当我单击“打开”时出现 IE10 查看下载对话框，它显示“无法下载 abc.xls”错误，但在单击“重试”它会在第二次尝试中正确打开 .xls 文件。

当我在 Firefox 或 Chrome 中测试它时，它工作正常。

4

2 回答 2

8

我认为这可以解释奇怪的行为：

《IE10 下载管理器中的内容长度和传输编码验证》

似乎IE9 beta在下载文件时引入了content-length验证transfer-encoding，但发现问题太大，因为许多服务器没有为这些通过代码处理的下载发送正确的值。显然，他们在 IE10 中将其重新打开，只是希望获得最好的结果。

我敢打赌，下载开始时发送的准确值应该可以解决这个问题。当然，一开始应该没问题……哎呀呀。

[编辑]

原来这个问题与 using Response.Close()and/or Response.End()in code相关（至少对我而言） 。这篇文章解释了为什么你不应该使用这两种方法，以及为什么HttpApplication.CompleteRequest选择的方法。更改我们的Response.End()和Response.Close()实例以HttpApplication.CompleteRequest解决我们的 IE10 下载问题。就像魔术一样。显然，MSDN 现在不鼓励使用这两种方法（尽管多年来 MSDN 代码示例包含它们），现在提倡使用HttpApplication.CompleteRequest。

我们一直在与欧亚大陆交战……

[/编辑]

于 2013-05-30T17:13:35.987 回答
2

我遇到了类似的行为 - 在解决这个问题大约 12 小时后，对我有用的是：

从更改响应标头

内容类型：application/application/vnd.ms-excel

至

内容类型：应用程序/八位字节流

请注意，我还有另一个未提及的症状：我正在设置

内容处置：附件；文件名="Inventory_10-10-2013.xls"

尽管设置IE使用来自URL的文件名（所以它说“无法下载getInventory” - 并将错误命名的文件保存在下载文件夹中！）。

当我更改“内容类型”时，IE 开始尊重标题中的文件名。

为了记录，这里是我设置的所有响应标头：

  • HTTP/1.1 200 正常
  • 编译指示：公共
  • 过期：格林威治标准时间 2013 年 10 月 11 日星期五 16:33:38
  • 缓存控制：max-age=1
  • 内容处置：附件；文件名="Inventory_10-10-2013.xls"
  • 内容传输编码：二进制
  • 设置 Cookie：fileDownload=true；路径=/
  • 内容类型：application/octet-stream;charset=UTF-8
  • 内容长度：7680
  • 日期：2013 年 10 月 10 日星期四 16:33:38 GMT
于 2013-10-10T17:43:00.753 回答