網站上傳方法匯總，制作好網頁后，如何把網頁上傳到申請的空間呢？為初學者做一個匯總。

上傳的定義

      上傳就是將信息從個人計算機（本地計算機）傳遞到中央計算機（遠程計算機）系統上，讓網絡上的人都能看到。將制作好的網頁、文字、圖片等發布到互聯網上去，以便讓其他人瀏覽、欣賞。這一過程稱為上傳。

上傳的來源

      上傳一詞來自英文（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） 。