Request.Referer的亂碼終極解決方法+獲得使用者是用什麼關鍵字通過搜尋引擎進來的
當你想獲取Url字串的時候，最好不要直接呼叫 Request.UrlReferrer.ToString()方法，因為這樣有可能返回的是一堆亂碼。產生的原因是，使用者在來你網站之前的那個網站的編 碼方式（Encoding)也許和你的網站不一樣，導致Url Decode的時候出現了亂碼。這裡建議使用Request.UrlReferrer.OriginalString，這個屬性返回的就是當時構造Uri 物件的原始Url。
以下為獲得使用者是用什麼關鍵字通過搜尋引擎進來的方法
什麼是HTTP Referer
簡言之，HTTP Referer是header的一部分，當瀏覽器向web伺服器傳送請求的時候，一般會帶上Referer，告訴伺服器我是從那個頁面連結過來的，伺服器 籍此可以獲得一些資訊用於處理。可以用於統計訪問本網站的使用者來源，也可以用來防止盜連結（注意：用這種方法來防止盜連結有很大的侷限性，因為 Header中的資訊很容易偽造）。在.NET中取得該欄位非常簡單，你只需要做如下呼叫即可：Request.UrlReferrer，該值返回的是一 個Uri物件。值得注意的是，當你想獲取Url字串的時候，最好不要直接呼叫Request.UrlReferrer.ToString()方法，因為 這樣有可能返回的是一堆亂碼。產生的原因是，使用者在來你網站之前的那個網站的編碼方式（Encoding)也許和你的網站不一樣，導致Url Decode的時候出現了亂碼。這裡建議使用Request.UrlReferrer.OriginalString，這個屬性返回的就是當時構造Uri 物件的原始Url，即沒有經過Decode操作。當然，如果你只是想獲取Url字串的話，還可以這樣調 用：Request.Headers["Referer"]。但你得先判斷一下瀏覽器是否傳送了該值，如果沒有傳送該值，則返回null。（小提示：細心 的人可能看出來了，在HTTP Header中Referer的不是英文單詞Referrer。Referer其實應該是英文單詞Referrer，不過拼錯的人太多了，所以編寫標準的 人也就將錯就錯了。但在.NET中修改了這個錯誤，所以是Request.UrlReferrer，而不是Request.UrlReferer，使用的 時候小心一點就是了）
Referer不能正確獲取
Firefox中關於Referer的設定有兩個鍵值:network.http.sendRefererHeader (default=2) 設定Referer的傳送方式，0為完全不傳送；1為部分發送；2為始終傳送。我檢查了我的Firefox設定，明明設定的是2啊，也就是說都要傳送這個 欄位的，但我除錯的時候發現Firefox確實沒有傳送這個欄位，Request.UrlReferrer始終為null。於是上網去找找有沒有解決的辦 法，發現有很多人和我遇到了相同的問題，但都沒有說明原因，也沒有找到合適的解決方案。在微軟的官方網站，好像有人提交了這個Bug，請參考 http://connect.microsoft.com/VisualStudio/feedback /ViewFeedback.aspx?FeedbackID=103334。搞了半天，微軟回覆說沒法重現這個Bug。FT。。。除了Firefox 外，其他幾個瀏覽器IE，Safari，好像都有這個問題。
查詢解決辦法
在網上找了一陣，還是無果而終。於是我自己觀察了網站的訪問日誌，發現並不是所有的Firefox的訪問記錄Url Refferrer都是空的，有的確是正確的傳送了資訊的。我開始還懷疑是FF的版本問題，於是我去下載了FF的最新版本3.0.8， 裝上之後結果依然。看來不是版本的問題。我仔細想了一下，出現這樣的情況無非有兩個原因：第一，FF沒有正確傳送Refferrer到伺服器；第二，FF 正確傳送了Refferrer，伺服器的.NET程式沒能正確擷取該值。為了檢視FF是否正確傳送了Refferre，我用了一個網路抓包工具，把FF發 送的資料抓回來分析了一番，驚奇的發現在FF傳送的Header正確的傳送了Refferrer。如下所示：
Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.baidu.com/s?wd=%C3%C0%C3%FB%CC%DA
Cookie: ....
這樣一來，就徹底排除了FF沒有正確傳送的問題。難道是Server沒能正確識別FF傳送的Refferrer？我開始還是有點懷疑的，可是仔細一想， 除了Refferrer沒能正確處理以外，其他的Header都是正確的啊，.NET不會傻到這種程度的，所以我覺得還是客服端在傳送資料的時候出了問 題。這時候，我突然想到很多防火牆軟體會掃描網路資料包。會不會是防火牆截斷了FF傳送的Refferrer呢？我機器上是OEM的諾頓防火牆，由於一直 用諾頓，我對他還是有些好感的。為了驗證我的想法，我暫時關閉了諾頓的Internet監控功能。重新試了一遍之前的訪問操作，驚奇的發現這次我的訪問記 錄裡面正確提取了Refferrer。到這裡，我大概就明白了，肯定是諾頓自動去掉了Header中的Refferrer資訊！！這個時候，我重新測試了 IE，Safari等瀏覽器，都能正確獲取Refferrer值了。到此為止，這個問題算是找到答案了，諾頓去掉了我的瀏覽器傳送的Header中的 Refferer資訊！！我的問題是解決了，不知道網上其他那些遇到同樣問題的朋友是否也是防火牆的原因。希望我的經歷對此有些幫助。
最後，由於我在找原因的過程中，發現有的朋友敘述的問題與我的還不完全一樣，他們的是IE能正確提取Refferrer，而FF卻不行，這個時候請你看看的FF設定是否有問題，即network.http.sendRefererHeader的值是否設定為2。