rfc1867.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：黄俊（hujiao  [e-mail]）
译文发布时间：2001-4-26
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                           E. Nebel
Request For Comments: 1867                                   L. Masinter
Category: Experimental                                 Xerox Corporation
                                                           November 1995

                     HTML中基于表单的文件上传
(RFC1867  Form-based File Upload in HTML)

本备忘录的状态

本备忘录描述了一种Internet社区的试验协议。本备忘录并未规定任何Internet标准，它需
要进一步进行讨论和建议以得到改进。本备忘录的发布不受限制。

目录
1．摘要	2
2．带有文件提交功能的HTML表单	2
3．建议采纳的应用	3
3.1 FILE组件的显示	4
3.2提交之后的动作	4
3.3 multipart/form-data的使用	4
3.4其他属性的解释	5
4.向后兼容性的考虑	5
5.其他的考虑	6
5.1压缩，加密	6
5.2文件传输延迟	6
5.3传输二进制数据的其他解决办法	7
5.4 不修改<INPUT>	7
5.5字段内容的默认类型	8
5.6允许ACTION指向"mailto:"	8
5.7第三方传输的远程文件	8
5.8用ENCTYPE=x-www-form-urlencoded来传输文件	8
5.9将CRLF作为行分隔符	8
5.10和multipart/related的关系	9
5.11含有非ASCII码的字段名	9
6.例子	9
7. multipart/form-data的登记	10
8.安全性考虑	11
9.结论	11
作者地址：	12
A.为multipart/form-data登记的媒体类型	12
参考：	13

1．摘要

目前，HTML的表单让表单编写者能够通过表单得到浏览表单的用户的信息。在许多需要得
到用户输入的应用中，表单被证明是非常有用的。但是，因为HTML表单并没有提供让用
户可以上传文件或数据的途径，这种能力受到了一定的限制。所以那些需要从用户那儿得到
文件的服务提供商们不得不自己来建立相应的应用程序。（我们可以在www-talk邮件列表
中找到这类客户浏览器的例子。）既然文件上传是能够让许多应用程序受益的特点，这使得
人们要求扩展HTML，以便能让信息提供商们能够统一地处理文件上传请求，并为文件上传
响应提供统一的MIME兼容的表现形式。本方案同时也包括了一个向后保持兼容的策略介
绍，以便能让新的服务器能和现有的HTML客户端进行互动。

本建议独立于现有的各版本HTML。

2．带有文件提交功能的HTML表单

现有的HTML规范为INPUT元素的TYPE属性定义了八种可能的值，分别是：CHECKBOX, 
HIDDEN, IMAGE, PASSWORD, RADIO, RESET, SUBMIT, TEXT. 另外，当表单采用
POST方式的时候，表单默认的具有"application/x-www-form-urlencoded" 的ENCTYPE
属性。

本建议对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
          >

  ... (其他元素) ...

3．建议采纳的应用

因为用户端有多种途径来选择最合适的方式来解释HTML内容，本节针对其中的一种：
WWW浏览器来建议如何实现文件上传。

3.1 FILE组件的显示

当浏览器遇到一个FILE类型的INPUT标记时，它将显示一个文件名（或者是前面所选择
的文件名），和一个Browse（浏览）按钮或类似的选择方式。选择这个Browse（浏览）
按钮将触发浏览器对应于其所运行的平台相应的文件选择方式。举例来说，基于Windows
的浏览器将会弹出一个文件选择窗口。在这个文件选择窗口中，用户可以进行替换现有的选
择，为选择增加一个新的文件等操作。浏览器的设计者可以自己确定所选择的文件名列表是
否可以被用户手工修改。

如果该标记有ACCEPT属性，浏览器还可以限制符合该平台的文件类型。

3.2提交之后的动作

当用户填完了表单，并且选择了SUBMIT元素，浏览器应该将表单的内容和所选择的文件
的内容传回。对于传送那些大容量的二进制数据或包含非ASCII字符的文本来说，
application/x-www-form-urlencoded编码类型是远远不能满足要求的。于是，我们提出了一
种新的媒体类型：multipart/form-data，用来作为将填写好的表单内容从客户端传回到主机
端的高效方式。

3.3 multipart/form-data的使用

第7节里面对multipart/form-data做出了具体的定义。最极端的情况是选择中不包括任何数
据。（这种选择在某些情况下是非常可能的。）作为数据流的一部分，表单中的每一项内容
都按照它们在表单中出现的顺序被依次发送。每一部分由它们在HTML表单中INPUT标记
的名字所标识。如果该部分内容的类型是已知的，就用相应的媒体内容进行标识（举例来说，
可以从文件的扩展名或者从操作系统的相关类型信息中得知），否则的话，就标识为
application/octet-stream。

如果有多个文件被选中上传，它们必须按照multipart/mixed格式进行传输。

虽然HTTP协议能够传送任意形式的二进制数据，邮件传送（举例来说，如果表单的ACTION
是mailto的形式）的默认方式是7位编码。但是如果传送的内容和默认的编码方式不兼容
的话，所传送的内容将需要进行编码，并且加上一个"content-transfer-encoding"标识头。
（此方面详细内容可参看RFC 1521第5节）。

