摘要:在基于/的應用環境中,上傳各種類型的文件一直是困擾用戶文件管理應用的難題之一。在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 Aclearcase/" target="_blank" >cceptor 。ASP不懂"multipart/form-data" 編碼方案。取而代之,提供了Posting Acceptor ,Posting Acceptor是一種在上傳完成后,接受REPOST到一個ASP頁的ISAPI應用程序。
本新聞共3頁,當前在第1頁 1 2 3