java.net.URLDecoder.decode
在项目中碰到了个比较奇怪的问题，就是我在本地使用java.net.URLDecoder.decode(ruleName)方法解码，没有问题，本地的页面也可以正常打开。但是当我把代码移植到测试环境中去的时候，却打不开页面，查看后台日志也没有报错信息。
本地环境用的JDK1.6，tomcat用的7，测试环境JDK1.6 tomcat版本不明确
就纳闷了，因为这个方法已经提示过时了，就在考虑是不是这个问题导致的，应该有可以替代的方法，然后就去查看了下JDK的API，如下
试着将代码中的java.net.URLDecoder.decode(ruleName)修改为java.net.URLDecoder.decode(ruleName, "UTF-8");然后编译，替换测试环境的代码，发现问题解决了。
这应该就是JDK中有些过时的代码在低版本的tomcat中可能失效了，所以大家在以后的编程中一定要尽量避免过时方法的使用，以规避不必要的问题。
案例2：
和基友一起撸Java Web，基友负责前端我负责后端。前端用jQuery与后端交互，参数和响应全部用JSON传。在传参数的时候JSON字符串肯定会被URL Encode，在后端要进行URL Decode之后才能解析。一开始用的是URLDecoder解析：
- return URLDecoder.decode(str);
之后发现中文全都是乱码……很尴尬。一开始以为是浏览器发送的数据的编码和Java默认的编码不一样，于是各种转换编码，还是跪了。判断了一下编码，发现本来就是UTF-8，但打印出来还是乱码。后来把字符串按字节打印出来，发现中文部分和URL Encode之后的那部分字符串完全吻合，之前也看到有人用URL Encode然后Decode解决了中文乱码问题，才意识到是URL Decode出了问题。其实URLDecoder.decode(String) 这个方法是deprecated的，加上指定文本编码的参数，乱码问题解决：
- return URLDecoder.decode(str, "UTF-8");
顺便贴一下Java中判断字符串编码的方法：
- public static String getEncoding(String str) {
- String[] encode = {
- "GB2312", "ISO-8859-1", "UTF-8", "GBK"
- };
- for(int i = 0; i < encode.length; i++) {
- try {
- if(str.equals(new String(str.getBytes(encode[i]), encode[i]))) {
- return encode[i];
- }
- } catch (UnsupportedEncodingException e) {
- }
- }
- return "";
- }
写Java都快写吐了，有时间的话或许该学学Python了，毕竟人生苦短。