RFC1867 HTML中基于表單的文件上傳

1、 組織：中國互動出版網(wǎng)（/）RFC 文檔中文翻譯計劃（/compters/emook/aboutemook.htm）E-mail：ouyang譯者：黃?。╤ujiao hj_chinese ）譯文發(fā)布時間：2001-4-26版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有?？梢杂糜诜巧虡I(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及版權(quán)信息。Network Working GroupRequest For Comments: 1867Category: ExperimentalE. NebelL. MasinterXerox CorporationNovember 1995HTML 中基于表單的文件上傳(

2、RFC1867 Form-based File Upload in HTML)本備忘錄的狀態(tài)本備忘錄描述了一種 Internet 社區(qū)的試驗協(xié)議。本備忘錄并未規(guī)定任何 Internet 標準，它需要進一步進行討論和建議以得到改進。本備忘錄的發(fā)布不受限制。目錄1摘要 22帶有文件提交功能的 HTML 表單 23建議采納的應用 33.1 FILE 組件的顯示 43.2 提交之后的動作 43.3 multipart/form-data 的使用 43.4 其他屬性的解釋 54.向后兼容性的考慮 55.其他的考慮 65.1 壓縮，加密 65.2 文件傳輸延遲 65.3 傳輸二進制數(shù)據(jù)的其他解決辦法 75

3、.4 不修改 75.5 字段內(nèi)容的默認類型 85.6 允許 ACTION 指向mailto: 85.7 第三方傳輸?shù)倪h程文件 85.8 用 ENCTYPE=x-www-form-urlencoded 來傳輸文件 85.9 將 CRLF 作為行分隔符 85.10 和 multipart/related 的關(guān)系 95.11 含有非 ASCII 碼的字段名 96.例子 9 7. multipart/form-data 的登記 108.安全性考慮 119.結(jié)論 11作者地址： 12A.為 multipart/form-data 登記的媒體類型 12參考： 131摘要目前，HTML 的表單讓表單編寫者能

4、夠通過表單得到瀏覽表單的用戶的信息。在許多需要得到用戶輸入的應用中，表單被證明是非常有用的。但是，因為 HTML 表單并沒有提供讓用戶可以上傳文件或數(shù)據(jù)的途徑，這種能力受到了一定的限制。所以那些需要從用戶那兒得到文件的服務(wù)提供商們不得不自己來建立相應的應用程序。（我們可以在 www-talk 郵件列表中找到這類客戶瀏覽器的例子。）既然文件上傳是能夠讓許多應用程序受益的特點，這使得人們要求擴展 HTML，以便能讓信息提供商們能夠統(tǒng)一地處理文件上傳請求，并為文件上傳響應提供統(tǒng)一的 MIME 兼容的表現(xiàn)形式。本方案同時也包括了一個向后保持兼容的策略介紹，以便能讓新的服務(wù)器能和現(xiàn)有的 HTML 客戶端

5、進行互動。本建議獨立于現(xiàn)有的各版本 HTML。2帶有文件提交功能的 HTML 表單現(xiàn)有的 HTML 規(guī)范為 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 屬性，該屬性

6、能夠指定可被上傳的文件類型或文件格式列表。另外，本建議還定義了一種新的 MIME 類型：multipart/form-data，以及當處理一個帶有ENCTYPE=multipart/form-data 并且/或含有的標記的表單時所應該采取的行為。這些改變可以被視為是完全獨立的，但對于合理的文件上傳需求來說，這些改變都是必需的。舉例來說，當 HTML 表單作者想讓用戶能夠上傳一個或更多的文件時，他可以這么寫： File to process: HTML DTD 里所需要做出的改動是為 InputType 實體增加一個選項。此外，我們也建議用一系列用逗號分隔的文件類型來作為 INPUT 標記的 A

7、CCEPT 屬性。. (其他元素) . (其他元素) .3建議采納的應用因為用戶端有多種途徑來選擇最合適的方式來解釋 HTML 內(nèi)容，本節(jié)針對其中的一種：WWW 瀏覽器來建議如何實現(xiàn)文件上傳。3.1 FILE 組件的顯示當瀏覽器遇到一個 FILE 類型的 INPUT 標記時，它將顯示一個文件名（或者是前面所選擇的文件名），和一個 Browse（瀏覽）按鈕或類似的選擇方式。選擇這個 Browse（瀏覽）按鈕將觸發(fā)瀏覽器對應于其所運行的平臺相應的文件選擇方式。舉例來說，基于 Windows的瀏覽器將會彈出一個文件選擇窗口。在這個文件選擇窗口中，用戶可以進行替換現(xiàn)有的選擇，為選擇增加一個新的文件等操

