表單內容類型（Form content types）

表單內容類型（Form content types）

NOTES
本文原文爲： https://www.w3.org/TR/html401...
翻譯由 本人（赤石俊哉） 整理，若您是原做者並認爲此文涉及版權侵犯，我會配合刪除。

在 HTML 標籤中，form 元素的 enctype 屬性指定了用何種方式來編碼提交到服務器的表單主體內容。用戶代理必須支持如下列出的內容類型，可是不關心其餘類型的表現。

也能夠查看這一部分：escaping ampersands in URI attribute values

application/x-www-form-urlencoded

這是默認的內容類型。使用此類型的被提交的表單必須被編碼成以下：

1. 控件名稱和值須要被轉義，空格字符替換爲 +，而後保留的字符根據[RFC1738]的第二部分，非字母數字字符用 %HH 替換。一個百分號和兩位用於表示該字符ASCII碼的十六進制數碼。換行符用 CR LF 對代替，也就是 %0D%0A。

2. 控件名稱和值的對按照他們在文檔中出現的順序進行排列。名稱和值之間用 = 分隔。每一個名稱和值的對之間用 & 分隔。

multipart/form-data

NOTES
請參照[RFC2388]以瞭解更多關於文件上傳的信息，包括逆向兼容性問題，其餘類型和 multipart/form-data 之間的關係，性能問題等等。

安全問題
做者、內嵌的圖片、以及其餘包含 URI 的元素做爲參數可能間接引用用戶輸入。這種狀況就須要注意[RFC1738]，第六部分所描述的安全問題了。最常使用的用於提交表單請求的方法（HTTP和SMTP）是提供一些機密條款。經過表單請求機密信息的信息提供者，尤爲是使用 type=password 的 input 元素的，應當讓用戶意識到保密性的缺失。

表單安全性
一個用戶代理不該該發送任何用戶沒有明確要求被送出的文件。所以，HTML用戶代理應當確承認能在 input 元素中的 value 中被建議的任何默認文件名。隱藏空間中不能指定文件。
這部分不包含數據加密機制，這個應當在其餘的安全傳輸數據機制中。
一旦有文件被上傳了，處理代理就應該進行處理，並保存適當地保存它。

使用內容類型 application/x-www-form-urlencoded 來發送大量二進制數據以及包含非ASCII字符的文本的效率是很是低的。multipart/form-data 這種內容類型就很適合用於提交包含文件、非ASCII數據和二進制數據的表單。

multipart/form-data 遵循全部的在[RFC2045]中所概述的多元 MIME 數據類型流。multipart/form-data 的定義在[IANA]記錄上是可用的。

一個 multipart/form-data 消息包含不少的部分，每個部分都表明了一個成功的控件（成功的控件表示在form元素中定義，而且有name的），這些部分以文檔中出現的順序相同的順序被送處處理代理。部分的邊界都不該該出如今任何數據中。這些是如何運做的超過了本文的描述範圍。

由於須要支持全部的多元的 MIME 類型，因此每一個部分都有一個可選的頭部參數Content-Type被定義爲text/plain。用戶代理能夠提供這個 Content-Type 頭，伴隨一個 charset 參數。

每個部分預計包含：

1. 一個 Content-Disposition 頭，它的值是 form-data。

2. 一個 name 屬性，用來指定和控件相同的名稱的控件名。控件名本該將非 ASCII 字符集使用[RFC2045]中描述的方法進行編碼。

NOTES 譯者注
在火狐以及Chrome中測試的現象，當 name 被指定爲中文名稱的時候，form-data 裏面的 name 也爲中文，沒有被轉碼。

所以，舉個栗子吧，若是有一個空間的名稱名字叫作 "mycontrol"，則對應的部分應該被指定爲：

Content-Disposition: form-data; name="mycontrol"

對於全部的MIME傳遞，"CR LF" (也就是 %0D%0A)用於數據中每行的分割。

每一個部分都要被編碼，並且若是這部分的值不遵循默認編碼(7BIT)，則 Content-Transfer-Encoding 頭部須要被提供。參考[RFC2045] 的第六部分。

若是一個文件的內容也隨着一個表單被提交，那麼文件輸入應該可以以適當的內容類型被識別，好比 application/octet-stream。若是多個文件被一個表單記錄返回，那就應該做爲 multupart/mixed被返回。

用戶代理應當試圖爲每個提交的文件提供文件名。文件名能夠用 Content-Disposition: form-data 頭部中的 filename 屬性來定義。或者，由於是多個文件，能夠用一個子部分 Content-Disposition: file 頭部中指定。若是客戶端的操做系統不是 US-ASCII 編碼的，文件名應當對應或者使用[RFC2045]的方法進行編碼。這對於有一些上傳文件之間存在互相引用的文件的處理比較便利。好比一個 TeX 文件和它的 .sty 輔助樣式描述。

下面一個例子是描繪了一個multipart/form-data編碼示例。假設咱們有這樣的一個表單：

<FORM action="http://server.com/cgi/handle"
       enctype="multipart/form-data"
       method="post">
   <P>
   What is your name? <INPUT type="text" name="submit-name"><BR>
   What files are you sending? <INPUT type="file" name="files"><BR>
   <INPUT type="submit" value="Send"> <INPUT type="reset">
 </FORM>

若是用戶在文本框中輸入 Larry，而後選擇一個文本文件 file1.txt。用戶代理應該傳送這些數據：

Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="submit-name"

   Larry
   --AaB03x
   Content-Disposition: form-data; name="files"; filename="file1.txt"
   Content-Type: text/plain

   ... contents of file1.txt ...
   --AaB03x--

若是用戶選擇了第二個文件 file2.gif，那麼用戶代理應該構建這些部分以下：

Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="submit-name"

   Larry
   --AaB03x
   Content-Disposition: form-data; name="files"
   Content-Type: multipart/mixed; boundary=BbC04y

   --BbC04y
   Content-Disposition: file; filename="file1.txt"
   Content-Type: text/plain

   ... contents of file1.txt ...
   --BbC04y
   Content-Disposition: file; filename="file2.gif"
   Content-Type: image/gif
   Content-Transfer-Encoding: binary

   ...contents of file2.gif ...
   --BbC04y--
   --AaB03x--