在使用苹果天猫APP扫码时，服务端接收到参数，对json字符串进行解码时，总是遇到下面的报错：
而使用苹果淘宝APP则是正常。因此怀疑是天猫和淘宝APP对json格式的解析方法或者对Base64的解码方法不相同。
经过一番探究，发现在两个不同解码网站进行测试时，得到的结果竟然不一样。
使用该字符串（eyJkZXZpY2VJZCI6MiwidXNlcklkIjoxNTQ3fQ）进行测试：
若对字符串末尾加上“==”，则可以正确解码：
对字符串末尾加上“==”，也可以正确解码：
由此，基本可以确定是解码工具不一样导致的。
检查了服务端代码，我目前使用的是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扫码：
