摘要：在基于/的應用環境中，上傳各種類型的文件一直是困擾用戶文件管理應用的難題之一。在HTTP中上傳文件有三種機制：RFC1867，PUT和WebDAV。常用的實現方法是利用在RFC1867中引入的一個新類型：File以及ADO Stream對象。本文對上述上傳方法及實現原理作了論述，并給出了具體解決實例。
ASP FILE對象
當前，基于/模式的應用比較流行。當用戶需要將文件傳輸到上時，常用方法之一是運行FTP并將每個用戶的FTP默認目錄設為用戶的Web主目錄，這樣用戶就能運行FTP客戶程序并上傳文件到指定的 Web目錄。這就要求用戶必須懂得如何使用FTP客戶程序。因此，這種解決方案僅對熟悉FTP且富有經驗的用戶來說是可行的。 如果我們能把文件上傳功能與Web集成，使用戶僅用Web就能完成上傳任務，這對于他們來說將是非常方便的。但是，一直以來,由于File System Object的僅能傳送文本文件的局限，所以ASP最大的難題就是文件上傳問題。下面介紹的就是如何在基于HTTP協議的網頁中實現文件的上傳。
一．通過HTTP上傳的三種機制
通過HTTP上傳有三種機制：RFC1867, PUT 和 WebDAV。
PUT 是在HTTP 1.1引入了一個新的HTTP動詞。當web收到一個HTTP PUT和對象名字，它將會驗證用戶，接收HTTP流的內容，并把它直接存入web。由于這可能會對一個web站點造成破壞，并且還會失去HTTP最大的優勢：可編程性。在PUT的情況下，自己處理請求：沒有空間讓CGI或者ASP應用程序介入。唯一讓你的應用程序捕獲PUT的方法是在低層操作，ISAPI過濾層。由于相應的原因，PUT的應用很有限。
而WebDAV允許web內容的分布式認證與翻譯。它引入了幾種新的HTTP動詞，允許通過HTTP上傳，鎖定/解鎖，登記/檢驗web內容。Office 2000中的"Save to web" 就是通過WebDAV來實現的。如果你所感興趣的一切都是上傳內容，WebDAV應用得非常出色，它解決了很多問題。 然而，如果你需要在你的web應用程序里面上傳文件，WebDAV對你就毫無用處可言。象HTTP PUT一樣，那些WebDAV的動詞是被解釋的，而不是web應用程序。你需要工作在ISAPI過濾層來訪問WebDAV的這些動詞，并在你的應用程序中解釋內容。
RFC1867 (http://www.ietf.org/rfc/rfc1867.txt) 最終被W3C在HTML3.2中接受前，是作為一種建議標準。它是一種非常簡單但是功能很強大的想法：在表單字段中定義一個新類型。
<INPUT TYPE="FILE">
并且在表單本身加入了不同的編碼方案，不再使用典型的：
<FORM ACTION="formproc.asp" METHOD="POST">
而是使用：
<FORM ACTION="formproc.asp" METHOD="POST" ENCTYPE="multipart/form-data">
這種編碼方案在傳送大量數據的時候，比起缺省的"application/x-url-encoded"表單編碼方案，顯得效率要高得多。URL編碼只有很有限的字符集，使用任何超出字符集的字符，必須用'%nn'代替，這里的nn表示相應的2個十六進制數字。例如，即使是普通的空格字符也要用'%20'代替。而RFC1867使用多部分MIME編碼，就象通常在e-mail消息中看到的那樣，不編碼來傳送大量數據，而只是在數據周圍加上很少的簡單但實用的頭部。主要的廠商都采用了建議的"瀏覽..."按鈕，用戶能很容易的使用本地"打開文件..." 對話框選擇要上傳的文件。
RFC1867仍然將大多數文件上傳的靈活方法留給了你的web應用程序。PUT用得很有限。WebDAV對內容的作者很有用，比如FrontPage用戶，但是對想在web應用程序中加入文件上傳的web開發者來說很少用到。因此，RFC1867是在web應用程序中加入文件上傳的最好的辦法。
在實際應用中，免費提供了Posting Acceptor 。ASP不懂"multipart/form-data" 編碼方案。取而代之，提供了Posting Acceptor ，Posting Acceptor是一種在上傳完成后，接受REPOST到一個ASP頁的ISAPI應用程序。
本新聞共3頁,當前在第1頁 1 2 3
文章來源于領測軟件測試網 http://www.kjueaiud.com/
