今天发布的博客有些临时赶场成分…
下班骑上哈罗飞奔回家，天气还一如既往的炎热，于是到了家习惯性的打开了空调，从冰箱掏出冰棒享受着透心凉的赶脚。待身上的热辐射褪去殆尽，便去开锅做起牛肉粉丝汤，嗯，今天的晚餐。做好，盛碗，端进卧室，在空调的风口下吃口味更佳，嗯，还不起劲，打开了“王者农药”进行一场刺激的峡谷之战，边吃边玩，意境更佳。
完事，洗碗刷锅后看看手机上的时间，如果时间充足的话就去游泳，然而“一不小心”看到了今天的日期，F…K！31号了！这个月一篇文章都没发！！！
赶紧开机开写，于是有了今天的意外产出，下面正式开始
此前写过一篇关于AES加密的文章《Android加密算法之对称加密AES》，介绍了相关概念，使用以及脱坑姿势。
之所以写续篇，是因为最近项目中出现了AES加密的bug，折腾了许久最终确认为Android端错误地使用PKCS5Padding填充方式，而服务端则是PKCS7Padding，改为PKCS7Padding即可，还好bug只会出现在Android4.3和4.4的设备上，仅影响了极少数的用户。呵呵呵…
希望这篇文章没有被领导看到…看到也没事，反正又不是我弄的
嗯哼，求知欲强的童鞋可能会抛出以下问题：
- 为什么Android可以使用
PKCS7Padding？ - 为什么可以使用
PKCS5Padding来解密PKCS7Padding加密的数据？
接下来一一作答
Android可以使用PKCS7Padding
我们知道Java是不支持PKCS7Padding填充的，标准的方式是PKCS5Padding。而Android实现了Java SE API，但不使用相同的源代码，不使用相同的提供程序，也没有作实现AES限制。
这句话引自stackoverflow
Android implements the Java SE API, but does not use the same source code, not the same provider and the AES restrictions are not implemented either.
一句话概括下：Android没有使用标准Java的AES加密，而是自己实现了一套，顺便实现了PKCS7Padding。
可以使用PKCS5Padding来解密PKCS7Padding加密的数据
未完待续。。。