深入研究“用ASP上载文件”(一)
程序员文章站
2022-04-19 13:38:05
现在“瘦客户”的观点已经是一个神话了，但随着电视或掌上型的繁荣，这一状况会有所改变。今天绝大多数的网络客户仍使用功能强大的pc，附着着大量的客户端存储器和客户端感兴趣的内容。在in...
现在“瘦客户”的观点已经是一个神话了，但随着电视或掌上型的繁荣，这一状况会有所改变。今天绝大多数的网络客户仍使用功能强大的pc，附着着大量的客户端存储器和客户端感兴趣的内容。在internet协议下，将文件传递到*服务器有一些方法可供选择，但基于web的文件上载比其它方法都要高级。下面来检验这一点。
一、http与ftp的方式比较
为什么要上载？
文件上载对任何网络应用程序来说都起到重要作用。这里有一些例子，是关于我们的一些客户如何把文件上载并他们的web应用程序结合起来的：
1、基于web的e-mail形式，用文件上载给邮件信息增加附件
2、外部互联网应用程序用文件上载在伙伴间传送文件，如协议证明、软件更新或文件
3、技术支持站点用文件上载从用户中接收错误记录和有问题文件
4、企业内部互联网的文献出版用友好的网络接口在用户间分享文件
5、图形库用文件上载控制提交、产生略图
6、isp主机店面用文件上载发送产品图象
http与ftp的方式比较
在tcp/ip的早期，ftp是向服务器传输文件的标准机制。它可靠、可接受文本和二进制格式，客户可以在任何地方执行，但是它远远不及http的适应性强。下面来比较一下：
■ 可靠性：用ftp上载，要么管理大量的用户帐号，要么就允许匿名访问。用web应用程序上载，应用程序可以确定允许谁上载，免除了极大的管理负担。
■ 安全性：通过http上载可用ssl编码，这样一来信息可以在传输过程中。用ftp就无法作到。
■ 配置难易：ftp上载要求管理员精确地调节ntfs许可。用基于http的上载和应用程序，管理员和应用程序都可以决定，如果需要的话。
■ 适应性：你想在一个地方存储doc文件，在另一处存储图形吗？使用ftp的话，用户必须知道这些存储路径。而在web应用程序中，你可以自行控制，不用打扰用户就可以进行修改。
■ 能力：用web应用程序，每次调用都可以动态地控制上载文件的大小，甚至可以根据同一个表单中的信息改变大小。另外还可以冲掉符合一定标准的上载文件，如错误的mime类型或文件类型。
■ 界面的简易友好性：招人喜欢的网页可以提供指导、建议、在线帮助，而基于批处理的ftp是不可能作到的。更重要的是发生错误时，web方式可以立刻向用户提供反馈并作出纠正。
■ 防火墙支持：出于安全和知识产权方面的考虑，许多机构不允许外部的ftp。通过简单的配置，大多数防火墙都支持http。
■ 补充信息：一个http上载（用rfc1867）还提供其它可用信息，例如用户的原始文件名，这在内部互联网环境下特别有用。
■ 上载到一个：利用服务器端，如sa-fileup，允许上载到ole db数据库。但用ftp，却绝对做不到这点！
■ 性能：ftp和http最终都是用tcp协议，这是决定传输性能的决定因素。
■ 可靠性及重新上载：ftp和http 1.1都允许传输重新启动。不幸地是许多服务器包括iis，现在都不能支持任意一种协议的重新上载功能。ftp的重新上载功能将在iis5版本中实现。
总之，同web本身一样，服务器的可性使http上载比ftp具有极大的优势。
http上载格式
通过http上载有三种文件机制，它们是rfc1867、put和webdav。
http上载方法1：rfc1867
html 3.2最终推出w3c之前的一段时期，rfc1867 () 是ietf的建议标准。首先是netscape在navigator 2.0中运行，跟着microsoft 把它作为ie 3.02 (32-bit) 的附加和ie 3.03 (16-bit)的自带内容。它是一个非常简单但又很强大的概念：定义一个格式域的新类型
< input type= "file" >
然后向表单中填加不同的编码方案：
< form action="formproc." method="post" enctype="multipart/form-data" >
而不是用典型的：
< form action="formproc.asp" method= "post" >
在传输大量数据时，这种编码方案比默认的"application/x-url-encoded"格式编码方案效率高。正如你也许知道的，url可用的字符集是很有限的。任何超出范围的字符集都要用%nn来代替，在这里nn是相应的两位十六进制数。即使是最常用的空格字符也要用%20来代替。如果浏览器不得不用效率如此低的编码方法对整个文件进行编码，那么上载文件的传输规模有可能比原始文件大2到3倍。而rfc1867用multipart mime编码，就象通常在e-mail信息中所见到的，在传输大量数据时不用编码，而只是在数据周围有几个简单有用的头。
一、http与ftp的方式比较
为什么要上载？
文件上载对任何网络应用程序来说都起到重要作用。这里有一些例子，是关于我们的一些客户如何把文件上载并他们的web应用程序结合起来的：
1、基于web的e-mail形式，用文件上载给邮件信息增加附件
2、外部互联网应用程序用文件上载在伙伴间传送文件，如协议证明、软件更新或文件
3、技术支持站点用文件上载从用户中接收错误记录和有问题文件
4、企业内部互联网的文献出版用友好的网络接口在用户间分享文件
5、图形库用文件上载控制提交、产生略图
6、isp主机店面用文件上载发送产品图象
http与ftp的方式比较
在tcp/ip的早期，ftp是向服务器传输文件的标准机制。它可靠、可接受文本和二进制格式，客户可以在任何地方执行，但是它远远不及http的适应性强。下面来比较一下：
■ 可靠性：用ftp上载，要么管理大量的用户帐号，要么就允许匿名访问。用web应用程序上载，应用程序可以确定允许谁上载，免除了极大的管理负担。
■ 安全性：通过http上载可用ssl编码，这样一来信息可以在传输过程中。用ftp就无法作到。
■ 配置难易：ftp上载要求管理员精确地调节ntfs许可。用基于http的上载和应用程序，管理员和应用程序都可以决定，如果需要的话。
■ 适应性：你想在一个地方存储doc文件，在另一处存储图形吗？使用ftp的话，用户必须知道这些存储路径。而在web应用程序中，你可以自行控制，不用打扰用户就可以进行修改。
■ 能力：用web应用程序，每次调用都可以动态地控制上载文件的大小，甚至可以根据同一个表单中的信息改变大小。另外还可以冲掉符合一定标准的上载文件，如错误的mime类型或文件类型。
■ 界面的简易友好性：招人喜欢的网页可以提供指导、建议、在线帮助，而基于批处理的ftp是不可能作到的。更重要的是发生错误时，web方式可以立刻向用户提供反馈并作出纠正。
■ 防火墙支持：出于安全和知识产权方面的考虑，许多机构不允许外部的ftp。通过简单的配置，大多数防火墙都支持http。
■ 补充信息：一个http上载（用rfc1867）还提供其它可用信息，例如用户的原始文件名，这在内部互联网环境下特别有用。
■ 上载到一个：利用服务器端，如sa-fileup，允许上载到ole db数据库。但用ftp，却绝对做不到这点！
■ 性能：ftp和http最终都是用tcp协议，这是决定传输性能的决定因素。
■ 可靠性及重新上载：ftp和http 1.1都允许传输重新启动。不幸地是许多服务器包括iis，现在都不能支持任意一种协议的重新上载功能。ftp的重新上载功能将在iis5版本中实现。
总之，同web本身一样，服务器的可性使http上载比ftp具有极大的优势。
http上载格式
通过http上载有三种文件机制，它们是rfc1867、put和webdav。
http上载方法1：rfc1867
html 3.2最终推出w3c之前的一段时期，rfc1867 () 是ietf的建议标准。首先是netscape在navigator 2.0中运行，跟着microsoft 把它作为ie 3.02 (32-bit) 的附加和ie 3.03 (16-bit)的自带内容。它是一个非常简单但又很强大的概念：定义一个格式域的新类型
< input type= "file" >
然后向表单中填加不同的编码方案：
< form action="formproc." method="post" enctype="multipart/form-data" >
而不是用典型的：
< form action="formproc.asp" method= "post" >
在传输大量数据时，这种编码方案比默认的"application/x-url-encoded"格式编码方案效率高。正如你也许知道的，url可用的字符集是很有限的。任何超出范围的字符集都要用%nn来代替，在这里nn是相应的两位十六进制数。即使是最常用的空格字符也要用%20来代替。如果浏览器不得不用效率如此低的编码方法对整个文件进行编码，那么上载文件的传输规模有可能比原始文件大2到3倍。而rfc1867用multipart mime编码，就象通常在e-mail信息中所见到的，在传输大量数据时不用编码，而只是在数据周围有几个简单有用的头。