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地址栏手动输入中文进行处理的搜索引擎，还只有谷歌，不过今日再看，已经有不少的公司也做到了。
以上就介绍了IE浏览器在地址栏针对param直接输入中文导致乱码的解决方案，包括了方面的内容，希望对PHP教程有兴趣的朋友有所帮助。