在使用蘋果天貓APP掃碼時(shí)，服務(wù)端接收到參數(shù)，對(duì)json字符串進(jìn)行解碼時(shí)，總是遇到下面的報(bào)錯(cuò)：
而使用蘋果淘寶APP則是正常。因此懷疑是天貓和淘寶APP對(duì)json格式的解析方法或者對(duì)Base64的解碼方法不相同。
經(jīng)過一番探究，發(fā)現(xiàn)在兩個(gè)不同解碼網(wǎng)站進(jìn)行測(cè)試時(shí)，得到的結(jié)果竟然不一樣。
使用該字符串（eyJkZXZpY2VJZCI6MiwidXNlcklkIjoxNTQ3fQ）進(jìn)行測(cè)試：
若對(duì)字符串末尾加上“==”，則可以正確解碼：
對(duì)字符串末尾加上“==”，也可以正確解碼：
由此，基本可以確定是解碼工具不一樣導(dǎo)致的。
檢查了服務(wù)端代碼，我目前使用的是sun.misc.BASE64Decoder的解碼方法，
查看了幾篇文章，在這篇文章中（ https://blog.csdn.net/u013476542/article/details/53213783） 提到sun.misc.BASE64Decoder并不被推薦，有可能未來會(huì)被刪除，
因此猜測(cè)有可能是這個(gè)工具類引起的，那就不如換個(gè)其他工具類試下。
暫定使用了文章提到的“常用的Apache Commons Codec library里面的org.apache.commons.codec.binary.Base64”。
寫了一個(gè)測(cè)試方法對(duì)該字符串進(jìn)行測(cè)試，
傳入不加和加上“==”的兩種字符串，發(fā)現(xiàn)果然都可以正確解碼：
趕緊改了改代碼，部署到服務(wù)端測(cè)試，果然正常啦！
至此，開心得感極而泣啦！昨天還花了兩個(gè)小時(shí)研究，以為是前端編碼入?yún)⒌膯栴}，最終還是排除了前端問題，定位在服務(wù)端方法異常。
話說回來，為什么蘋果淘寶掃碼可以正常，而天貓APP則不可以？
試驗(yàn)了下，對(duì)掃碼結(jié)果進(jìn)行了日志記錄，終于發(fā)現(xiàn)了問題：
淘寶服務(wù)器和天貓服務(wù)器對(duì)參數(shù)的處理方式有差異，淘寶會(huì)對(duì)base64編碼過的字符串保留==（應(yīng)該是使用類似Base64.DEFAULT的方式），而天貓則默認(rèn)會(huì)去掉末尾 的==（應(yīng)該是使用類似Base64.NO_PADDING的方式），而恰巧使用sun.misc.BASE64Decoder則不可以解碼沒有==的字符串
——就是這么巧合，所以奇葩問題才會(huì)來了。
使用淘寶APP掃碼：
使用天貓APP掃碼：
