IE瀏覽器在地址欄針對param直接輸入中文導致亂碼的解決方案

    這篇文章算是對我前幾年在做搜索引擎項目時候無法解決的一個問題畫一個句號吧，用處不大，不過可以彌補下自己的一個遺憾。

    當時的場景是這樣子的，本來正常人的習慣總是在搜索框輸入正常搜索詞然後進行搜索，但是總有一些用戶會自認爲聰明的，從地址欄複製出URL，然後改parameter然後進行訪問，類似於http://www.xxx.com/search?keyword =%E4%B8%AD%E6%96%87 (IE下的顯示，至於chrome和firefox等則會在地址欄顯示中文)，當用戶提交的請求在IE下是http://www.xxx.com/search?keyword =中文  時，你會發現服務端（web處理後端）根本無法識別這種字符，這是瀏覽器在向後端提交請求的時候，其參數必須是iso-8859-1規範的URLEncode，在寫web程序的時候，IE必須要我們手動去轉換編碼，而chrome和firefox則可轉可不轉，因爲它們會在傳輸的時候自動轉換。

    後端無法識別字符，也就是我們常說的亂碼。這種亂碼產生的原因也是因爲解碼錯誤，我們的web容器（框架 、類似於java中的jetty/tomcat/jboss和python中的django之類的）會自動把這串字符進行UrlDecode.此時，IE提交的沒有經過編碼的字符被解碼，那可想而知，再也回不來了（多少人曾經像我一樣看到這種亂碼，病急亂投醫）。

    ok,解決這種問題的方案其實有兩種，第一種是在到達web後端之前（沒辦法在js層，因爲用戶是直接敲地址欄的回車的），也就是說是在服務端的前端（nginx）進行預處理，將沒有編碼的字符進行url編碼。第二種是重新編譯web容器中關於servlet處理參數進行decode的邏輯，進行判斷其是否需要urldecode。

    鑑於實現的難度，我選擇了第一種，在nginx進行處理，在nginx中採用lua進行對參數進行轉碼，然後再反向代理到web後端。

    在這裏，需要視乎自己的項目而定，有幾種情況要注意，比如自己的項目是UTF-8編碼還是GBK編碼，客戶的環境是UTF-8還是GBK，這些都要做不同的處理，比如我的系統是瀏覽器所在系統是windows，所以我的客戶機的編碼是GBK，然後我的項目是UTF-8的，所以在進行urlencoding之前，還需要再進行將GBK-》UTF-8的操作。

 set_by_lua $arg_name 
			'
				local iconv = require("luaiconv")
				local cd = iconv.new( "utf-8","gbk")
				
				if(string.find(ngx.var.arg_name,"%")){
					ngx.var.arg_name, err = cd:iconv(ngx.var.arg_name)
				}
				return ngx.escape_uri(ngx.var.arg_name)
			';

    在這個場景下，我的參數名是name，然後我採用了luaiconv的庫進行轉換。其實我這個邏輯不是很嚴謹，比如我沒有判斷編碼，在判斷是否需要編碼的場景，也只是通過字符串中是否含有%來做判斷。

    三年前，會對IE地址欄手動輸入中文進行處理的搜索引擎，還只有谷歌，不過今日再看，已經有不少的公司也做到了。