這篇文章算是對我前幾年在做搜尋引擎專案時候無法解決的一個問題畫一個句號吧，用處不大，不過可以彌補下自己的一個遺憾。
當時的場景是這樣子的，本來正常人的習慣總是在搜索框輸入正常搜索詞然後進行搜索，但是總有一些用戶會自認為聰明的，從地址欄複製出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)
';三年前，會對IE網址列手動輸入中文進行處理的搜尋引擎，還只有谷歌，不過今日再看，已經有不少的公司也做到了。
以上就介紹了IE瀏覽器在網址列針對param直接輸入中文導致亂碼的解決方案，包括了方面的內容，希望對PHP教程有興趣的朋友有所幫助。
