response.BinaryWrite問題（文本文件包含PDF編碼）

所以我有一些奇怪的事情發生在我的Asp.Net網站。response.BinaryWrite問題（文本文件包含PDF編碼）

我有2個單獨的頁面，使用相同的代碼來下載存儲在SQL數據庫中的文件。

一頁是該頁面的管理員版本，您可以在其中刪除和上載文件並查看文件ID。

此頁面的用戶端版本只顯示下載按鈕和文件名。該ID被隱藏並用作網格中的DataKey以從數據庫中選擇文件。

這兩個頁面在開發中都很完美。但是，當我切換到我們的製作臨時服務器時，頁面的用戶最終版本會在保存並打開它時將簡單的一行文本文件轉換爲一堆難看的PDF編碼，而頁面的管理員版本仍然正常工作。 PDF的下載和查看正常和文字文檔與文本文件做同樣的事情。

這裏是後面的代碼爲admin下載部分：

protected void btnSaveAttachment_Click(object sender, EventArgs e) 
    { 
     GridViewRow selectedRow = ((LinkButton)sender).NamingContainer as GridViewRow; 

     string AttachmentID = ""; 
     string AttachmentName = ""; 
     if (selectedRow.Cells[1].Text != null && selectedRow.Cells[2].Text != null) 
     { 
      AttachmentID = selectedRow.Cells[1].Text; 
      AttachmentName = selectedRow.Cells[2].Text; 
     } 

     byte[] objData = Utility.SaveAttachmentBytes(AttachmentID); 

     HttpResponse response = HttpContext.Current.Response; 
     response.ClearContent(); 
     response.Clear(); 
     response.ClearHeaders(); 
     response.AddHeader("Cache-Control", " no-store, no-cache "); 
     response.AddHeader("Content-Disposition", "attachment; filename=" + AttachmentName + ";"); 
     response.BinaryWrite(objData); 
     response.Flush(); 

     if (response != null) 
     { 
      response.End(); 
     } 

    }

這裏是後面的代碼供用戶下載部分：

protected void btnSaveAttachment_Click(object sender, EventArgs e) 
    { 
     GridViewRow selectedRow = ((LinkButton)sender).NamingContainer as GridViewRow; 

     //string AttachmentID = selectedRow.Cells[1].Text; 
     string AttachmentID = grdAttachments.DataKeys[0].Value.ToString(); 
     string AttachmentName = ""; 
     if (selectedRow.Cells[1].Text != null) 
     { 
      AttachmentName = selectedRow.Cells[1].Text; 
     } 

     byte[] objData = Utility.SaveAttachmentBytes(AttachmentID); 

     HttpResponse response = HttpContext.Current.Response; 
     response.ClearContent(); 
     response.Clear(); 
     response.ClearHeaders(); 
     response.AddHeader("Cache-Control", " no-store, no-cache "); 
     response.AddHeader("Content-Disposition", "attachment; filename=" + AttachmentName + ";"); 
     response.BinaryWrite(objData); 
     response.Flush(); 

     //File.Delete(SavePath); 

     if (response != null) 
     { 
      response.End(); 
     } 
    }

我在一個點，我只是不知道這是怎麼回事。頁面前端代碼中唯一的其他區別是用戶頁面從數據庫加載一些文本到標籤中，並且具有telerik文本框控件。（我曾嘗試刪除頁面上的所有其他項目，但仍然是PDF以外的其他文件嘗試編碼爲PDF。）

這是一行文本文件在保存和打開時的樣子。

%PDF-1.4 
%âãÏÓ 
9 0 obj<</H[516 160]/Linearized 1/E 5419/L 14363/N 2/O 12/T 14137>> 
endobj 

