公司要建個文檔管理系統，想想沒必要自己寫，就在網上找了一個基於AMP的開源軟件OpenDocMan。部署倒也很順利，就在是通過部門查詢文檔的時候，出現了無法根據中文搜索的問題。
開啓mysql日誌後，發現查詢語句中的查詢條件爲SELECT * FROM D where name LIKE '%u751F%u4EA7%u90E8' )。對'%u751F%u4EA7%u90E8' ，百度了一下，就是是自己的查詢條件：“生產部”的unicode編碼。分析屬於字符集問題，於是把數據庫字符集都改成和頁面編碼一樣的UTF-8，仍然不行。突然想到查詢語句本身就不對，當然怎麼改數據庫也沒用了。變換思路在服務端對這個字符串進行解碼成自己需要的查詢條件，加解碼函數，還是不行，甚至想過在數據庫端進行解碼，也沒成功。
仔細思考一下，發現中文傳參需要編碼是很正常的，但是一般情況下編碼出來都不會是%U這種格式的，而是%E6%82%A8這樣的格式，是瀏覽器根據頁面頭中規定的格式來進行編碼，一般是GBK，或者是UTF-8，再翻翻源代碼，發現頁面中指定字符集爲utf-8，那很明顯%u751F%u4EA7%u90E8不是瀏覽器編碼得來的，而是通過代碼中通過編碼函數得來的。順着線索找，終於在源代碼中找到了提交請求的JS代碼，其中用了escape函數來編碼查詢條件，直接刪除escape，讓瀏覽器自動編碼，再試中文查詢，這下整個世界安靜了。
這個問題花了這麼長時間，主要還是我對js不太熟悉造成的。
關於escape和頁面參數編碼更詳細可以看這篇文章，講得非常細緻
http://www.haorooms.com/post/js_escape_encodeURIComponent