最近做在做一個項目，涉及到文件上傳的問題。 以前也做過文件上傳。但都是些小文件，不超過2M。 這次要求上傳1G以上的東西。 沒辦法找來資料研究了一下。 基于WEB的文件上傳可以使用FTP和HTTP兩種協議，用FTP的話雖然傳輸穩定，但安全性是個嚴重的問題，所以沒有考慮。 剩下只有HTTP。 在HTTP中有3種方式，PUT、WEBDAV、RFC1867，前2種方法不適合大文件上傳，在這里也不說了。
確定使用RFC1867格式處理之后開始分析流行的上傳組件。看了N多代碼之后發現，目前無組件程序和一些COM組件都是使用Request.BinaryRead方法。一次性得到上傳的數據，然后分析處理。這就是為什么上傳大文件很慢的原因了，IIS超時不說，就算1G文件上去了，分析處理也得一陣子。 之后我把注意力放在國外商業組件上，比較流行的有Power-Web，
AspUpload,ActiveFile,ABCUpload,aspSmartUpload,SA-FileUp。其中比較優秀的是ASPUPLOAD和SA-FILE，他們號稱可以處理2G的文件(SA-FILE EE版甚至沒有文件大小的限制)，而且效率也是非常棒，難道編程語言的效率差這么多?(我的編程環境是
VB6) 查了一些資料,覺得他們都是直接操作文件流。這樣就不受文件大小的制約。 真是個好方法。
但老外的東西也不是絕對完美，ASPUPLOAD處理大文件后,內存占用情況驚人。1G左右都是稀松平常。我用的是3.0.0.3版。至于SA-FILE雖然是好東西但是破解難尋(郁悶死..) 失望之際，發現2款上傳組件，Lion.Web.UpLoadModule和
AspnetUpload，都是.NET的，估計也是操作文件流。但是上傳速度和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占用如此之低.....這樣2個.net的組件也被PASS.
稍帶2個問題就是上傳進度和斷點續傳。
顯示上傳進度比較簡單，主要是查詢用戶上傳的狀態，用Script顯示到瀏覽器中，至于無刷新顯示就要看腳本語言運用的熟練程度了。
斷點續傳，HTTP方式是實現不了的，因為瀏覽器每次上傳文件都是從頭開始，沒有Range標簽。實現的方法只能用ActiveX。
研究之后決定寫個CGI來處理文件上傳。 這樣可以不走IIS以免程序出錯影響網站訪問。小弟比較菜只能用
VB6做，完成之后發現WIN CGI的效率簡直就是差的不能再差。索性寫個FILE SERVER，專門處理文件的上傳。但是現在遇到一個2個問題。
一、用WINSOCK控件接收到的文本有亂碼 不知道是程序轉換時的錯誤還是WINSOCK本身垃圾，SO 換了PowerTCP的WINSOCK TOOL，情況有所好轉 亂碼沒那么多了.........準備換vb.net，直接操作socket，程序還沒做，不知道用.net接收會不會亂碼。再有就哭了。
二、這個問題就比較初級了....接收到的文件流不能還原成文件..寒一個，
最后就是如何高效處理文件流, 我想來想去也就只有2種方法，一是都放在內存里，然后一起處理， 二是一邊接收一邊寫文件。 但這2種方法都不盡如人意思