上傳

上傳一詞來自英文（Upload），拆開來“Up”為“上”，“Load”為“載”，故上傳也叫上載，與下載（Download）是逆過程。

上傳分為Web上傳和Ftp上傳，前者直接通過點擊網頁上的鏈接即可操作，後者需要專用的FTP工具。

WEB上傳：即通過瀏覽器來上傳文件 。

1、通過瀏覽器上傳文件，按照“操作嚮導”一步步操作完成，用户無須培訓；

2、通過分配用户權限發佈課件，簡單，安全；

3、不支持斷點續傳，支持大文件上傳；

4、上傳文件屬性（格式，上傳時間，人員等）自動生成，方便快捷；

5、上傳後的文件，配有審核機制，保證課件質量；

6、審核後的文件，自動歸類，用户通過校園網瀏覽；

7、WEB上傳需要有一定的網頁內容支持（包括上面所説的很多功能。）

FTP上傳：簡稱文件傳輸協議，通過FTP上傳。

1、上傳之前，需要安裝專業上傳軟件，並對軟件加以學習，用户需要學習上傳軟件；

2、需要建立FTP服務器及配置設置，專業性強；

3、支持斷點續傳，無需重新上傳，支持大文件上傳；

4、FTP上傳後，需要從後台手工輸入文件屬性，費時費力；

5、FTP上傳後的文件，沒有審核機制；

6、FTP上傳的文件後需要手工進行歸類，比較麻煩；

7、但FTP上傳具有WEB上傳絕無僅有的優勢，就是可以批量上傳、批量整理，不受太多限制。

在上傳主頁之前，讓我們先來認識Internet上一個基本的概念———FTP。它是英文“File Transfer Protocol”(文件傳輸協議)的縮寫，不過我們今天已經把它看成了一個動詞，意思是説在計算機和計算機之間傳輸文件。把自己製作好的主頁上傳到服務器上，就要用到FTP。

有許多種方法可以把主頁文件上傳到Internet服務器上，下面是常見的五種方法。

這是最常用、最方便也是功能最為強大的主頁上傳方法。雖然網上這類軟件很多，像Filezilla、CuteFtp、FlashFXP等已經廣受網友歡迎。這類軟件除了可以完成文件傳輸的功能以外，還可以通過它們完成站點管理、遠程編輯服務器文件等工作，一些常用的FTP軟件還有斷點續傳、任務管理、狀態監控等功能，可以讓你的上傳工作變得非常輕鬆。

所謂兼職的FTP軟件，是指軟件本身並不是專門用來完成FTP功能的，主頁上傳只是其編外任務。例如我們常用的FrontPage、Dreamweaver、東方主頁王Ⅱ等都有主頁上傳、發佈的功能。使用這類軟件的好處是可以在編輯主頁的同時就上傳到服務器上查看主頁效果，省去了啓動軟件、登錄、設置等諸多麻煩。但是，這種方法往往上傳速度較慢，且難以對服務器上的文件進行管理。

和前面兩種方法相比，這種方法不但沒有什麼明顯的優點，而且速度緩慢、操作麻煩、不支持斷點續傳。但是，如果你恰恰申請了一個這樣的不支持FTP的免費主頁空間，那麼就只能使用這種笨拙的方法了！

在很久很久以前，Unix系統上的FTP程序是基於命令行的，如今的Window95/98/NT/2000/Me仍然有基於命令行的FTP程序(進入DOS模式，輸入FTP就可以了)。使用這種方法首先要掌握幾十條命令不説，而且屏幕上通常只能顯示25或50行文字，很不方便。圖形界面的FTP軟件流行之後，這種方法已經被大多數網友拋棄了，只供少數骨灰級的網蟲練習他們的指法。

這種方法要求你把主頁文件通過E-mail發給系統管理員，然後再由系統管理員把它們放到服務器上。這是最簡單也是最複雜的方法，隨着網絡條件的提高，這種方法已逐漸銷聲匿跡了。

基於WEB的文件上傳可以使用FTP和HTTP兩種協議，用FTP的話雖然傳輸穩定，但安全性是個嚴重的問題，而且FTP服務器讀用户庫獲取權限，這樣對於用户使用來説還是不太方便。 剩下只有HTTP。在HTTP中有3種方式，PUT、WEBDAV、RFC1867，前2種方法不適合大文件上傳，基本上我們使用的web上傳都是基於RFC1867標準的HTML中基於表單的文件上傳。

