否是過大以至于將不能完整地處理，從而返回一個錯誤代碼并關閉該連接，而不用等到接受
了所有的數據才進行判斷。目前一些現有的CGI應用對所有的POST事務都需要知道內容
總長度。

如果INPUT標記含有一個MAXLENGTH屬性，客戶端可以將這個屬性值看作是服務器端
所能夠接受的傳送文件的最大字節數。在這種情況下，服務器能夠在上傳開始前，提示客戶
端在服務器上有多少空間可以用來進行文件上傳。但是應該引起注意的是，這僅僅是一個提
示，在表單被創建后和文件上傳前，服務器的實際需求可能會發生改變。

在任何情況下，如果接受的文件過大的話，任何一個HTTP服務器都有可能在文件傳輸的
過程中中斷傳輸。

5.3傳輸二進制數據的其他解決辦法

有些人曾經建議使用一種新的MIME類型"aggregate"，比如說aggregate/mixed 或是
content-transfer-encoding "包"來描述那些不確定長度的二進制數據，而不是靠分解為多個
部分來表示。雖然我們并不反對這么做，但這需要增加額外的設計和標準化工作來讓大家接
受并理解"aggregate"。 從另一方面來說，"分解為多部分"的機制工作得很好，能夠非常簡
單的在客戶發送端和服務器接受端加以實現，而且能像其他一些綜合處理二進制數據的方式
一樣高效率地工作。

5.4 不修改<INPUT>

有些人曾經提到過，為什么要修改INPUT來實現文件上傳功能，而不是為表單元素提供一
個完全不同的類型？在這種種考慮中，當我們使用<INPUT>時，最重要的考慮是兼容策略。
事實上，<INPUT>標記"早就已經"被修改過以用來包含各種輸入的數據，相比較于創造不同
種類的<INPUT>標記，對<INPUT>進行加強看起來是更為合理的辦法。INPUT的“類型”
并不是它所返回的內容類型，而更象是“多類型”的，也就是說，它表示了和用戶互動的方
式。它的定義被仔細地斟酌以便其既能在文本瀏覽器，也能在聲音標記中使用。

5.5字段內容的默認類型

HTML中許多字段都需要用戶進行輸入。過去人們對這些表單數據應該如何傳回到服務器有
些意見分歧。但是將這些INPUT字段的內容看成是純文本很明顯將有助于消除這方面的分
歧。客戶端再將這些數據傳回到服務器以前應該將它們用CRLF分隔開，并進行適當的編
碼。

5.6允許ACTION指向"mailto:"

雖然和本方案無關，但是如果允許客戶端的表單的ACTION指向一個"mailto:"地址將肯定非
常有用。不管本方案本身怎么設想，這都是一個好主意。同樣的，那些用來接受郵件的表單
的ACTION也應該默認指向"reply-to:"。這兩個設想有助于讓HTML表單借助于HTTP服務
器工作，但通過電子郵件發送內容。或者也可以這么做：允許HTML表單能夠被電子郵件
發送，當HTML中指明的郵件收件人填寫完表單后，再將結果發送作為郵件傳送回來。

5.7第三方傳輸的遠程文件
在某些情況下，那些操作客戶端軟件的用戶可能希望通過指定一個URL地址來傳送位于網
上，而不是本地的數據文件。在這種情況下，瀏覽器能夠發送給客戶一個指向遠程數據的連
接，而不是實際的所有內容嗎？這種要求實際上是可以辦得到的，舉例來說，只要讓客戶在
發送給服務器的數據當中，用"message/external-body"來指明數據的類型，同時將
"access-type"設置為連接的地址，并在發送的內容中包含遠程數據的URL地址就可以了。

5.8用ENCTYPE=x-www-form-urlencoded來傳輸文件

如果一個表單包含了<INPUT TYPE=file>元素，但是表單本身未包含ENCTYPE屬性，也
就是沒有詳細說明相應的行為的話。這將可能導致為服務器進行不恰當的對大量數據進行
URN編碼，而這將是服務器端所不希望看到的

5.9將CRLF作為行分隔符

象所有的MIME傳輸一樣，在用POST方式傳送表單內容的時候，CRLF都被用作行的分
隔符。

5.10和multipart/related的關系
MIMESGML小組正在考慮制訂一種新的類型，稱為multipart/related。它包含和
multipart/form-data類似的特點。Form-data的使用和應用卻是完全不同的，所以它被單獨
進行描述。

在某些情況下，有可能將HTML表單的內容（包括文件）作為multipart/related進行編碼，
但這和本方案所討論的情況有很大的不同。

5.11含有非ASCII碼的字段名

