关于2B的转义问题

　　最近碰到了一个中文乱码问题，话说是这样的：模块A调模块B的1接口，B把A带过来的用户ID加密后返回一个链接，当用户点击该链接时，A解密该用户ID后再调B的2接口。简而言之，我们用流程看下：模块A ->(1，加密userID) 模块B -> 链接 -> 模块A ->(2，解密userID) -> 模块B。问题出在链接上，模块B返回的链接里userID刚好加密完了有一个+号，经过转义+号变成了%2B，但是模块A没有按B提供的转义后的链接给用户，而是自己提供给未转义的链接（%2B又变回了+号），这时A模块从浏览器获取userID后，再解密就变成了一串乱码：d[pk 161

　　我们先看模块B的加密：

public static void main(String[] args) throws Exception
{
    String value = "XXXXXXX";
    String msisdn = "53003443161";
    byte[] middleString = encrypt(msisdn, value);
    byte[] arr = Base64.encodeBase64(middleString, true);
    value = new String(arr, "UTF-8");
    value = value.replaceAll("[\\s*\t\n\r]", "");
    System.out.println(value);
    //转义
    value = URLEncoder.encode(value, "utf-8");
   System.out.println(value);
}

　　秘钥我就不贴了，这里我把没转义的和转义过的都打印出来了：

thgrhWmM0+EasSHO5Ld2GQ==
thgrhWmM0%2BEasSHO5Ld2GQ%3D%3D

　　从上面我们可以看到+转义为%2B，=转义为%3D。我们返回出去的链接是：http://wlf.com/p/wlf.jsp?userID=thgrhWmM0%2BEasSHO5Ld2GQ%3D%3D，经过浏览器%2B会变成+，再解密userID是ok的。但人工提供的未转义链接却是长这样的：http://wlf.com/p/wlf.jsp?userID=thgrhWmM0+EasSHO5Ld2GQ%3D%3D。通过浏览器用get方式访问时，+号会被浏览器处理为空，所以userID就变成了

thgrhWmM0 EasSHO5Ld2GQ%3D%3D，中间的+号被吃了，变成了空格，再去解密自然成乱码了。

　　解决办法就是提供转义后的userID。