8、作。瀏覽器的設(shè)計者可以自己確定所選擇的文件名列表是否可以被用戶手工修改。 如果該標記有 ACCEPT 屬性，瀏覽器還可以限制符合該平臺的文件類型。3.2 提交之后的動作當用戶填完了表單，并且選擇了 SUBMIT 元素，瀏覽器應該將表單的內(nèi)容和所選擇的文件的內(nèi)容傳回。對于傳送那些大容量的二進制數(shù)據(jù)或包含非 ASCII 字符的文本來說，application/x-www-form-urlencoded 編碼類型是遠遠不能滿足要求的。于是，我們提出了一種新的媒體類型：multipart/form-data，用來作為將填寫好的表單內(nèi)容從客戶端傳回到主機端的高效方式。3.3 multipart/form

9、-data 的使用第 7 節(jié)里面對 multipart/form-data 做出了具體的定義。最極端的情況是選擇中不包括任何數(shù)據(jù)。（這種選擇在某些情況下是非常可能的。）作為數(shù)據(jù)流的一部分，表單中的每一項內(nèi)容都按照它們在表單中出現(xiàn)的順序被依次發(fā)送。每一部分由它們在 HTML 表單中 INPUT 標記的名字所標識。如果該部分內(nèi)容的類型是已知的，就用相應的媒體內(nèi)容進行標識（舉例來說，可以從文件的擴展名或者從操作系統(tǒng)的相關(guān)類型信息中得知），否則的話，就標識為application/octet-stream。如果有多個文件被選中上傳，它們必須按照 multipart/mixed 格式進行傳輸。雖然 HT

10、TP 協(xié)議能夠傳送任意形式的二進制數(shù)據(jù)，郵件傳送（舉例來說，如果表單的 ACTION是 mailto 的形式）的默認方式是 7 位編碼。但是如果傳送的內(nèi)容和默認的編碼方式不兼容的話，所傳送的內(nèi)容將需要進行編碼，并且加上一個content-transfer-encoding標識頭。（此方面詳細內(nèi)容可參看 RFC 1521 第 5 節(jié)）。上傳文件的原始文件名也應該一道被傳送，或者是作為 filename 參數(shù)，或者是content-disposition: form-data的標題頭，如果傳送的是多個文件的話，也可以是子內(nèi)容中的content-disposition:file的標題頭?？蛻舳藨贸?/p>

11、序應該盡量提供文件名。如果客戶端操作系統(tǒng)上的文件名包含有非 US-ASCII 字符，文件名可以用類似的字符或者是按照 RFC1522中描述的方法進行編碼。這在某些情況下有其便利之處，比如說上傳的文件中可能包含互相關(guān)聯(lián)的關(guān)系，例如一個 TeX 文件可能會有一個后綴為.sty 的附加類型描述文件。在服務(wù)器端，ACTION 可能是指向一個 HTTP 地址，借助 CGI 來完成表單的處理程序。在這種情況下，CGI 程序?qū)⒁獾絻?nèi)容類型是 multipart/form-data，并采取措施來處理不同的字段（校驗合法性，按照處理順序?qū)⑽募懭氪疟P等等）3.4 其他屬性的解釋標記可以有一個 VALUE 屬

12、性來指定默認的文件名。這有可能會影響到平臺無關(guān)性，但也可能非常有用。舉例來說在某些有多個提交過程的操作中，可以避免讓用戶不停的選擇同樣的文件名?？梢杂谩癝IZE=寬，高”來指定 SIZE 屬性。寬度默認為文件名的寬度，而高度是所選擇的 文件列表的顯示區(qū)域大小。舉例來說，對那些希望在瀏覽器中實現(xiàn)上傳多個文件，并且顯示多行的文件輸入框（當然，旁邊還有一個 Browse 按鈕）的人來說，這點非常有用。當沒有指定高度值時，將只會顯示一個單行的文件輸入框（如果表單設(shè)計者只希望上傳一個文件的話），而如果高度值大于 1 的話，將顯示帶有滾動條的多行輸入框（如果表單設(shè)計者希望上傳多個文件的話）。4.向后兼容性

13、的考慮盡管對于現(xiàn)有的 WWW 表單機制來說，一個成功的改進方案不一定要考慮這點，但是考慮一種遷移的策略也是有幫助的：對于那些使用比較老版本的瀏覽器的用戶來說，借助于一個附加程序，他們也能夠進行文件上傳?，F(xiàn)有的絕大部分瀏覽器在碰到時，會將它按照對待，并給用戶一個文本輸入框。用戶能在這個框里面輸入文件名。此外，似乎現(xiàn)有的瀏覽器都忽略了表單元素中的 ENCTYPE 參數(shù)，并按照 application/x-www-form-urlencoded 傳送表單數(shù)據(jù)。這樣的話，當服務(wù)器端的 CGI 處理傳送回來的表單數(shù)據(jù)時，如果數(shù)據(jù)類型是application/x-www-form-urlencoded，而

