【原创】使用simc类Base64方法解码引发的奇葩问题

在使用苹果天猫APP扫码时，服务端接收到参数，对json字符串进行解码时，总是遇到下面的报错：

而使用苹果淘宝APP则是正常。因此怀疑是天猫和淘宝APP对json格式的解析方法或者对Base64的解码方法不相同。

经过一番探究，发现在两个不同解码网站进行测试时，得到的结果竟然不一样。

使用该字符串（eyJkZXZpY2VJZCI6MiwidXNlcklkIjoxNTQ3fQ）进行测试：

1. http://tool.chinaz.com/Tools/Base64.aspx ，提示解码失败

若对字符串末尾加上“==”，则可以正确解码：

2. http://base64.xpcha.com/ ，则成功
   

对字符串末尾加上“==”，也可以正确解码：

由此，基本可以确定是解码工具不一样导致的。

检查了服务端代码，我目前使用的是sun.misc.BASE64Decoder的解码方法，

查看了几篇文章，在这篇文章中（ https://blog.csdn.net/u013476542/article/details/53213783） 提到sun.misc.BASE64Decoder并不被推荐，有可能未来会被删除，

因此猜测有可能是这个工具类引起的，那就不如换个其他工具类试下。
暂定使用了文章提到的“常用的Apache Commons Codec library里面的org.apache.commons.codec.binary.Base64”。

写了一个测试方法对该字符串进行测试，

传入不加和加上“==”的两种字符串，发现果然都可以正确解码：

赶紧改了改代码，部署到服务端测试，果然正常啦！

至此，开心得感极而泣啦！昨天还花了两个小时研究，以为是前端编码入参的问题，最终还是排除了前端问题，定位在服务端方法异常。

话说回来，为什么苹果淘宝扫码可以正常，而天猫APP则不可以？
试验了下，对扫码结果进行了日志记录，终于发现了问题：
淘宝服务器和天猫服务器对参数的处理方式有差异，淘宝会对base64编码过的字符串保留==（应该是使用类似Base64.DEFAULT的方式），而天猫则默认会去掉末尾 的==（应该是使用类似Base64.NO_PADDING的方式），而恰巧使用sun.misc.BASE64Decoder则不可以解码没有==的字符串
——就是这么巧合，所以奇葩问题才会来了。

使用淘宝APP扫码：

使用天猫APP扫码：