★为什么上传?

"瘦客户端"的观念在今天看来是个神话。也许随着电视浏览器或者是掌上型浏览器的繁衍，情况会有所变化。但是在今天，大量的web客户端使用功能强大的PC，它们拥有很大的存贮空间和许多有趣的客户端内容。

事实上，文件上传对于任何web应用程序都是很有用的一个功能。以下是我们的一些客户如何在他们的web应用程序中集成文件上传的例子：

基于web的e-mail使用文件上传在消息中加入附件。

外部网络应用程序使用文件上传在合作对象间发送文件，比如一致性验证、软件更新或者是软件管理。

技术支持站点使用文件上传从用户处接收错误日志和缺陷报告文档。

内部网文档出版使用文件上传，通过友好的web界面在用户间共享文件。

图形库使用文件上传控制提交，并且生成小图标。

ISP经营的店面使用文件上传发送产品图型。

对比其他通过Internet协议将文件发送到中央服务器的方法，基于web的文件上传是一种高级得多的替代手段。让我们检查一下为什么会这样。

★HTTP 对比 FTP

从TCP/IP最早出现，FTP已经成为将文件发送到服务器的标准机制。它很可靠，能够考虑到跨平台的文本和二进制格式，并且拥有很普遍的客户。然而对比灵活的HTTP，它却有很大的缺陷。让我们比较一下：

认证: 通过FTP上传，你要么需要管理大量的用户帐号，要么允许匿名访问。通过web应用程序上传，应用程序能够判断谁有资格上传，免去了大量的管理负担。

安全: HTTP上传能够使用SSL编码，以便传输过程中信息是加密的。而标准FTP上传则无此功能。

设置的删除: FTP上传需要管理员精确的调节NTFS权限。基于HTTP的上传结合你的应用程序，使得这种调节可以根据你的喜好让程序自己决定，同样也能由管理员决定。

灵活性: 想把DOC文件存放在一处，而图形文件存放在另一处吗？使用FTP，你的用户必须知道那些。而通过web应用程序，你可以在程序中指定好这些方案，改变时也不会打扰你的用户。

功能: 通过一个web应用程序，你可以在上传的文件每次被激活的时候动态限制文件大小。你甚至可以根据同一个表单中的信息来改变文件大小。除此之外，你还能撤除那些符合特定标准的上传，比如错误的MIME类型或者错误的文件内容。

简单和友好: 一个好的页面可以提供指示、建议、在线帮助。这对于基于批处理的FTP是不可能的。更重要的是，当错误发生时，你能即时给用户提供反馈并采取修正方法。

防火墙支持: 许多组织出于安全性和知识产权的考虑，不允许超出范围的FTP。虽然这仅仅是个设置的问题，但是大多数防火墙允许HTTP上传。

附加信息: 一个HTTP上传（使用RFC1867）产生能够访问的关于上传的额外信息，比如用户的原文件名。这在内部网的场合会非常有用。

上传至数据库: 服务器端组件，象SA-FileUp,允许你上传到一个OLE DB数据库。用FTP试试看！

性能: FTP和HTTP最终都使用TCP协议，正是它对于传输性能起着主要的决定性因素。

可靠性和重新开始: FTP和HTTP 1.1都允许传输重新开始。然而不幸的是，许多服务包括IIS目前都还不支持任何一种协议的重新开始。很明显IIS5将包含FTP重新开始功能。

简言之，象web自身一样，正是在服务器端的可编程性使得HTTP相比较FTP上传而言具有巨大的优势。

★HTTP上传的形式

通过HTTP上传有三种机制：RFC1867, PUT 和 WebDAV.

HTTP上传方式1: RFC1867