現有的HTML規範為INPUT元素的TYPE屬性定義了八種可能的值，分別是：CHECKBOX， HIDDEN，MAGE，PASSWORD，RADIO，RESET，SUBMIT，TEXT。 另外，當表單採用POST方式的時候，表單默認的具有“application/x-www-form-urlencoded”的ENCTYPE屬性。

RFC1867標準對HTML做出了兩處修改：

（1）為INPUT元素的TYPE屬性增加了一個FILE選項。

（2）INPUT標記可以具有ACCEPT屬性，該屬性能夠指定可被上傳的文件類型或文件格式列表。

另外，本標準還定義了一種新的MIME類型：multipart/form-data，以及當處理一個帶有ENCTYPE="multipart/form-data" 並且/或含有<INPUT type="file">的標記的表單時所應該採取的行為。

舉例來説，當HTML表單作者想讓用户能夠上傳一個或更多的文件時，他可以這麼寫：

<FORM ENCTYPE="multipart/form-data" ACTION="_URL_" METHOD=POST>

File to process:

<INPUT NAME="userfile1" TYPE="file">

<INPUT TYPE="submit" VALUE="Send File">

</FORM>

HTML DTD裏所需要做出的改動是為InputType實體增加一個選項。此外，我們也建議用一系列用逗號分隔的文件類型來作為INPUT標記的ACCEPT屬性。

... (其他元素) ...

