网站程序上传到服务器方法汇总（2）

大文件上传

以前也做过文件上传，但都是些小文件，不超过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--