14、不是 multipart/form-data，就可以知道用戶使用的瀏覽器沒有實現(xiàn)文件上傳。在這種情況下，服務(wù)器端的 CGI 不會返回一個“text/html”響應，而是返回一個數(shù)據(jù)流以便附加程序能夠處理；這個數(shù)據(jù)流可能被標識為application/x-please-send-files，并包含以下內(nèi)容：?表單數(shù)據(jù)實際需要被傳送至的（標準）URL 地址（以 CRLF 結(jié)尾）應該包含文件內(nèi)容的字段名字列表（用空格間隔開，以 CRLF 結(jié)尾）客戶端傳至服務(wù)器端的 application/x-www-form-urlencoded 表單數(shù)據(jù)這時候，瀏覽器需要被設(shè)置以便能啟動一個附加程序來處理 app

15、lication/x-please-send-files請求。附加程序能夠處理表單數(shù)據(jù)，并且注意到那些包含有“本地文件名”、需要用實際的文件內(nèi)容替代的字段。它可能會需要提示用戶來改變或增加文件列表，然后重新將數(shù)據(jù)和文件內(nèi)容打包成 multipart/form-data，并再次傳回給服務(wù)器。附加程序能夠象那些新版本的瀏覽器實際處理數(shù)據(jù)那樣處理表單，并按照原始的 ACTION指定的 URL 地址將數(shù)據(jù)發(fā)送。這樣處理的好處是服務(wù)器端可以使用“同樣的”CGI 來處理老版本及新版本的瀏覽器。附加程序不需要顯示表單數(shù)據(jù)，但是“需要”確保用戶能夠得知傳送的文件是恰當?shù)摹＃ㄟ@是為了避免那些不懷好意的服務(wù)器要求

16、傳送用戶本來沒有要求傳送的文件而可能帶來的安全問題。）如果能夠顯示當前正在傳送的文件狀態(tài)，將非常有幫助。5.其他的考慮 5.1 壓縮，加密本方案并沒有考慮可能存在的文件壓縮。經(jīng)過一定的考慮，我們發(fā)現(xiàn)如果要讓瀏覽器自己來決定那些文件需要被壓縮的話，對文件壓縮進行優(yōu)化的討論將變得非常復雜。許多連接層的傳輸協(xié)議（比如說高速調(diào)制解調(diào)器）在連接層對數(shù)據(jù)進行壓縮，如果在這一層上對壓縮進行優(yōu)化可能不是非常恰當。如果確實希望如此的話，可以讓瀏覽器選擇是否對文件內(nèi)容進行content-transfer-encoding 的 x-compress 壓縮，并且在服務(wù)器端處理數(shù)據(jù)前進行數(shù)據(jù)解壓縮。但這將不在該方案中進

17、行討論。同樣，本方案也沒有包括對數(shù)據(jù)進行加密的機制。這應該由其他的數(shù)據(jù)保密傳輸協(xié)議進行處理，或者是保密 HTTP（HTTPs），或者是電子郵件。5.2 文件傳輸延遲在某些情況下，在確實準備接受數(shù)據(jù)前，服務(wù)器先對表單數(shù)據(jù)中的某些元素（比如說用戶名，賬號等）進行驗證是推薦的做法。但是，經(jīng)過一定的考慮后，我們認為如果服務(wù)器想這樣做的話，最好是采用一系列的表單，并將前面所驗證過的數(shù)據(jù)元素作為“隱藏”字段傳回給客戶端，或者是通過安排表單使那些需要驗證的元素先顯示出來。這樣的話，那些需要做復雜的應用的服務(wù)器可以自己維持事務(wù)處理的狀態(tài)，而那些簡單的應用的則可以實現(xiàn)得簡單些。HTTP 協(xié)議可能需要知道整個事務(wù)