xref 
9 11 
0000000016 00000 n 
0000000676 00000 n 
0000000516 00000 n 
0000000753 00000 n 
0000000881 00000 n 
0000000976 00000 n 
0000001511 00000 n 
0000001903 00000 n 
0000002142 00000 n 
0000002387 00000 n 
0000002463 00000 n 
trailer 
<</Size 20/Prev 14127/Root 10 0 R/Info 8 0 R/ID[<3d8f2faf909b30f75011a461bd4aff97><b62071c85b58ab4d8f0b23af1811506f>]>> 
startxref 
0 
%%EOF 

11 0 obj<</Length 82/Filter/FlateDecode/L 90/S 53>>stream 
xÚb```f`` 
‘BVœÀ cf`aàXÀàÎ°…Ql 
HT ÈAPÌÀàÃÀÃì ,³Ñ†Ë`%·Hˆ…Aý!fb€ O{Ì 
endstream 
endobj 
10 0 obj<</Pages 6 0 R/Type/Catalog/PageLabels 4 0 R/Metadata 7 0 R>> 
endobj 
12 0 obj<</Contents 19 0 R/Type/Page/Parent 6 0 R/Rotate 0/MediaBox[0 0 612 792]/CropBox[0 0 612 792]/Resources 13 0 R>> 
endobj 
13 0 obj<</Font<</TT2 14 0 R/TT4 15 0 R>>/ProcSet[/PDF/Text]/ExtGState<</GS1 18 0 R>>>> 
endobj 
14 0 obj<</Type/Font/Encoding/WinAnsiEncoding/BaseFont/TimesNewRomanPSMT/FirstChar 32/LastChar 150/Subtype/TrueType/FontDescriptor 16 0 R/Widths[250 0 0 0 0 833 778 0 333 333 0 564 250 333 250 278 500 500 500 500 500 500 500 500 500 500 278 0 0 0 0 0 0 722 667 667 722 611 556 722 0 333 389 0 611 889 722 722 556 722 667 556 611 722 722 944 722 722 0 0 0 0 0 0 0 444 500 444 500 444 333 500 500 278 278 500 278 778 500 500 500 500 333 389 278 500 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500]>> 
endobj 
15 0 obj<</Type/Font/Encoding/WinAnsiEncoding/BaseFont/TimesNewRomanPS-BoldMT/FirstChar 32/LastChar 121/Subtype/TrueType/FontDescriptor 17 0 R/Widths[250 0 0 0 0 0 0 0 0 0 0 0 0 0 250 0 500 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 722 722 0 0 0 0 389 0 0 0 0 0 778 0 0 0 556 667 722 0 0 0 0 0 0 0 0 0 0 0 500 0 444 0 444 333 500 0 278 0 0 0 833 556 0 0 0 444 389 333 556 500 722 0 500]>> 
endobj 
16 0 obj<</Type/FontDescriptor/FontBBox[-568 -307 2028 1007]/FontName/TimesNewRomanPSMT/Flags 34/StemV 82/CapHeight 656/XHeight 0/Ascent 891/Descent -216/ItalicAngle 0/FontFamily(Times New Roman)/FontStretch/Normal/FontWeight 400>> 
endobj 
17 0 obj<</Type/FontDescriptor/FontBBox[-558 -307 2034 1026]/FontName/TimesNewRomanPS-BoldMT/Flags 34/StemV 136/CapHeight 656/XHeight 0/Ascent 891/Descent -216/ItalicAngle 0/FontFamily(Times New Roman)/FontStretch/Normal/FontWeight 700>> 
endobj 
18 0 obj<</Type/ExtGState/SA false/OP false/SM 0.02/op false/OPM 1>> 
endobj 

etc.................... 

endstream 
endobj 
4 0 obj<</Nums[0 5 0 R]>> 
endobj 
5 0 obj<</S/D>> 
endobj 
6 0 obj<</Count 2/Kids[12 0 R 1 0 R]/Type/Pages>> 
endobj 
7 0 obj<</Length 3339/Type/Metadata/Subtype/XML>>stream 
<?xpacket begin='ï»¿' id='W5M0MpCehiHzreSzNTczkc9d'?> 
<?adobe-xap-filters esc="CRLF"?> 
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='XMP toolkit 2.9.1-13, framework 1.6'> 
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:iX='http://ns.adobe.com/iX/1.0/'> 
<rdf:Description rdf:about='uuid:d5ef0fdf-fd89-4be0-a57d-fcab92aa8d2b' xmlns:pdf='http://ns.adobe.com/pdf/1.3/' pdf:Producer='Acrobat Distiller 6.0 (Windows)'></rdf:Description> 
<rdf:Description rdf:about='uuid:d5ef0fdf-fd89-4be0-a57d-fcab92aa8d2b' xmlns:xap='http://ns.adobe.com/xap/1.0/' xap:CreatorTool='PScript5.dll Version 5.2' xap:ModifyDate='2005-06-10T14:07:36-04:00' xap:CreateDate='2005-06-10T14:07:36-04:00'></rdf:Description> 
<rdf:Description rdf:about='uuid:d5ef0fdf-fd89-4be0-a57d-fcab92aa8d2b' xmlns:xapMM='http://ns.adobe.com/xap/1.0/mm/' xapMM:DocumentID='uuid:2aee5402-c607-44cd-a815-8ad3a0bf0a56'/> 
<rdf:Description rdf:about='uuid:d5ef0fdf-fd89-4be0-a57d-fcab92aa8d2b' xmlns:dc='http://purl.org/dc/elements/1.1/' dc:format='application/pdf'><dc:title><rdf:Alt><rdf:li xml:lang='x-default'>Microsoft Word - 1 - DTOD Overview.doc</rdf:li></rdf:Alt></dc:title><dc:creator><rdf:Seq><rdf:li>AttardA</rdf:li></rdf:Seq></dc:creator></rdf:Description> 
</rdf:RDF> 
</x:xmpmeta>     
<?xpacket end='w'?> 
endstream 
endobj 
8 0 obj<</ModDate(D:20050610140736-04'00')/CreationDate(D:20050610140736-04'00')/Title(Microsoft Word - 1 - DTOD Overview.doc)/Creator(PScript5.dll Version 5.2)/Producer(Acrobat Distiller 6.0 \(Windows\))/Author(AttardA)>> 
endobj 
xref 
0 9 
0000000000 65535 f 
0000005419 00000 n 
0000005544 00000 n 
0000005638 00000 n 
0000010369 00000 n 
0000010402 00000 n 
0000010425 00000 n 
0000010482 00000 n 
0000013897 00000 n 
trailer 
<</Size 9>> 
startxref 
116 
%%EOF

分辨

的問題是DataKeys [0]總是選擇鍵的陣列中的0項。我改變了：

string AttachmentID = grdAttachments.DataKeys[selectedRow.RowIndex].Value.ToString();

現在一切工作正常！希望我能更接近attachmentID進行調試！

它剛剛碰巧有兩個文件是相同的，我雖然我正在下載正確的文件。

來源

2013-06-04 Robert Hamm

在您的管理部分：

string AttachmentID = selectedRow.Cells[1].Text;

在用戶部分：

string AttachmentID = grdAttachments.DataKeys[0].Value.ToString();

我會假定用戶部分分配不這樣做，你指望它有什麼，因爲邏輯兩者都不相同。在每種情況下驗證AttachmentID設置爲什麼，可能是通過日誌記錄。

來源

2013-06-04 17:12:24 Haney

我認爲這將是第一個問題。但是，propper附件在開發過程中使用這個非常好的代碼下載和查看，並且我已經通過代碼來確保DataKey是正確的附件ID。 –

它們之間的區別必須是環境。考慮數據庫和表格模式（可能會對它們進行比較/比較）或Telerik版本。 – Haney

一想到我將重新評估attachmentID。 –

response.BinaryWrite問題（文本文件包含PDF編碼）

回答

相關問題