上传一词来自英文（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中基于表单的档案上传。

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伺服器都有可能在档案传输的过程中中断传输。

有些人曾经建议使用一种新的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来创建一个自定义的主题。