來源
上傳一詞來自英文（Upload），拆開來“Up”為“上”，“Load”為“載”，故上傳也叫上載，與下載（Download）是逆過程。
分類
上傳上傳分為Web上傳和Ftp上傳，前者直接通過點擊網頁上的連結即可操作，後者需要專用的FTP工具。
區別
WEB上傳 與 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伺服器上，下面是常見的五種方法。
1、使用FTP軟體上傳主頁檔案
這是最常用、最方便也是功能最為強大的主頁上傳方法。雖然網上這類軟體很多，像Filezilla、CuteFtp、FlashFXP等已經廣受網友歡迎。這類軟體除了可以完成檔案傳輸的功能以外，還可以通過它們完成站點管理、遠程編輯伺服器檔案等工作，一些常用的FTP軟體還有斷點續傳、任務管理、狀態監控等功能，可以讓你的上傳工作變得非常輕鬆。
2、使用“兼職”的FTP軟體上傳主頁檔案
所謂兼職的FTP軟體，是指軟體本身並不是專門用來完成FTP功能的，主頁上傳只是其編外任務。例如我們常用的FrontPage、Dreamweaver、東方主頁王Ⅱ等都有主頁上傳、發布的功能。使用這類軟體的好處是可以在編輯主頁的同時就上傳到伺服器上查看主頁效果，省去了啟動軟體、登錄、設定等諸多麻煩。但是，這種方法往往上傳速度較慢，且難以對伺服器上的檔案進行管理。
3、使用Web頁面上傳主頁檔案
和前面兩種方法相比，這種方法不但沒有什麼明顯的優點，而且速度緩慢、操作麻煩、不支持斷點續傳。但是，如果你恰恰申請了一個這樣的不支持FTP的免費主頁空間，那么就只能使用這種笨拙的方法了！
4、通過命令上傳主頁檔案
在很久很久以前，Unix系統上的FTP程式是基於命令行的，如今的Window95/98/NT/2000/Me仍然有基於命令行的FTP程式(進入DOS模式，輸入FTP就可以了)。使用這種方法首先要掌握幾十條命令不說，而且螢幕上通常只能顯示25或50行文字，很不方便。圖形界面的FTP軟體流行之後，這種方法已經被大多數網友拋棄了，只供少數骨灰級的網蟲練習他們的指法。
5、通過E-mail上傳
這種方法要求你把主頁檔案通過E-mail發給系統管理員，然後再由系統管理員把它們放到伺服器上。這是最簡單也是最複雜的方法，隨著網路條件的提高，這種方法已逐漸銷聲匿跡了。
大檔案
基於WEB的檔案上傳可以使用FTP和HTTP兩種協定，用FTP的話雖然傳輸穩定，但安全性是個嚴重的問題，而且FTP伺服器讀用戶庫獲取許可權，這樣對於用戶使用來說還是不太方便。 剩下只有HTTP。在HTTP中有3種方式，PUT、WEBDAV、RFC1867，前2種方法不適合大檔案上傳，基本上我們使用的web上傳都是基於RFC1867標準的HTML中基於表單的檔案上傳。
RFC1867：
1．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伺服器都有可能在檔案傳輸的過程中中斷傳輸。
3.傳輸二進制數據的其他解決辦法
有些人曾經建議使用一種新的MIME類型"aggregate"，比如說aggregate/mixed 或是content-transfer-encoding "包"來描述那些不確定長度的二進制數據，而不是靠分解為多個部分來表示。雖然我們並不反對這么做，但這需要增加額外的設計和標準化工作來讓大家接受並理解"aggregate"。 從另一方面來說，"分解為多部分"的機制工作得很好，能夠非常簡單的在客戶傳送端和伺服器接受端加以實現，而且能像其他一些綜合處理二進制數據的方式一樣高效率地工作。
RFC上傳
1．一次性得到上傳的數據，然後分析處理。
看了N多代碼之後發現，無組件程式和一些COM組件都是使用Request.BinaryRead方法。一次性得到上傳的數據，然後分析處理。這就是為什麼上傳大檔案很慢的原因了，IIS逾時不說，就算幾百M檔案上去了，分析處理也得一陣子。
2．一邊接收檔案，一邊寫硬碟。
了解了一下國外的商業組件，比較流行的有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） 。
上傳組件
JAVA實現檔案上傳的幾個組件
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來創建一個自定義的主題。
