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地址栏手动输入中文进行处理的搜索引擎，还只有谷歌，不过今日再看，已经有不少的公司也做到了。