★RFC1867 (http://info.internet.isi.edu/in-notes/rfc/files/rfc1867.txt)

在最终被W3C在HTML3.2 中接受前，是作为一种建议标准。它首先被网景在Navigator2.0中采用，随后被微软作为IE3.02(32位版）的附件和IE3.03(16位版）的一部分。它是一种非常简单但是功能很强大的想法：在表单字段中定义一个新类型。

<INPUT TYPE="FILE">

并且在表单本身加入了不同的编码方案，不再使用典型的：

<form ACTION="formproc.asp" METHOD="POST">

而是使用

<form ACTION="formproc.asp" METHOD="POST" ENCTYPE="multipart/form-data">

这种编码方案在传送大量数据的时候，比起缺省的"application/x-url-encoded"表单编码方案，显得效率要高得多。象你可能会意识到的那样，URL编码只有很有限的字符集。使用任何超出字符集的字符，必须用'%nn' 代替，这里的nn表示相应的2个十六进制数字。例如，即使是普通的空格字符也要用'%20'代替。如果浏览器不得不使用这种低效的手段对整个文件编码，那么传送的文件会是原始文件的2-3倍大！取而代之，RFC1867 使用多部分MIME编码，就象通常在e-mail消息中看到的那样，不编码来传送大量数据，而只是在数据周围加上很少的简单但实用的头部。

结果看起来象是通常的HTML的form Post，但是说起来是4KB的表单数据，却有可能达到上兆字节的长度！

RFC1867也建议浏览器厂商必须采纳对TYPE="FILE"标签提出的几个属性的建议。包括：

ACCEPT: 让web站点在接受文件前限制文件类型。

SIZE: 让站点设置单个文件名文本框的大小或者用一个<INPUT>标签允许多个文件。

MAXLENGTH: 在客户端潜在的设置将要传送的文件的最大长度。

Wildcards and directory uploads: 虽然RFC建议使用通配符或者字典，但IE和Navigator都不支持

幸运的是，两个浏览器的厂商都采用了建议的“浏览...”按钮，是用户能很容易的使用本地"打开文件..." 对话框选择要上传的文件。

数值项的使用很有趣。通常出于用户方便考虑，让web站点预设表单字段的值是很自然的。但是这样的话，就会使得不法web站点能够预设要上传的文件名，并伴随一个客户端的表单提交，从而不经过用户的允许就“窃取”他们PC里的文件。在1997年夏季，CERT协同一名贝尔实验室的雇员，针对这个问题发布了安全性警告，网景和微软迅速发布补丁来阻止预设文件被上传。

(请见http://www.microsoft.com/ie/security/bell.htm)

这很不幸，因为原本RFC1867就清楚的祥述过“用户代理不应该发送任何用户没有明确要求被发送的文件，这是非常重要的。”因此，与其整个关掉名字预设功能，倒不如浏览器简单的产生一个警告对话框，比如：“你想传送文件x,y,z到服务器吗？”。然而作为这件事最后的一个麻烦，10月中旬在IE4.01中发现了另外一个安全漏洞，这个漏洞能够让web站点绕过IE现有的安全机制。

(见http://www.microsoft.com/windows/ie/security/paste.htm)

★HTTP 1.1引入了一个新的HTTP动词：PUT。当web服务器收到一个HTTP PUT和对象名字("/myweb/image/x.gif")，它将会验证用户，接收HTTP流的内容，并把它直接存入web服务器。由于这可能会对一个web站点造成破坏，因而并不常用。它还会失去HTTP最大的优势：服务器可编程性。在PUT的情况下，服务器自己处理请求：没有空间让CGI或者ASP应用程序介入。唯一让你的应用程序捕获PUT的方法是在低层操作，ISAPI过滤层。由于相应的原因，大多数web开发者对此毫无兴趣。

★HTTP上传方式3: WebDAV

WebDAV (http://www.ietf.org/html.charters/webdav-charter.html)允许web

内容的分布式认证与翻译。

它引入了几种新的HTTP动词，允许通过HTTP上传，锁定/解锁，登记/检验web内容。

将其想象成为一种非私有的配置管理加上web文件传输。微软已经公开宣称将在IIS5、Office 2000和后续版本的IE中支持它。ISP将会喜欢把它作为低层的、经常坏掉的FrontPage Server Extensions的替代品。注意，它并不会替代Frontpage server extensions:它将仅仅提供低层标准的服务来支持server extensions目前执行的更为精密复杂的功能。

正是通过WebDAV，Office 2000才能做到你可能在98年10月的PDC上看到的，那些漂亮的"Save to web"功能。

听起来真不错，是吗？好了，如果你所感兴趣的一切都是上传内容，WebDAV确实棒极了。它解决了很多问题。

然而，如果你需要在在你的web应用程序里面上传文件，WebDAV对你就毫无用处可言。象HTTP PUT一样，那些WebDAV的动词是被服务器解释的，而不是你的web应用程序。你需要工作在ISAPI过滤层来访问WebDAV的这些动词，并在你的应用程序中解释内容。

★HTTP上传机制: 结论

RFC1867仍然将大多数文件上传的灵活方法留给了你的web应用程序。PUT用得很有限。WebDAV对内容的作者很有用，比如FrontPage用户，但是对想在web应用程序中加入文件上传的web开发者来说很少用到。

★用ASP实现

我们得出结论，RFC1867是在web应用程序中加入文件上传的最好的办法。它是如何实际应用的呢？微软提供了什么工具？还有其它哪些工具可用？

★微软的Posting Acceptor

ASP不懂"multipart/form-data" 编码方案。取而代之，微软免费提供了Posting Acceptor (http://www.microsoft.com/iis/support/iishelp/iis/htm/core/pareadme.htm).

Posting Acceptor是一种在上传完成后，接受REPOST到一个ASP页的ISAPI应用程序。

（请见Scott Stanfield 98年7月的文章issue of MIND）

★Software Artisans的SA-FileUp

SA-FileUp (http://www.softartisans.com/softartisans/saf.html)是最早的商业Active Server组件之一。97年5版本发行的版本1现在使用在全世界成千上万的站点上，包括microsoft.com。早期的beta版为了和ASP集成，将ISAPI过滤和Active Server组件结合在一起。随后微软发布了ASP 1.0b(ASP.DLL1.15.14.0) ，提供了几种新的方法：Request.BinaryRead。BinaryRead方法使得从浏览器到一个Active Server组件的

原始的，未处理过的数据得以利用。当这些数据能够得到利用时，SA-FileUp丢掉了ISAPI过滤的必要，并且现在作为一个纯粹的ASP组件存在。

使用Request.BinaryRead，就如同SA-FileUp一样,和Request.form对象是相互排斥的。 这意味着: 由于原本的数据流是表单信息，你如何能够从浏览器中读出它的同时解析它?为了减轻ASP开发者的负担，SA-FileUp在他自己的.form集合中重新实现了所有Request.form的功能。这使得那些习惯用Request.form的程序员对使用SA-FileUp变得熟悉。

★Posting Acceptor与SA-FileUp对比

这里是PA和SA-FileUp有可能做对比的地方：

ASP 集成: SA-FileUp能完全的用ASP写脚本。而不是作为一个分离的ISAPI DLL存在，Sa-FileUp和你的ASP应用程序结合的非常平滑。

支持标准: IE浏览器里的PA上传使用专利的WebPost API，而非标准的RFC 1867标准，因此，缺省的，针对Netscape和IE用户，你要采用不同的表单。

匿名连接: 由于PA使用一个ISAPI DLL, 它必须在你的ASP应用程序之外提供额外的安全保障。因此，PA缺省的是禁止所有匿名连接的。PA1.1能允许匿名上传，但是由于对上传有程序控制，所以这里存在很大的安全隐患。而SA-FileUp与ASP集成在一起，你的应用程序能够决定安全权限级别，包括匿名。

上传控制: 传送过程中PA不允许任何上传控制。而使用SA-FileUp，你能限制上传大小，或者在执行中随时决定取消上传。最好的地方是，你能动态改变上传的地方。

过程: PA有2步上传和重新发送过程。而通过SA-FileUp，所有事情都能一步解决，比如写入数据库依赖于上传的状态。

上传至数据库: PA只能上传到文件。SA-FileUp能上传到文件，也能上传到数据库。

"文件名中的空格": PA处理包含空格的文件名时有个众所周知的问题，而SA-FileUp无此限制。

价格: PA随NT Option Pack捆绑， 并能从微软那里免费下载。SA-FileUp则不是免费的：它是提供支持的商用组件。

Scott Stanfield，Vertigo软件公司的总裁(http://www.vertigosoftware.com ), 98年7月Mind杂志上Posting Acceptor一文的作者，在MIND出版后，写信给Artisans软件公司关于SA-FileUp的学习：

“对于SA-FileUp的学习我们非常兴奋。妙极了，非常有价值的产品 ”

目前为止，最为普遍认同的问题是有关文件上传的安全问题。通常一个站点过于仔细的设置NTFS的安全权限，使得匿名用户无法写入目标文件所在处。而且，即使是资深的服务器管理员也常常会误解安全性。

记住IIS/ASP在特定的安全上下文中执行每个ASP页面。如果没有验证机制，每个页面作为匿名用户执行。web管理员能够设置对应的匿名用户的NT帐号。

对于IIS3, 缺省匿名用户是IUSR_<计算机名>.

对于IIS4，所有处理中的web应用程序的缺省匿名用户是IUSR_<计算机名>（“在分离的内存空间中运行” 没有选中）。 所有不在处理中的web应用程序的缺省匿名用户名是IWAM_<计算机名>("在分离的内存空间中运行”被选中）。

使用SA-FileUp时，你必须确信适当的用户拥有对目标路径的读、写和删除权限。

如果强制认证，那么IIS/ASP在ASP页执行时将模仿认证过的用户。因此，认证过的用户的NT登录帐号必须拥有对目标路径的读、写权限。

对于IIS安全性的完整讨论已经超出了本文讨论的范围。请查看IIS4的Resource Kit以得到一个好的解释。

★我们来看一些代码

理论已经够了，让我们看看ASP代码看起来如何。

单个文件上传

这里是一段简单的上传单个文件的HTML表单：

<HTML> <HEAD>
<title>Please Upload Your File</title>
</HEAD>
<BODY>
<form enctype="multipart/form-data" method="post" action="formresp.asp">
Enter filename to upload: <input type="file" name="f1">
<input type="submit">
</form>
</BODY>
</HTML>
这里是文件 'formresp.asp'

<%@ LANGUAGE="VBSCRIPT" %>
<HTML><HEAD>
<title>Upload File Results</title>
</HEAD>
<BODY>
Thank you for uploading your file.
<% Set upl = Server.CreateObject("SoftArtisans.FileUp") %>
<% upl.SaveAs "C:\temp\upload.out" %><BR>
Total Bytes Written: <%=upl.TotalBytes%>
</BODY>
</HTML>

用附加表单元素上传

加入额外表单元素很简单。只要编码方式指定正确，它和普通HTML一样运做：
<HTML> <HEAD>
<title>Please Upload Your File</title>
</HEAD>
<BODY>
<form enctype="multipart/form-data" method="post" action="mformresp.asp">
Enter description: <input type="text" name="descrip">
Enter filename to upload: <input type="file" name="f1">
<input type="submit">
</form>
</BODY>
</HTML>

这里是文件'mformresp.asp':
<%@ LANGUAGE="VBSCRIPT" %>
<HTML><HEAD>
<title>Upload File Results</title>
</HEAD>
<BODY>
Thank you for uploading your file.
<% Set upl = Server.CreateObject("SoftArtisans.FileUp") %>
<% upl.SaveAs "C:\temp\upload.out" %><BR>
Your description is: '<%=upl.form("descrip")%>'<BR>
Total Bytes Written: <%=upl.TotalBytes%>
</BODY>
</HTML>
多个文件又如何
对于多个文件，由于浏览器不支持SIZE=属性，你必须对每个文件使用附加的<INPUT>标签:

输入第一个文件名:　<input type="file" name="f1">
输入第二个文件名: <input type="file" name="f2">

表单处理相同:
<%@ LANGUAGE="VBSCRIPT" %>
<HTML><HEAD>
<title>Multiple File Upload Results</title>
</HEAD>
<BODY>
Thank you for uploading your files.
<% Set upl = Server.CreateObject("SoftArtisans.FileUp") %>
<% upl.form("f1").SaveAs "C:\temp\upload1.out" %><BR>
Total Bytes Written for file 1: <%=upl.form ("f1").TotalBytes%>
<% upl.form("f2").SaveAs "C:\temp\upload2.out" %><BR>
Total Bytes Written for file 2: <%=upl.form ("f2").TotalBytes%>
</BODY>
</HTML>
限制上传大小
要限制上传大小，只需仅仅设置一个属性：
<%@ LANGUAGE="VBSCRIPT" %>
<HTML><HEAD>
<title>Upload File Results</title>
</HEAD>
<BODY>
Thank you for uploading your file.
<% Set upl = Server.CreateObject("SoftArtisans.FileUp") %>
<% upl.MaxBytes = 1000 '--- limit the upload size to 1000 bytes %>
The maximum size that you are permitted to upload is <% =upl.MaxBytes%> bytes per file.
<% upl.SaveAs "C:\temp\upload.out" %>
Total Bytes Written: <%=upl.TotalBytes%>
Server Filename: <%=upl.ServerName%>
Total Bytes Transmitted by you: <%=Request.TotalBytes%>
</BODY>
</HTML>
所有第1000个字节以后的内容都要被丢弃，因此web服务器的硬盘不会被不必要的填充。

★结论

上传文件至你的web应用程序很简单：能够通过仅仅2行ASP代码实现。HTTP/RFC1867上传是推荐的机制，因为服务器提供了丰富的编程环境。SA-FileUp作为ASP集成的Active Server组件，比起微软免费的Posting Acceptor，能提供更多的便利。

参考
SA-FileUp: http://www.softartisans.com/softartisans/saf.html
Posting Acceptor Newsgroup:
news://msnews.microsoft.com/microsoft.public.site-
server.postingacceptr
RFC1867:http://info.internet.isi.edu/in-notes/rfc/files/rfc1867.txt
WebDAV:http://www.ietf.org/html.charters/webdav-charter.html
David Wihl是Artisans软件公司的总裁。(http://www.softartisans.com)公司地处Brookline,MA,是一个迅速发展的高性能Active Server组件提供商。他是SA-FileUp最初的作者，并且仍然埋头工作于即将到来的激动人心的增强功能之中。可以这样联系他wihl@softartisans.com