18、處理中的內(nèi)容總長度。即使沒有明確要求，HTTP 客戶端也應該提供上傳的所有文件的內(nèi)容總長度，這樣一個繁忙的服務(wù)器就能夠判斷文件的內(nèi)容是否是過大以至于將不能完整地處理，從而返回一個錯誤代碼并關(guān)閉該連接，而不用等到接受了所有的數(shù)據(jù)才進行判斷。目前一些現(xiàn)有的 CGI 應用對所有的 POST 事務(wù)都需要知道內(nèi)容總長度。如果 INPUT 標記含有一個 MAXLENGTH 屬性，客戶端可以將這個屬性值看作是服務(wù)器端所能夠接受的傳送文件的最大字節(jié)數(shù)。在這種情況下，服務(wù)器能夠在上傳開始前，提示客戶端在服務(wù)器上有多少空間可以用來進行文件上傳。但是應該引起注意的是，這僅僅是一個提示，在表單被創(chuàng)建后和文件上傳前，服

19、務(wù)器的實際需求可能會發(fā)生改變。在任何情況下，如果接受的文件過大的話，任何一個 HTTP 服務(wù)器都有可能在文件傳輸?shù)倪^程中中斷傳輸。5.3 傳輸二進制數(shù)據(jù)的其他解決辦法有些人曾經(jīng)建議使用一種新的 MIME 類型aggregate，比如說 aggregate/mixed 或是content-transfer-encoding 包來描述那些不確定長度的二進制數(shù)據(jù)，而不是靠分解為多個部分來表示。雖然我們并不反對這么做，但這需要增加額外的設(shè)計和標準化工作來讓大家接受并理解aggregate。 從另一方面來說，分解為多部分的機制工作得很好，能夠非常簡單的在客戶發(fā)送端和服務(wù)器接受端加以實現(xiàn)，而且能像其他一些

20、綜合處理二進制數(shù)據(jù)的方式一樣高效率地工作。5.4 不修改 有些人曾經(jīng)提到過，為什么要修改 INPUT 來實現(xiàn)文件上傳功能，而不是為表單元素提供一個完全不同的類型？在這種種考慮中，當我們使用時，最重要的考慮是兼容策略。事實上，標記早就已經(jīng)被修改過以用來包含各種輸入的數(shù)據(jù)，相比較于創(chuàng)造不同種類的標記，對進行加強看起來是更為合理的辦法。INPUT 的“類型”并不是它所返回的內(nèi)容類型，而更象是“多類型”的，也就是說，它表示了和用戶互動的方式。它的定義被仔細地斟酌以便其既能在文本瀏覽器，也能在聲音標記中使用。5.5 字段內(nèi)容的默認類型HTML 中許多字段都需要用戶進行輸入。過去人們對這些表單數(shù)據(jù)應該如何

21、傳回到服務(wù)器有些意見分歧。但是將這些 INPUT 字段的內(nèi)容看成是純文本很明顯將有助于消除這方面的分歧?？蛻舳嗽賹⑦@些數(shù)據(jù)傳回到服務(wù)器以前應該將它們用 CRLF 分隔開，并進行適當?shù)木幋a。5.6 允許 ACTION 指向mailto:雖然和本方案無關(guān)，但是如果允許客戶端的表單的 ACTION 指向一個mailto:地址將肯定非常有用。不管本方案本身怎么設(shè)想，這都是一個好主意。同樣的，那些用來接受郵件的表單的 ACTION 也應該默認指向reply-to:。這兩個設(shè)想有助于讓 HTML 表單借助于 HTTP 服務(wù)器工作，但通過電子郵件發(fā)送內(nèi)容?；蛘咭部梢赃@么做：允許 HTML 表單能夠被電子郵件

22、發(fā)送，當 HTML 中指明的郵件收件人填寫完表單后，再將結(jié)果發(fā)送作為郵件傳送回來。5.7 第三方傳輸?shù)倪h程文件在某些情況下，那些操作客戶端軟件的用戶可能希望通過指定一個 URL 地址來傳送位于網(wǎng)上，而不是本地的數(shù)據(jù)文件。在這種情況下，瀏覽器能夠發(fā)送給客戶一個指向遠程數(shù)據(jù)的連接，而不是實際的所有內(nèi)容嗎？這種要求實際上是可以辦得到的，舉例來說，只要讓客戶在發(fā)送給服務(wù)器的數(shù)據(jù)當中，用message/external-body來指明數(shù)據(jù)的類型，同時將access-type設(shè)置為連接的地址，并在發(fā)送的內(nèi)容中包含遠程數(shù)據(jù)的 URL 地址就可以了。5.8 用 ENCTYPE=x-www-form-urlen

23、coded 來傳輸文件如果一個表單包含了元素，但是表單本身未包含 ENCTYPE 屬性，也就是沒有詳細說明相應的行為的話。這將可能導致為服務(wù)器進行不恰當?shù)膶Υ罅繑?shù)據(jù)進行URN 編碼，而這將是服務(wù)器端所不希望看到的5.9 將 CRLF 作為行分隔符象所有的 MIME 傳輸一樣，在用 POST 方式傳送表單內(nèi)容的時候，CRLF 都被用作行的分隔符。5.10 和 multipart/related 的關(guān)系MIMESGML 小組正在考慮制訂一種新的類型，稱為 multipart/related。它包含和 multipart/form-data 類似的特點。Form-data 的使用和應用卻是完全不同的

