1. get是從服務器上獲取數(shù)據(jù)，post是向服務器傳送數(shù)據(jù)。2. get是把參數(shù)數(shù)據(jù)隊列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個字段一一對應，在URL中可以看到。post是通過HTTP post機制，將表單內(nèi)各個字段與其內(nèi)容放置在HTML HEADER內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。3. 對于get方式，服務器端用Request.QueryString獲取變量的值，對于post方式，服務器端用Request.Form獲取提交的數(shù)據(jù)。4. get傳送的數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。5. get安全性非常低，post安全性較高。但是執(zhí)行效率卻比Post方法好。 建議：1、get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數(shù)據(jù)提交方式；2、在做數(shù)據(jù)查詢時，建議用Get方式；而在做數(shù)據(jù)添加、修改或刪除時，建議用Post方式；
如果有人問你，GET和POST，有什么區(qū)別？你會如何回答？
我的經(jīng)歷
前幾天有人問我這個問題。我說GET是用于獲取數(shù)據(jù)的，POST，一般用于將數(shù)據(jù)發(fā)給服務器之用。
這個答案好像并不是他想要的。于是他繼續(xù)追問有沒有別的區(qū)別？我說這就是個名字而已，如果服務器支持，他完全可以把GET改個名字叫GET2。他反問道，那就是單純的名字上的區(qū)別嘍？我想了想，我覺得如果說再具體的區(qū)別，只能去看RFC文檔了，還要取決于服務器（指Apache，IIS）的具體實現(xiàn)。但我不得不承認，我的確沒有仔細看過HTTP的RFC文檔。于是我說，我對HTTP協(xié)議不太熟悉。這個問題也就結束了。
最普遍的答案
回來之后尋思了很久，他到底是想問我什么？我一直就覺得GET和POST沒有什么除了語義之外的區(qū)別，自打我開始學習Web編程開始就是這么理解的。
可能很多人都已經(jīng)猜到了，他要的答案是：
GET使用URL或Cookie傳參。而POST將數(shù)據(jù)放在BODY中。GET的URL會有長度上的限制，則POST的數(shù)據(jù)則可以非常大。POST比GET安全，因為數(shù)據(jù)在地址欄上不可見。
但是很不幸，這些區(qū)別全是錯誤的，更不幸的是，這個答案還是Google搜索的頭版頭條，然而我根本沒想著這些是答案，因為在我看來他們都是錯的。我來一一解釋一下。
1. GET和POST與數(shù)據(jù)如何傳遞沒有關系
GET和POST是由HTTP協(xié)議定義的。在HTTP協(xié)議中，Method和Data（URL， Body， Header）是正交的兩個概念，也就是說，使用哪個Method與應用層的數(shù)據(jù)如何傳輸是沒有相互關系的。
HTTP沒有要求，如果Method是POST數(shù)據(jù)就要放在BODY中。也沒有要求，如果Method是GET，數(shù)據(jù)（參數(shù)）就一定要放在URL中而不能放在BODY中。
那么，網(wǎng)上流傳甚廣的這個說法是從何而來的呢？我在HTML標準中，找到了相似的描述。這和網(wǎng)上流傳的說法一致。但是這只是HTML標準對HTTP協(xié)議的用法的約定。怎么能當成GET和POST的區(qū)別呢？
而且，現(xiàn)代的Web Server都是支持GET中包含BODY這樣的請求。雖然這種請求不可能從瀏覽器發(fā)出，但是現(xiàn)在的Web Server又不是只給瀏覽器用，已經(jīng)完全地超出了HTML服務器的范疇了。
知道這個有什么用？我不想解釋了，有時候就得自己痛一次才記得住。
2. HTTP協(xié)議對GET和POST都沒有對長度的限制
HTTP協(xié)議明確地指出了，HTTP頭和Body都沒有長度的要求。而對于URL長度上的限制，有兩方面的原因造成：
瀏覽器。據(jù)說早期的瀏覽器會對URL長度做限制。據(jù)說IE對URL長度會限制在2048個字符內(nèi)（流傳很廣，而且無數(shù)同事都表示認同）。但我自己試了一下，我構造了90K的URL通過IE9訪問live.com，是正常的。網(wǎng)上的東西，哪怕是Wikipedia上的，也不能信。服務器。URL長了，對服務器處理也是一種負擔。原本一個會話就沒有多少數(shù)據(jù)，現(xiàn)在如果有人惡意地構造幾個幾M大小的URL，并不停地訪問你的服務器。服務器的最大并發(fā)數(shù)顯然會下降。另一種攻擊方式是，把告訴服務器Content-Length是一個很大的數(shù)，然后只給服務器發(fā)一點兒數(shù)據(jù)，嘿嘿，服務器你就傻等著去吧。哪怕你有超時設置，這種故意的次次訪問超時也能讓服務器吃不了兜著走。有鑒于此，多數(shù)服務器出于安全啦、穩(wěn)定啦方面的考慮，會給URL長度加限制。但是這個限制是針對所有HTTP請求的，與GET、POST沒有關系。
安全不安全和GET、POST沒有關系
我覺得這真是中國特色。我講個小段子，大家應該可以體會出這個說法多么的可笑。
覺得POST數(shù)據(jù)比GET數(shù)據(jù)安全的人會說
“防君子不防小人；中國小白多，能防小白用戶就行了。”
“哼，”我不以為然，“那你怎么不說，URL參數(shù)都Encode過了，或是Base64一下，小白也看不懂啊。”
那人反駁道，“Encode太簡單了，聰明點兒的小白很容易就可以Decode并修改掉。”
我笑道，“五十步笑百步耳，再聰明點兒的小白還會截包并重發(fā)呢，Opera就有這功能。”
那人陰險地祭出神器——最終解釋權，說，“這個不算小白。”
我日啊。
最后一點兒感想
我之前一直做Windows桌面應用，對Web開發(fā)無甚了解，直到一年多前轉做服務器端開發(fā)，才開始接觸到HTTP。（注意，我說的是HTTP，不是HTML。服務器開放接口是基于REST理念設計的，使用的協(xié)議是HTTP，但是傳輸?shù)膬?nèi)容不是HTML。這不是Web Server，而是一個Web Service）
所以我對于GET和POST的理解，是純粹地來源于HTTP協(xié)議。他們只有一點根本區(qū)別，簡單點兒說，一個用于獲取數(shù)據(jù)，一個用于修改數(shù)據(jù)。具體的請參考RFC文檔。
如果一個人一開始就做Web開發(fā)，很可能把HTML對HTTP協(xié)議的使用方式，當成HTTP協(xié)議的唯一的合理使用方式。從而犯了以偏概全的錯誤。
可能有人會覺得我鉆牛角尖。我只是不喜歡模棱兩可，不喜歡邊界不清、概念不明，不喜歡“拿來主義”，也不喜歡被其它喜歡鉆牛角尖的人奚落得無地自容。
“知之為知之，不知為不知，是知也。”