坑一： AES+base64加密后的长度

AES算法加密后的长度应当是：不小于原始长度的16的最小倍数。例如：

15字节加密后变成16字节

16字节加密后变成32字节 这是第一个坑

后面base64编码后的长度即变成4/3倍。

坑二：数据库的编码对varchar类型的影响

varchar(n) 这个类型其实是指能容纳 n个字符，即如果数据库的编码是utf8，即每个字符可能占3个字节，那么在极限情况下，有可能 3*n 个字节。

然而经过base64以后，这些字节都将对应于一个字符。因此，在n不是16整数倍的情况下，加密以后varchar的长度应当变为4*n （如果n是16整数倍，则存在->坑一）

即无法使用 like 语法，必须完全匹配。

目前没有一个好的解决方案，针对数量级特别小的加密表，忽略模糊匹配的字段查询，解密后再过滤也可以；量级稍大一点点并且不需要频繁修改的，将明文结果缓存也可以。

MySql的字符串匹配默认是大小写不敏感的，也就是说之前系统里能匹配到的加密后就无法匹配了。

这里还涉及到统一认证系统URS的一个问题，该系统返回给我们的账户名有时大写有时小写。。

这是MySql的一个特性，sqlite则默认大小写敏感。

坑五： MyBatis缓存

由于MyBatis的缓存，在dao操作里对select出来的对象直接解密，可能会对下一次同一个dao操作有影响。详见：mybatis 的缓存坑

看到这里的小伙伴，如果你喜欢这篇文章的话，别忘了转发、收藏、留言互动！

最近我新整理了一些Java资料，包含个人精选的Java架构学习视频、大厂实战知识点、大厂内部面试题，如果你需要的话，欢迎私信我！

如果对文章有任何问题，欢迎在留言区和我交流~