24、，所以它被單獨進行描述。在某些情況下，有可能將 HTML 表單的內(nèi)容（包括文件）作為 multipart/related 進行編碼，但這和本方案所討論的情況有很大的不同。5.11 含有非 ASCII 碼的字段名需要注意的是 MIME 的標題頭通常是由 7 位的 US-ASCII 字符集構(gòu)成。所以如果字段名的字符不屬于該字符集的話，就必須按照 RFC 1522 里面所提到的方法進行編碼。在 HTML 2.0里面，默認的字符集是 ISO-8859-1，而由非 ASCII 碼字符組成的字段名就必須進行編碼。6.例子假設(shè)服務(wù)器段提供的是如下的 HTML：What is your name? What

25、files are you sending? 用戶在“姓名”字段里面填寫Joe Blow，對問題What files are you sending?，用戶選擇了一個文本文件file1.txt?？蛻舳慰赡馨l(fā)送回如下的數(shù)據(jù)：Content-type:-AaB03xmultipart/form-data, boundary=AaB03xcontent-disposition: form-data; name=field1Joe Blow-AaB03xcontent-disposition:Content-Type:form-data; name=pics; filename=file1.txtte

26、xt/plain. file1.txt 的內(nèi)容.-AaB03x-如果用戶同時還選擇了另一個圖片文件file2.gif，那么客戶端可能發(fā)送的數(shù)據(jù)將是：Content-type: multipart/form-data, boundary=AaB03x -AaB03xcontent-disposition: form-data; name=field1Joe Blow-AaB03xcontent-disposition:form-data; name=picsContent-type:multipart/mixed, boundary=BbC04y-BbC04yContent-dispositio

27、n:attachment; filename=file1.txttext/plainContent-Type:.file1.txt 的內(nèi)容.-BbC04yContent-disposition:Content-type: image/gifattachment; filename=file2.gifContent-Transfer-Encoding:binary. file2.gif 的內(nèi)容.-BbC04y-AaB03x-7. multipart/form-data 的登記multipart/form-data 的媒體內(nèi)容遵從 RFC 1521 所規(guī)定的多部分的數(shù)據(jù)流規(guī)則。它主要被用來描述表單

28、填寫后返回的數(shù)據(jù)。在一個表單中（這里指的是 HTML，當然其他一些應用也可能使用表單），有一系列字段提供給用戶進行填寫，每個字段都有自己的名字。在一個確定的表單中，每個名字都是唯一的。multipart/form-data 由多個部分組成，每一部分都有一個 content-disposition 標題頭，它的值是form-data，它的屬性指明了其在表單內(nèi)的字段名。舉例來說，content-disposition:form-data; name=xxxxx，這里的 xxxxx 就是對應于該字段的字段名。如果字段名包含非ASCII 碼字符的話，還應該按照 RFC 1522 里面所規(guī)定的方法進行編

29、碼。對所有的多部分 MIME 類型來說，每一部分有一個可選的 Content-Type，默認的值是text/plain。如果文件的內(nèi)容是通過表單填寫上傳返回的話，那么輸入的文件就被定義為application/octet-stream，或者，如果知道是什么類型的話，就定義為相應的媒體類型。如果一個表單返回多個文件，那么它們就作為 multipart/form-data 中所結(jié)合的 multipart/mixed被返回。如果所傳送的內(nèi)容不符合默認的編碼方式的話，該部分都將被編碼，并加上content-transfer-encoding的標題頭。 上傳的文件也可能被指定文件名，文件名可以由標題頭content-disposition中的 filename參數(shù)所指定。雖然這并不是必需的，但我們強烈建議在能夠得知原始文件名的情況下這么做。對于很多應用程序來說，這都是必需的或者是有用的。8.安全性考慮如果用戶沒有明確要求發(fā)送某個文件，用戶端就不應該發(fā)送該文件，這點非常重要。所以，在碰到的標記的時候，HTML 解釋器應該能夠讓用戶確認默認的文件名。不要使用隱含的字段來指定任何文件。本方案并沒有包括對數(shù)據(jù)加密的討論；這應該是保密數(shù)據(jù)傳輸協(xié)議，或者是加密HTTP，或者是 MOSS 所提供的加密協(xié)議（在 RFC 1848 中