下載後郵編文件夾總是損壞

Question

由於某些原因，當我從我的服務器的文件夾下載zip文件夾時，它總是被損壞。下面是代碼：

protected void gvFiles_RowCommand(object sender, System.Web.UI.WebControls.GridViewCommandEventArgs e) 
     { 
      string fileUrl = String.Empty; 

      if(e.CommandName.Equals("DownloadFile")) 
      { 
       fileUrl = e.CommandArgument as String; 
       string fileName = Path.GetFileName(fileUrl); 

       Response.AppendHeader("content-disposition", 
     "attachment; filename=" + fileName); 
       Response.ContentType = "application/zip"; 

       Response.WriteFile(fileUrl); 
       Response.End(); 



      } 
     } 

這裏是GridView控件的填充方式：

private void BindData() 
     { 
      List<SampleFile> files = new List<SampleFile>(); 

      for(int i=1;i<=3;i++) 
      { 
       SampleFile sampleFile = new SampleFile(); 
       sampleFile.Name = "File " + i; 
       sampleFile.Url = Server.MapPath("~/Files/File"+i+".txt"); 
       files.Add(sampleFile); 
      } 

      SampleFile file = new SampleFile(); 
      file.Name = "Zip File"; 
      file.Url = Server.MapPath("~/Files/WebSiteNestedMasters.zip"); 
      files.Add(file); 
      gvFiles.DataSource = files; 
      gvFiles.DataBind(); 
     } 

Answer 1

我只是想與.docx文件和相同的結果（該文件已損壞）相同的代碼：以下是代碼：

if(e.CommandName.Equals("DownloadFile")) 
      { 
       fileUrl = e.CommandArgument as String; 
       string fileName = Path.GetFileName(fileUrl); 

       FileInfo info = new FileInfo(fileUrl); 

       Response.Clear(); 
       Response.ClearContent(); 
       Response.ClearHeaders(); 
       Response.Buffer = true; 

       Response.AppendHeader("Content-Length",info.Length.ToString()); 
       Response.ContentType = GetContentType(fileUrl); 
       Response.AppendHeader("Content-Disposition:", "attachment; filename=" + fileName); 
       Response.TransmitFile(fileUrl); 
       Response.Flush(); 
       Response.End(); 
      } 

Answer 2

我不知道asp.net可言，但是這是很常見的做下載的結果在文本模式而不是二進制模式下。換行結尾的字符會從\ r \ n轉換爲\ n，反之亦然，並且所有事情都會發生。

Answer 3

首先，驗證文件的內容是否看起來像一個zip文件。只需將文件放入記事本並查看內容即可。如果文件以PK和一些有趣的字符開頭，則可能是一個zip文件。如果它包含HTML，那可能是它爲什麼會出錯的線索。

看着你的代碼，它讓我感到你將URL傳遞給了文件Response.WriteFile。 Response.WriteFile處理url的還是使用本地文件名？也許一切都由Response.WriteFile起作用，因此正確的頭文件被髮送等等，但是隨後的代碼會崩潰，這可能會讓你的「zip文件」包含一個HTML錯誤信息。

---

編輯：好吧，先解決問題的步驟完成。文件看起來像記事本中的zip文件，而不是HTML錯誤消息。

下一步，由於文件駐留在服務器上，因此請嘗試將文件直接寫入文件，而不是通過應用程序。那樣有用嗎？

如果沒有，請嘗試使用不同的zip程序（您使用哪種方式？）。

作爲一個例子，你應該直接嘗試文件和不同的解壓縮程序。 FinalBuilder會生成PowerArchiver抱怨的zip文件，但7zip不會，所以文件或程序可能有問題，甚至可能兩者都有問題。

但是請驗證文件是否正確，可以打開，如果您完全不下載它們，並檢查如果將它們直接下載到應用程序之外會發生什麼情況。

---

編輯：好吧，你已經驗證，即使你直接從你的服務器下載該文件將不會打開。

如何在瀏覽器中打開文件，完全繞開Web服務器？例如，由於它看起來像您在本地有文件，因此請嘗試導航到正確的文件夾並直接打開文件。那樣有用嗎？

Answer 4

由於@lassevk建議您下載損壞的 zip文件並將其與服務器上的原始文件進行比較。都是一樣的長度？使用十六進制編輯器檢查文件的內容。在這個related thread你說如果你直接將瀏覽器指向zip文件，它也會被破壞，這意味着問題可能與頭文件無關，但是IIS有問題。您是否在使用可修改文件的第三方ISAPI擴展？

Answer 5

下面是更新後的代碼：

fileUrl = e.CommandArgument as String; 
       string fileName = Path.GetFileName(fileUrl); 

       FileStream fs = new FileStream(fileUrl, FileMode.Open); 
       byte[] buffer = new byte[fs.Length]; 
       fs.Read(buffer, 0, (int) fs.Length); 
       fs.Close(); 

       Response.Clear(); 
       Response.AppendHeader("content-disposition", 
     "attachment; filename=" + fileName); 
       Response.ContentType = "application/octet-stream"; 
       Response.AppendHeader("content-length", buffer.Length.ToString()); 

       Response.BinaryWrite(buffer); 
       Response.Flush(); 
       Response.End(); 

Answer 6

這裏是小提琴手統計：

HTTP/1.1 200 OK 服務器：ASP.NET開發服務器/ 8.0.0.0 日期：週三，17 Dec 2008 22:22:05 GMT X-AspNet-Version：2.0.50727 Content-Disposition：attachment;文件名= MyZipFolder.zip 的Content-Length：148 緩存控制：私人 內容類型：應用程序/ x-ZIP壓縮 連接：關閉

Answer 7

假設你需要這樣做：（例如，你不能以提供直接鏈接）

<a href='<% Eval("Url")) %>'>download</a> 

我會首先做一個觀察，即讓RowCommand處理程序開始返回文件不是這樣做的。創建某種類型的下載鏈接到不同的頁面。從包含網格的頁面的其餘部分單獨下載文件。

現在......

你已經得到了有關的權利的基礎，但像在this CodeProject tutorial評論你很快會遇到的問題。

Where the above code sample falls down:

• not responsive to user
• the code will keep going and you'll have no idea if the user actually downloaded the file (it may not matter to you)
• won't work with all browsers
• cannot resume a download
• doesn't show progress
• larger files will use more server memory and take longer to stream
• and a lot of downloads will mean the server is going to take a resource hit

，而你可能想..

• works just like a clicked download (ie using get, not post)
• works in all browsers on all platforms in the way the user expects (ie filename hint works on things like IE for Mac or Netscape 4.1).
• show download progress
• resumable downloads
• tracking all downloads and knowing when downloads complete
• looks like a file, even if it isn't
• expiration on url.
• allows for high concurrent # of downloads for any size of file

雖然用VB編寫的.net1.1文章Tracking and Resuming Large File Downloads in ASP.NET [devx]遠不如在解釋如何正確地做到這一點。

簡單的代碼很簡單，但並不總是奏效，並且有效地將文件流式傳輸給用戶100％的時間比設置內容頭部和剷除網絡上的某些位花費更多的精力。