＜!ENTITY % InputType＞(TEXT | PASSWORD | CHECKBOX |

RADIO | SUBMIT | RESET |

＜IMAGE | HIDDEN | FILE＞

＜!ELEMENT INPUT - 0 EMPTY＞

＜!ATTLIST INPUT＞

TYPE %InputType TEXT

NAME CDATA #IMPLIED -- required for all but submit and reset

VALUE CDATA #IMPLIED

SRC %URI #IMPLIED -- for image inputs --

CHECKED (CHECKED) #IMPLIED

SIZE CDATA #IMPLIED --like NUMBERS,

but delimited with comma, not space

MAXLENGTH NUMBER #IMPLIED

ALIGN (top|middle|bottom) #IMPLIED

ACCEPT CDATA #IMPLIED --list of content types

... (其他元素) ...

2.文件傳輸延遲

在某些情況下，在確實準備接受數據前，服務器先對表單數據中的某些元素（比如説用户名，賬號等）進行驗證是推薦的做法。但是，經過一定的考慮後，我們認為如果服務器想這樣做的話，最好是採用一系列的表單，並將前面所驗證過的數據元素作為“隱藏”字段傳回給客户端，或者是通過安排表單使那些需要驗證的元素先顯示出來。這樣的話，那些需要做複雜的應用的服務器可以自己維持事務處理的狀態，而那些簡單的應用的則可以實現得簡單些。

HTTP協議可能需要知道整個事務處理中的內容總長度。即使沒有明確要求，HTTP客户端也應該提供上傳的所有文件的內容總長度，這樣一個繁忙的服務器就能夠判斷文件的內容是否是過大以至於將不能完整地處理，從而返回一個錯誤代碼並關閉該連接，而不用等到接受了所有的數據才進行判斷。一些現有的CGI應用對所有的POST事務都需要知道內容總長度。

如果INPUT標記含有一個MAXLENGTH屬性，客户端可以將這個屬性值看作是服務器端所能夠接受的傳送文件的最大字節數。在這種情況下，服務器能夠在上傳開始前，提示客户端在服務器上有多少空間可以用來進行文件上傳。但是應該引起注意的是，這僅僅是一個提示，在表單被創建後和文件上傳前，服務器的實際需求可能會發生改變。

在任何情況下，如果接受的文件過大的話，任何一個HTTP服務器都有可能在文件傳輸的過程中中斷傳輸。

有些人曾經建議使用一種新的MIME類型"aggregate"，比如説aggregate/mixed 或是content-transfer-encoding "包"來描述那些不確定長度的二進制數據，而不是靠分解為多個部分來表示。雖然我們並不反對這麼做，但這需要增加額外的設計和標準化工作來讓大家接受並理解"aggregate"。 從另一方面來説，"分解為多部分"的機制工作得很好，能夠非常簡單的在客户發送端和服務器接受端加以實現，而且能像其他一些綜合處理二進制數據的方式一樣高效率地工作。

看了N多代碼之後發現，無組件程序和一些COM組件都是使用Request.BinaryRead方法。一次性得到上傳的數據，然後分析處理。這就是為什麼上傳大文件很慢的原因了，IIS超時不説，就算幾百M文件上去了，分析處理也得一陣子。

瞭解了一下國外的商業組件，比較流行的有Power-Web，AspUpload,ActiveFile,ABCUpload,aspSmartUpload,SA-FileUp。其中比較優秀的是ASPUPLOAD和SA-FILE，他們號稱可以處理2G的文件(SA-FILE EE版甚至沒有文件大小的限制)，而且效率也是非常棒，難道編程語言的效率差這麼多?查了一些資料,覺得他們都是直接操作文件流。這樣就不受文件大小的制約。但老外的東西也不是絕對完美，ASPUPLOAD處理大文件後,內存佔用情況驚人。1G左右都是稀鬆平常。至於SA-FILE雖然是好東西但是破解難尋。然後發現2款.NET上傳組件，Lion.Web.UpLoadModule和AspnetUpload也是操作文件流。但是上傳速度和CPU佔用率都不如老外的商業組件。

做了個測試，LAN內傳1G的文件。ASPUPLOAD上傳速度平均是4.4M/s，CPU佔用10-15，內存佔用700M。SA-FILE也差不多這樣。而AspnetUpload最快也只有1.5M/s，平均是700K/s，CPU佔用15-39，測試環境: PIII800,256M內存,100M LAN。我想AspnetUpload速度慢是可能因為一邊接收文件，一邊寫硬盤。資源佔用低的代價就是降低傳輸速度。但也不得不佩服老外的程序，CPU佔用如此之低.....。

我們在上傳大文件時都遇到過這樣或那樣的問題。設置很大的maxRequestLength值並不能完全解決問題，因為會block直到把整個文件載入內存後，再加以處理。實際上，如果文件很大的話，我們經常會見到Internet Explorer顯示 "The page cannot be displayed - Cannot find server or DNS Error"，好像是怎麼也catch不了這個錯。為什麼？因為這是個client side錯誤，server side端的Application_Error是處理不到的。

解決的方法是利用隱含的HttpWorkerRequest，用它的GetPreloadedEntityBody 和 ReadEntityBody方法從IIS為建立的pipe裏分塊讀取數據。Chris Hynes為我們提供了這樣的一個方案(用HttpModule)，該方案除了允許你上傳大文件外，還能實時顯示上傳進度。

Lion.Web.UpLoadModule和AspnetUpload 兩個.NET組件都是利用的這個方案。

利用HttpHandler實現了類似於ISAPI Extention的功能，處理請求(Request)的信息和發送響應(Response)。

1． httpHandler or HttpModule

a.分塊讀取和寫入數據

b.實時跟蹤上傳進度更新meta信息

2． 利用隱含的HttpWorkerRequest用它的GetPreloadedEntityBody 和 ReadEntityBody方法處理文件流

3． 自定義Multipart MIME 解析器。

自動截獲MIME分割符。

將文件分塊寫如臨時文件。

實時更新Appliaction 狀態（ReceivingData, Error, Complete） 。

1 SmartUpload 用的最多的一個組件，已經不再更新了，可以實現上傳和下載

2 FileUpload Apache實現的文件上傳組件，功能齊備

3 J2KUpload java2000實現的文件上傳組件，全部使用內存，適合多個不超過10M的小文件

ASP .NET Wijmo的Upload控件

ASP.NETWijmo的HTML5視頻播放器Video Player，是ComponentOne為ASP .NET Wijmo出品的Upload控件，可以提供一個簡單和可靠的方式來將文件和數據流上傳到服務器。

全屏模式：它可以允許最終用户在全屏模式下查看HTML5視頻播放器。它們可以在全屏幕模式和標準模式之間進行切換。

控制按鈕：HTML5視頻播放器配有標準的控制按鈕，如播放、暫停、靜音、音量控制，以及全屏顯示。當你需要將顯示區域最大化時，你可以自動隱藏控制欄。

主題：只需點擊一下智能標籤，就可以通過從六個溢價主題（北極，午夜時分，雅集，火箭，鈷和英鎊）中選擇一個來改變視頻播放器的外觀。另外，還可以使用jQuery UI的ThemeRoller來創建一個自定義的主題。