需要注意的是MIME的標題頭通常是由7位的US-ASCII字符集構成。所以如果字段名的字
符不屬于該字符集的話，就必須按照RFC 1522里面所提到的方法進行編碼。在HTML 2.0
里面，默認的字符集是ISO-8859-1，而由非ASCII碼字符組成的字段名就必須進行編碼。

6.例子

假設服務器段提供的是如下的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--

7. multipart/form-data的登記
multipart/form-data的媒體內容遵從RFC 1521所規定的多部分的數據流規則。它主要被用
來描述表單填寫后返回的數據。在一個表單中（這里指的是HTML，當然其他一些應用也可
能使用表單），有一系列字段提供給用戶進行填寫，每個字段都有自己的名字。在一個確定
的表單中，每個名字都是唯一的。

multipart/form-data由多個部分組成，每一部分都有一個content-disposition標題頭，它的
值是"form-data"，它的屬性指明了其在表單內的字段名。舉例來說，'content-disposition: 
form-data; name="xxxxx"'，這里的xxxxx就是對應于該字段的字段名。如果字段名包含非
ASCII碼字符的話，還應該按照RFC 1522里面所規定的方法進行編碼。

對所有的多部分MIME類型來說，每一部分有一個可選的Content-Type，默認的值是
text/plain。如果文件的內容是通過表單填寫上傳返回的話，那么輸入的文件就被定義為
application/octet-stream，或者，如果知道是什么類型的話，就定義為相應的媒體類型。如
果一個表單返回多個文件，那么它們就作為multipart/form-data中所結合的multipart/mixed
被返回。

如果所傳送的內容不符合默認的編碼方式的話，該部分都將被編碼，并加上
"content-transfer-encoding"的標題頭。

上傳的文件也可能被指定文件名，文件名可以由標題頭"content-disposition"中的filename
參數所指定。雖然這并不是必需的，但我們強烈建議在能夠得知原始文件名的情況下這么做。
對于很多應用程序來說，這都是必需的或者是有用的。

8.安全性考慮

如果用戶沒有明確要求發送某個文件，用戶端就不應該發送該文件，這點非常重要。所以，
在碰到<INPUT TYPE=file VALUE="yyyy">的標記的時候，HTML解釋器應該能夠讓用戶確
認默認的文件名。不要使用隱含的字段來指定任何文件。

本方案并沒有包括對數據加密的討論；這應該是保密數據傳輸協議，或者是加密HTTP，或
者是MOSS所提供的加密協議（在RFC 1848中有具體的描述）所討論的問題。

一旦文件上傳成功，就將取決于文件接受方來處理文件或者是儲存在適當的地方。

9.結論

我們所建議的應用讓客戶端有很大的彈性來決定它發送到服務器的文件的類型和數量，也讓
服務器端有權決定是否接受上傳的文件，同時也讓服務器有機會和那些不支持類型為file的
INPUT的瀏覽器進行互動。

對HTML DTD的改動雖然很簡單，但卻有很大的作用。能夠讓目前這種缺少文件上傳機制
的萬維網實現很多種服務。這將給萬維網實際的性能增加許多驚人的價值。

作者地址：

   Larry Masinter
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   Phone:  (415) 812-4365
   Fax:    (415) 812-4333
   EMail:   masinter@parc.xerox.com

   Ernesto Nebel
   XSoft, Xerox Corporation
   10875 Rancho Bernardo Road, Suite 200
   San Diego, CA 92127-2116

   Phone:  (619) 676-7817
   Fax:    (619) 676-7865
   EMail:   nebel@xsoft.sd.xerox.com

A.為multipart/form-data登記的媒體類型
媒體類型名稱:
 multipart

子類型名稱:
 form-data

必需的參數:
 無

可選參數:
 無

編碼考慮:
和其他類型相比沒有額外的考慮。

發行的規范:
 RFC 1867

安全性考慮

multipart/form-data并未引進新的安全性考慮來針對那些可能存在所附的內容中的問題。

參考：

[RFC 1521] MIME (多用途的網際郵件擴充協議) 第一部分:
	  網上郵件內容格式的確定和規范機制
	  N. Borenstein & N. Freed.
           1993年9月.

[RFC 1522] MIME (多用途的網際郵件擴充協議) 第二部分:
	  非ASCII碼文本的郵件頭擴充
           K. Moore.
           1993年9月.

[RFC 1806] 英特網上的信息通訊和表達
           信息: Content-Disposition標題頭. 
	  R. Troost & S. Dorner, 
	  1995年6月.
RFC 1867 Form-based File Upload in HTML	HTML中基于表單的文件上傳
RFC文檔中文翻譯計劃		1