組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：黃俊（hujiao  hj_chinese@yahoo.com）
譯文發布時間：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客戶端
也應該提供上傳的所有文件的內容總長度，這樣一個繁忙的服務器就能夠判斷文件的內容是