上传文件的原始文件名也应该一道被传送，或者是作为filename参数，或者是
'content-disposition: form-data'的标题头，如果传送的是多个文件的话，也可以是子内容中
的'content-disposition:file'的标题头。客户端应用程序应该尽量提供文件名。如果客户端操
作系统上的文件名包含有非US-ASCII字符，文件名可以用类似的字符或者是按照RFC1522
中描述的方法进行编码。这在某些情况下有其便利之处，比如说上传的文件中可能包含互相
关联的关系，例如一个TeX文件可能会有一个后缀为.sty的附加类型描述文件。

在服务器端，ACTION可能是指向一个HTTP地址，借助CGI来完成表单的处理程序。在
这种情况下，CGI程序将会注意到内容类型是multipart/form-data，并采取措施来处理不同
的字段（校验合法性，按照处理顺序将文件写入磁盘等等）

3.4其他属性的解释

<INPUT TYPE=file>标记可以有一个VALUE属性来指定默认的文件名。这有可能会影响到
平台无关性，但也可能非常有用。举例来说在某些有多个提交过程的操作中，可以避免让用
户不停的选择同样的文件名。

可以用“SIZE=宽，高”来指定SIZE属性。宽度默认为文件名的宽度，而高度是所选择的
文件列表的显示区域大小。举例来说，对那些希望在浏览器中实现上传多个文件，并且显示
多行的文件输入框（当然，旁边还有一个Browse按钮）的人来说，这点非常有用。当没有
指定高度值时，将只会显示一个单行的文件输入框（如果表单设计者只希望上传一个文件的
话），而如果高度值大于1的话，将显示带有滚动条的多行输入框（如果表单设计者希望
上传多个文件的话）。

4.向后兼容性的考虑

尽管对于现有的WWW表单机制来说，一个成功的改进方案不一定要考虑这点，但是考虑
一种迁移的策略也是有帮助的：对于那些使用比较老版本的浏览器的用户来说，借助于一个
附加程序，他们也能够进行文件上传。现有的绝大部分浏览器在碰到<INPUT TYPE=FILE>
时，会将它按照<INPUT TYPE=TEXT>对待，并给用户一个文本输入框。用户能在这个框
里面输入文件名。此外，似乎现有的浏览器都忽略了表单元素中的ENCTYPE参数，并按
照application/x-www-form-urlencoded传送表单数据。

这样的话，当服务器端的CGI处理传送回来的表单数据时，如果数据类型是
application/x-www-form-urlencoded，而不是multipart/form-data，就可以知道用户使用的
浏览器没有实现文件上传。

在这种情况下，服务器端的CGI不会返回一个“text/html”响应，而是返回一个数据流以
便附加程序能够处理；这个数据流可能被标识为"application/x-please-send-files"，并包含
以下内容：

?	表单数据实际需要被传送至的（标准）URL地址（以CRLF结尾）
?	应该包含文件内容的字段名字列表（用空格间隔开，以CRLF结尾）
?	客户端传至服务器端的application/x-www-form-urlencoded表单数据

这时候，浏览器需要被设置以便能启动一个附加程序来处理application/x-please-send-files
请求。

附加程序能够处理表单数据，并且注意到那些包含有“本地文件名”、需要用实际的文件内
容替代的字段。它可能会需要提示用户来改变或增加文件列表，然后重新将数据和文件内容
打包成multipart/form-data，并再次传回给服务器。

附加程序能够象那些新版本的浏览器实际处理数据那样处理表单，并按照原始的ACTION
指定的URL地址将数据发送。这样处理的好处是服务器端可以使用“同样的”CGI来处理
老版本及新版本的浏览器。

附加程序不需要显示表单数据，但是“需要”确保用户能够得知传送的文件是恰当的。（这
是为了避免那些不怀好意的服务器要求传送用户本来没有要求传送的文件而可能带来的安
全问题。）如果能够显示当前正在传送的文件状态，将非常有帮助。

5.其他的考虑

5.1压缩，加密

本方案并没有考虑可能存在的文件压缩。经过一定的考虑，我们发现如果要让浏览器自己来
决定那些文件需要被压缩的话，对文件压缩进行优化的讨论将变得非常复杂。许多连接层的
传输协议（比如说高速调制解调器）在连接层对数据进行压缩，如果在这一层上对压缩进行
优化可能不是非常恰当。如果确实希望如此的话，可以让浏览器选择是否对文件内容进行
content-transfer-encoding的x-compress压缩，并且在服务器端处理数据前进行数据解压
缩。但这将不在该方案中进行讨论。

同样，本方案也没有包括对数据进行加密的机制。这应该由其他的数据保密传输协议进行处
理，或者是保密HTTP（HTTPs），或者是电子邮件。

5.2文件传输延迟

在某些情况下，在确实准备接受数据前，服务器先对表单数据中的某些元素（比如说用户名，
账号等）进行验证是推荐的做法。但是，经过一定的考虑后，我们认为如果服务器想这样做
的话，最好是采用一系列的表单，并将前面所验证过的数据元素作为“隐藏”字段传回给客
户端，或者是通过安排表单使那些需要验证的元素先显示出来。这样的话，那些需要做复杂
的应用的服务器可以自己维持事务处理的状态，而那些简单的应用的则可以实现得简单些。

HTTP协议可能需要知道整个事务处理中的内容总长度。即使没有明确要求，HTTP客户端
也应该提供上传的所有文件的内容总长度，这样一个繁忙的服务器就能够判断文件的内容是