|
|
上傳就是將信息從個人計算機(本地計算機)傳遞到中央計算機(遠程計算機)係統上,讓網絡上的人都能看到。將製作好的網頁、文字、圖片等發佈到互聯網上去,以便讓其他人瀏覽、欣賞。這一過程稱為上傳。 |
|
上傳一詞來自英文(upload),拆開來“up”為“上”,“load”為“載”,故上傳也叫上載,與下載(download)是逆過程。 |
|
上傳分為web上傳和ftp上傳,前者直接通過點擊網頁上的鏈接即可操作,後者需要專用的ftp工具。 |
|
web上傳與ftp上傳的區別
web上傳:即通過瀏覽器(ie)來上傳文件 。
1、通過ie瀏覽器上傳文件,按照“操作嚮導”一步步操作完成,用戶無須培訓;
2、通過分配用戶權限發佈課件,簡單,安全;
3、支持斷點續傳,支持大文件上傳;
4、上傳課件屬性(格式,上傳時間,人員等)自動生成,方便快捷;
5、上傳後的課件,配有審核機製,保證課件質量;
6、審核後的課件,自動歸類,用戶通過校園網瀏覽;
ftp上傳:簡稱文件傳輸協議,通過ftp上傳。
1、上傳之前,需要安裝專業上傳軟件,並對軟件加以學習,用戶需要學習上傳軟件;
2、需要建立ftp服務器及配置設置,專業性強;
3、不支持斷點續傳,衹能重新上傳,支持大文件上傳;
4、ftp上傳後,需要從後臺手工輸入課件屬性,費時費力;
5、ftp上傳後的課件,沒有審核機製;
6、ftp上傳的課件後需要手工進行歸類,比較煩麻; |
|
在上傳主頁之前,讓我們先來認識internet上一個基本的概念———ftp。它是英文“file transfer protocol”(文件傳輸協議)的縮寫,不過我們今天已經把它看成了一個動詞,意思是說在計算機和計算機之間傳輸文件。把自己製作好的主頁上傳到服務器上,就要用到ftp。
有許多種方法可以把主頁文件上傳到internet服務器上,下面是常見的五種方法。
1、使用ftp軟件上傳主頁文件
這是最常用、最方便也是功能最為強大的主頁上傳方法。現在網上這類軟件很多,像cuteftp、ws-ftp已經廣受網友歡迎。這類軟件除了可以完成文件傳輸的功能以外,還可以通過它們完成站點管理、遠程編輯服務器文件等工作,一些常用的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發給係統管理員,然後再由係統管理員把它們放到服務器上。這是最簡單也是最復雜的方法,隨着網絡條件的提高,這種方法已逐漸銷聲匿跡了。 |
|
以前也做過文件上傳,但都是些小文件,不超過2m。 這次要求上傳100m以上的東西。 沒辦法找來資料研究了一下。基於web的文件上傳可以使用ftp和http兩種協議,用ftp的話雖然傳輸穩定,但安全性是個嚴重的問題,而且ftp服務器讀用戶庫獲取權限,這樣對於用戶使用來說還是不太方便。 剩下衹有http。在http中有3種方式,put、webdav、rfc1867,前2種方法不適合大文件上傳,目前我們使用的web上傳都是基於rfc1867標準的html中基於表單的文件上傳。
一、先簡要介紹一下rfc1867(form-based file upload in html)標準:
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"。 從另一方面來說,"分解為多部分"的機製工作得很好,能夠非常簡單的在客戶發送端和服務器接受端加以實現,而且能像其他一些綜合處理二進製數據的方式一樣高效率地工作。
4.例子
假設服務器段提供的是如下的html:
<form action="http://server.dom/cgi/handle"
enctype="multipart/form-data"
method=post>
what is your name? <input type=text name=submitter>
what files are you sending? <input type=file name=pics>
</form>
用戶在“姓名”字段裏面填寫"joe blow",對問題'what files are you sending?',用戶選擇
了一個文本文件"file1.txt"。
客戶段可能發送回如下的數據:
content-type: multipart/form-data, boundary=aab03x
--aab03x
content-disposition: form-data; name="field1"
joe blow
--aab03x
content-disposition: form-data; name="pics"; filename="file1.txt"
content-type: text/plain
... file1.txt 的內容...
--aab03x--
如果用戶同時還選擇了另一個圖片文件"file2.gif",那麽客戶端可能發送的數據將是:
content-type: multipart/form-data, boundary=aab03x
--aab03x
content-disposition: form-data; name="field1"
joe blow
--aab03x
content-disposition: form-data; name="pics"
content-type: multipart/mixed, boundary=bbc04y
--bbc04y
content-disposition: attachment; filename="file1.txt"
content-type: text/plain
... file1.txt 的內容...
--bbc04y
content-disposition: attachment; filename="file2.gif"
content-type: image/gif
content-transfer-encoding: binary
... file2.gif的內容...
--bbc04y--
--aab03x--
二、利用rfc1867標準處理文件上傳的兩種方式:
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占用如此之低.....。
三、asp.net上傳文件遇到的問題
我們在用asp.net上傳大文件時都遇到過這樣或那樣的問題。設置很大的maxrequestlength值並不能完全解决問題,因為asp.net會block直到把整個文件載入內存後,再加以處理。實際上,如果文件很大的話,我們經常會見到internet explorer顯示 "the page cannot be displayed - cannot find server or dns error",好像是怎麽也catch不了這個錯誤。為什麽?因為這是個client side錯誤,server side端的application_error是處理不到的。
四、asp.net大文件上傳解决方案
解决的方法是利用隱含的httpworkerrequest,用它的getpreloadedentitybody 和 readentitybody方法從iis為asp.net建立的pipe裏分塊讀取數據。chris hynes為我們提供了這樣的一個方案(用httpmodule),該方案除了允許你上傳大文件外,還能實時顯示上傳進度。
lion.web.uploadmodule和aspnetupload 兩個.net組件都是利用的這個方案。
方案原理:
利用httphandler實現了類似於isapi extention的功能,處理請求(request)的信息和發送響應(response)。
方案要點:
1. httphandler or httpmodule
a.在asp.net進程處理request請求之前截獲request對象
b.分塊讀取和寫入數據
c.實時跟蹤上傳進度更新meta信息
2. 利用隱含的httpworkerrequest用它的getpreloadedentitybody 和 readentitybody方法處理文件流
iserviceprovider provider = (iserviceprovider) httpcontext.current;
httpworkerrequest wr = (httpworkerrequest) provider.getservice(typeof(httpworkerrequest));
byte[] bs = wr.getpreloadedentitybody();
....
if (!wr.isentireentitybodyispreloaded())
{
int n = 1024;
byte[] bs2 = new byte[n];
while (wr.readentitybody(bs2,n) >0)
{
.....
}
}
3. 自定義multipart mime 解析器。
自動截獲mime分割符。
將文件分塊寫如臨時文件。
實時更新appliaction 狀態(receivingdata, error, complete) 。 |
|
上傳分為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上傳絶無僅有的優勢,就是可以批量上傳、批量整理,不受太多限製。 |
|
1 SmartUpload 用的最多的一個組件,已經不再更新了,可以實現上傳和下載
2 FileUpload Apache實現的文件上傳組件,功能齊備
3 J2KUpload java2000實現的文件上傳組件,全部使用內存,適合多個不超過10M的小文件 |
|
軟件工具 | 下載 | 網絡 | 軟件 | 日本 | 視頻 | 動漫 | 字幕組 | java | SmartUpload | 基地 | 魔術 | 愛好者 | 魔客 | 網絡硬盤 | 存儲 | 共享 | 網盤 | 上傳工具 | |
|