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

1、 組織：中國互動(dòng)出版網(wǎng)（/）RFC 文檔中文翻譯計(jì)劃（/compters/emook/aboutemook.htm）E-mail：ouyang譯者：黃?。╤ujiao hj_chinese ）譯文發(fā)布時(shí)間：2001-4-26版權(quán)：本中文翻譯文檔版權(quán)歸中國互動(dòng)出版網(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ū)的試驗(yàn)協(xié)議。本備忘錄并未規(guī)定任何 Internet 標(biāo)準(zhǔn)，它需要進(jìn)一步進(jìn)行討論和建議以得到改進(jìn)。本備忘錄的發(fā)布不受限制。目錄1摘要 22帶有文件提交功能的 HTML 表單 23建議采納的應(yīng)用 33.1 FILE 組件的顯示 43.2 提交之后的動(dòng)作 43.3 multipart/form-data 的使用 43.4 其他屬性的解釋 54.向后兼容性的考慮 55.其他的考慮 65.1 壓縮，加密 65.2 文件傳輸延遲 65.3 傳輸二進(jìn)制數(shù)據(jù)的其他解決辦法 75

3、.4 不修改 75.5 字段內(nèi)容的默認(rèn)類型 85.6 允許 ACTION 指向mailto: 85.7 第三方傳輸?shù)倪h(yuǎn)程文件 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、夠通過表單得到瀏覽表單的用戶的信息。在許多需要得到用戶輸入的應(yīng)用中，表單被證明是非常有用的。但是，因?yàn)?HTML 表單并沒有提供讓用戶可以上傳文件或數(shù)據(jù)的途徑，這種能力受到了一定的限制。所以那些需要從用戶那兒得到文件的服務(wù)提供商們不得不自己來建立相應(yīng)的應(yīng)用程序。（我們可以在 www-talk 郵件列表中找到這類客戶瀏覽器的例子。）既然文件上傳是能夠讓許多應(yīng)用程序受益的特點(diǎn)，這使得人們要求擴(kuò)展 HTML，以便能讓信息提供商們能夠統(tǒng)一地處理文件上傳請求，并為文件上傳響應(yīng)提供統(tǒng)一的 MIME 兼容的表現(xiàn)形式。本方案同時(shí)也包括了一個(gè)向后保持兼容的策略介紹，以便能讓新的服務(wù)器能和現(xiàn)有的 HTML 客戶端

5、進(jìn)行互動(dòng)。本建議獨(dú)立于現(xiàn)有的各版本 HTML。2帶有文件提交功能的 HTML 表單現(xiàn)有的 HTML 規(guī)范為 INPUT 元素的 TYPE 屬性定義了八種可能的值，分別是：CHECKBOX,HIDDEN, IMAGE, PASSWORD, RADIO, RESET, SUBMIT, TEXT. 另外，當(dāng)表單采用POST 方式的時(shí)候，表單默認(rèn)的具有application/x-www-form-urlencoded 的 ENCTYPE屬性。本建議對 HTML 做出了兩處修改：1）為 INPUT 元素的 TYPE 屬性增加了一個(gè) FILE 選項(xiàng)。2）INPUT 標(biāo)記可以具有 ACCEPT 屬性，該屬性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25、files are you sending? 用戶在“姓名”字段里面填寫Joe Blow，對問題What files are you sending?，用戶選擇了一個(gè)文本文件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-如果用戶同時(shí)還選擇了另一個(gè)圖片文件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ù)。在一個(gè)表單中（這里指的是 HTML，當(dāng)然其他一些應(yīng)用也可能使用表單），有一系列字段提供給用戶進(jìn)行填寫，每個(gè)字段都有自己的名字。在一個(gè)確定的表單中，每個(gè)名字都是唯一的。multipart/form-data 由多個(gè)部分組成，每一部分都有一個(gè) content-disposition 標(biāo)題頭，它的值是form-data，它的屬性指明了其在表單內(nèi)的字段名。舉例來說，content-disposition:form-data; name=xxxxx，這里的 xxxxx 就是對應(yīng)于該字段的字段名。如果字段名包含非ASCII 碼字符的話，還應(yīng)該按照 RFC 1522 里面所規(guī)定的方法進(jìn)行編

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