今天在通过jsp给后端传参过程中，发现后台接收的是乱码。花了两个小时，终于解决了，现在记录一下。
背景
现在有一个jsp页面，里面主要的内容是表格，其中表格中的每一行最后一列是操作部分，点击可以对该行进行修改或删除。
如上图，点击"修改"会将左边的参数传给后台。"配电主类型"和"配电副类型"两列看着是文字，实际上传的是数字；参数类型这一项不参与上传；"参数编码"和"参数名称"两项是文字，除此之外，还有一个uuid会传给后台。如下图所示：
在浏览器的地址栏上显示了我所上传的内容：
paraId就是前面提到的uuid；devMainType和devSubType对应配电主类型和配电副类型；paraCode和paraName两项是本文关注的重点，即前面提到的参数编码和参数名称。
问题
在提交了URL之后，会把这些参数传给后台代码，后台代码将转到另一个前端jsp页面，将传的参数显示出来。在这里，后台代码只负责中转，并未对上传参数作处理。但是在显示页面中却出了问题：
（因为其它几项是正常的，就没有截图）本来是中文的参数编码和参数名称都已经乱掉了。
思路
回想整个过程，前端jsp（代号A）获取表格某行中的数据，然后将这些数据传给浏览器（代号B），B将参数传给后台C。
- 首先，保证A到B，参数没有乱。
通过对参数加console.log()，发现传的是中文，check.
- 其次，检查C接收的是还是乱码。如果不是乱码，说明是C的原因导致最后显示有问题；如果已经是乱码，说明是B到C的过程出现了问题。
对后台加断点，发现在接收的时候，就已经是乱码了。
结论：B应该背锅。
检查浏览器
重新看一下A传数据B的时候发生了什么。打开Chrome Developer Tool
把URL部分放大：
可以发现，paraCode和paraName两项已经变成了%E6%B5%8B等字样。。。。
上面这张图的第一行右边还有"view parsed"，点开看一下：
没错，解析出来的确实是我传的。然而被浏览器编码成了这样子：
现在已经可以肯定，浏览器对我URL里面的中文做了某种格式的编码，就变成了%E6%B5...这个样子。那是哪种格式的编码呢？通过站长工具一个一个的试，最后发现是URL编码。
解决
既然浏览器会对中文编码，那传给浏览器时不要包含中文不就好了嘛。但A取到的表格中的数据就是中文怎么办呢？可以在A里就对这些中文进行编码，编码后的结果就是%E6%B5%8B%E8%AF%95了，这时候浏览器就不会再对它加编码了。
步骤
在A中，对paraCode和paraName加两次encodeURI()
在C中，对接收到的参数加一次decode
然后重新看一下最终的显示页面
这两个中文终于能正常显示了:)
疑问1
为什么要A中是两次编码，而C中只有一次解码呢？这是因为tomcat容器已经默认解了一次码。
那又要问了，既然容器默认已经有解码了，那在A中加一次编码，C中不解码可不可以呢？
可能可以，可能不可以。因为容器解码时使用的编码方式是容器的默认编码方式，可能是UTF-8，可能是GBK，也有可能是其它乱七八糟的编码方式。你不能保证跟你的编码方式相同。所以这种方式可能会出现乱码。
如果觉得两次编码的方式太烦了，而一定要使用这种一次编码的方式也是可以的。这里就需要修改容器的默认编码方式，让它与你的编码方式相同。比如修改成UTF-8。怎么修改呢？在tomcat安装目录下conf目录下的server.xml：
把这一行变成
疑问2
细心的朋友可能发现了，浏览器对中文编码之后，向C传的明明是%E6%B5%8B%E8%AF%95这种形式的，为什么C接收到的却是&æ&mirco...这样的html转义字符了呢？好吧，我也不清楚。。。
参考资料：
[1] 关于URL编码 (http://www.ruanyifeng.com/blog/2010/02/url_encoding.html)