如何发送HTML表单数据
多數(shù)時候，HTML表單的目的只是為了把數(shù)據(jù)發(fā)給服務器，之后服務器再處理這些數(shù)據(jù)并發(fā)送響應給用戶。雖然看起來挺簡單的，但我們還是得注意一些事情以確保傳送的數(shù)據(jù)不會破壞服務器、或者給你的用戶制造麻煩。
數(shù)據(jù)會到哪里去
關于客戶端/服務器架構
整個web都是基于一種基本的客戶端/服務器架構，該架構可以歸納如下：
一個客戶端(通常是Web瀏覽器)使用HTTP協(xié)議發(fā)送一個請求給服務器(通常是web服務器程序，譬如Apache, Nginx, IIS, Tomcat等等)，而服務器則以相同的協(xié)議響應這個請求。
在客戶端，HTML表單只是提供一種比較方便且用戶友好的方式，用來配置發(fā)送給服務器的HTTP請求。這樣用戶就可以自己提供能被HTTP請求傳送的信息。
客戶端：定義如何發(fā)送數(shù)據(jù)
<form>元素能夠定義其數(shù)據(jù)如何被發(fā)送，它所有的特性都是為了在用戶點擊發(fā)送按鈕時，讓你配置要發(fā)送的請求。其中最重要的兩個特性是action和method。
action特性
該特性定義了數(shù)據(jù)會被發(fā)往何處，它的值必須是個合法的URL。若該特性未指定，則數(shù)據(jù)會發(fā)送到包含該表單的頁面所在的URL。
示例
在下面的例子中，數(shù)據(jù)會發(fā)送至http://foo.com：
這里，數(shù)據(jù)會被發(fā)送到表單頁所在的服務器，但到達的卻是服務器上不同的URL：
如下，當不指定任何特性時，表單數(shù)據(jù)會給發(fā)送到包含該表單的的頁面：
許多老舊的頁面會使用下面的符號來表明，數(shù)據(jù)得被發(fā)送到包含該表單的的頁面;這在當時是必須的，因為直到HTML5之前，action特性都是必填的。但現(xiàn)在就不再需要了。
注意：可以指定一個使用HTTPS(安全的HTTP)協(xié)議的URL，此時數(shù)據(jù)會隨請求的其他部分一起加密，即使表單本身位于一個通過HTTP訪問的不安全頁面。此外，若表單位于一個安全的頁面，而你卻給action特性指定了一個不安全的HTTP URL，則所有的瀏覽器會在每次用戶要發(fā)送數(shù)據(jù)時給他們一個安全警告，因為此時這些數(shù)據(jù)將不被加密。
method特性
該特性定義了數(shù)據(jù)如何被發(fā)送。HTTP協(xié)議提供了幾種方式來執(zhí)行一個請求;HTML表單數(shù)據(jù)可以通過其中至少方式來發(fā)送：GET和POST。
要理解這兩種方式的不同，我們得回過頭來來看下HTTP是如何工作的。當你想取得Web上的某個資源時，瀏覽器會發(fā)送一個請求給指定的URL。一個HTTP請求含有兩個部分：包含和瀏覽器功能有關的一系列全局字段的請求頭，以及包含要給服務器處理的信息的請求體。
GET方法
瀏覽器使用GET方法來請求服務器發(fā)回指定的資源：“嘿服務器，我想獲得這個資源”。這種情況下，瀏覽器只會發(fā)送一個空的請求體，而正因如此，若瀏覽器使用該方式，那么發(fā)給服務器的數(shù)據(jù)會給追加到URL后面。
示例
考慮如下表單：
使用GET方法時，HTTP請求看起來就這樣：
POST方法
POST方法則稍有不同，瀏覽器發(fā)送這個方法給服務器，用以請求一個和HTTP請求體里數(shù)據(jù)有關的響應：“嘿服務器，看看這些數(shù)據(jù)然后給我發(fā)回一個適當?shù)慕Y果”。若表單使用該方法發(fā)送，則數(shù)據(jù)會給追加到HTTP請求體里。
示例
考慮如下表單(和上面那個一樣)：
使用POST方法時，HTTP請求看起來就這樣：
Content-length頭部字段指示了請求體的大小，而Content-Type字段則標識了發(fā)往服務器的資源類型。我們將在稍后討論下這些請求頭。
當然，HTTP請求是不會展示給用戶看的(若你想看到它們，還得使用諸如火狐的Web Console或者chrome Developer Tools等工具)，唯一展示給用戶的，只有訪問的URL。所以使用GET請求時，用戶將會在他們的地址欄看到數(shù)據(jù)，而使用POST請求則看不到。這點至關重要，原因如下：
服務器端：處理數(shù)據(jù)
不論你選擇哪種HTTP方法，服務器只會接收到一個字符串并將其解析，再以鍵/值對列表的形式獲取數(shù)據(jù)。而如何訪問這個列表，取決于你基于何種開發(fā)平臺、以及用了何種框架。你使用的技術也會決定如何處理重復的鍵名，通常某個鍵名最后接收到的值是優(yōu)先被選取的。
示例：原生PHP
PHP提供了幾個全局對象來處理數(shù)據(jù)。假設你使用POST方法，下面的示例會直接提取你的數(shù)據(jù)并展示給用戶。當然，要如何處理數(shù)據(jù)取決于你，你可以展示它、將其存進數(shù)據(jù)庫、用郵件發(fā)送它、或者其他任何方式。
這個示例會用我們發(fā)送的數(shù)據(jù)生成一個頁面。考慮我們前面用的表單示例數(shù)據(jù)，輸出結果會是：
示例：原生Python
下面的示例使用Python來做相同的事---將給定的數(shù)據(jù)展示到web頁面上。其中使用了CGI Python package 來處理表單數(shù)據(jù)。
結果和之前用PHP處理是一樣的：
其它語言和框架
還有許多其他的服務端技術可以用來處理表單，比如Perl, Java, .Net, Ruby等等，選擇你最喜歡的一種就好。我們很少直接使用這些技術，因為這么做得需要很多技巧來填坑;通常我們會在眾多好用的框架中選擇一種，這樣會讓表單的處理更容易些，比如：
- Symfony for PHP
- Django for Python
- Ruby On Rails for Ruby
- Grails for Java
值得注意的是，就算用了這些框架，處理表單是不一定就會變得輕松。但至少這樣用起來會更好些，還能節(jié)省你不少時間。
特殊案例：發(fā)送文件
文件是HTML表單中一個特殊的例子，其他數(shù)據(jù)都是文本數(shù)據(jù)，而文件則一般是、或者被認為是二進制數(shù)據(jù)。由于HTTP是個文本協(xié)議，所以對處理二進制數(shù)據(jù)得有特別的要求。
enctype特性
該特性能讓你指定HTTP請求頭中的Content-Type字段值，這個字段的重要性在于，它能告訴服務器要發(fā)送的數(shù)據(jù)類型。其默認值是application/x-www-form-urlencoded，對應的解釋是：“這份表單數(shù)據(jù)已被編碼為URL格式”。
而當你想發(fā)送文件時，得先做兩件事：
- 將method特性設置為POST，因為使用表單時，文件內容是不能被放到URL參數(shù)里的
- 將enctype特性的值設為multipart/form-data，這樣數(shù)據(jù)就會被分割為多個部分，每個文件都會追加上和他們一起發(fā)送的表單有關的文本。
示例：
注意：某些瀏覽器支持<input>元素的multiple特性，以便讓一個input元素能發(fā)送多個文件。至于服務器會如何處理這些文件，就得取決于它用來什么技術了。如前所述，使用框架能讓你的活的輕松些~
警告：為防止濫用，許多服務器會對文件和HTTP請求設置大小限制。所以，最好在發(fā)送文件之前和服務器管理員核實一下這個限制。
安全相關
每次要發(fā)數(shù)據(jù)給服務器前，你都得考慮下安全問題。HTML表單是針對服務器的首要攻擊載體之一，但該危害的來源并非HTML表單本身，而在于服務器如何處理數(shù)據(jù)。
常見的安全問題
著名的安全問題有很多，如何劃分取決于你在做什么：
XSS和CSRF
跨站腳本攻擊(XSS)和跨站請求偽造(CSRF)是最常見的攻擊類型，它們會在你展示由用戶發(fā)給用戶的數(shù)據(jù)時發(fā)生。
XSS讓攻擊者能再其他用戶訪問的Web頁面上注入客戶端腳本。攻擊者會利用跨站腳本的脆弱性來繞過訪問控制策略，譬如同源策略。這種攻擊可以取得從小麻煩到嚴重安全危機不等的危害效果。
CSRF很像XSS，因為它們都以相同的方式開始---注入客戶端腳本到Web頁面，但它們的攻擊目標卻不同。CSRF攻擊者會試著升級權限以成為一個高權限的用戶(比如網站管理員)，然后執(zhí)行本不能夠執(zhí)行的動作(如把數(shù)據(jù)發(fā)送給不受信任的用戶)。
XSS攻擊利用了用戶對網站的信任，而CSRF攻擊則利用了網站對其用戶的信任。
要防止此類攻擊，就得時常校驗用戶發(fā)送給服務器的數(shù)據(jù);同時(如果需要展示)也盡量別展示用戶提供的HTML內容，而應該處理用戶提供的數(shù)據(jù)，以避免將其原封不動地顯示出來。目前幾乎所有市面上的的框架，至少都會實現(xiàn)一個過濾器，用以移除用戶提交數(shù)據(jù)中<script>, <iframe>, <object>等標簽，這樣有助于減輕風險，但并不意味著會根除它。
SQL注入
SQL注入是一種對目標網站的數(shù)據(jù)庫執(zhí)行動作的攻擊方式。通常攻擊者會發(fā)送一段SQL請求，并希望服務器能執(zhí)行它(多數(shù)發(fā)生在應用服務器想存儲數(shù)據(jù)之時)。這實際上已成為針對web站點的主要攻擊載體之一。
該攻擊的危害是很嚴重的，小到數(shù)據(jù)丟失、大到被攻擊者通過權限升級訪問整個網站架構。這確實是非常重大的威脅，所以你不應該存儲那些用戶提交而沒經過特殊處理(例如，在PHP/MySQL架構下經過mysql_real_escape_string()處理)的數(shù)據(jù)。
HTTP頭部注入和郵件注入
這種攻擊會在你的應用使用用戶在表單上輸入的數(shù)據(jù)來構造HTTP頭、或者email時發(fā)生。該攻擊雖然不會危害你的服務器或者影響你的用戶，但卻會給更深處的問題大開方便之門，比如會話劫持、釣魚攻擊。
所有這些攻擊往往都是悄無聲息地發(fā)生的，而且會把你的服務器弄成肉雞)。
偏執(zhí)些：永遠別信任你的用戶
所以，要如何對抗這些威脅呢?這一點已超出本指南的主題范圍了，但有幾條規(guī)則時需要我們牢記的。最重要的一條就是：永遠別信任你的用戶，包括你自己;即使是受信任的用戶也會有被劫持可能。
所有的到達你服務器的數(shù)據(jù)都必須被校驗并處理，而且要一直保持，不能有例外。
- 過濾潛在的危險字符。要關注的哪些特定字符，取決于使用數(shù)據(jù)的上下文、也取決于你使用的服務器平臺，而所有的服務端語言都會提供相應的功能。
- 限制傳入的數(shù)據(jù)量，只允許有必要的。
- 把上傳的文件放沙盒里(將它們存儲到放到一個不同的服務器上，并且要訪問到它們只有通過一個不同的子域名、或一個完全不同的域名才行)。
若你能遵循這三條規(guī)則，就應該能避免絕大多數(shù)問題，但一個更好的辦法是讓一個有資格的第三方來做安全審查，別以為你能看透所有潛在的問題。
結論
如你所見，發(fā)送表單數(shù)據(jù)時很簡單的，但保障一個應用的安全就需要很多技術了。前端開發(fā)者不是那種去定義一個數(shù)據(jù)安全模型的角色，雖然可能得執(zhí)行[客戶端數(shù)據(jù)校驗]()，但是服務器也不能信任這些校驗，因為它并不能確切知道客戶端上到底發(fā)生過什么。
作者：Levon
來源：51CTO
總結
以上是生活随笔為你收集整理的如何发送HTML表单数据的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： c语言中数组名a和a详细介绍
- 下一篇： MIT黑科技：全新芯片将语音识别功耗降低