坑一： AES+base64加密後的長度

AES算法加密後的長度應當是：不小於原始長度的16的最小倍數。例如：數據庫

後面base64編碼後的長度即變成4/3倍。緩存

坑二：數據庫的編碼對varchar類型的影響

varchar(n) 這個類型實際上是指能容納 n個字符，即若是數據庫的編碼是utf8，即每一個字符可能佔3個字節，那麼在極限狀況下，有可能 3*n 個字節。markdown

然而通過base64之後，這些字節都將對應於一個字符。所以，在n不是16整數倍的狀況下，加密之後varchar的長度應當變爲4*n （若是n是16整數倍，則存在->坑一）mybatis

即沒法使用 like 語法，必須徹底匹配。編碼

目前沒有一個好的解決方案，針對數量級特別小的加密表，忽略模糊匹配的字段查詢，解密後再過濾也能夠；量級稍大一點點而且不須要頻繁修改的，將明文結果緩存也能夠。加密

MySql的字符串匹配默認是大小寫不敏感的，也就是說以前系統裏能匹配到的加密後就沒法匹配了。spa

這裏還涉及到統一認證系統URS的一個問題，該系統返回給咱們的帳戶名有時大寫有時小寫。。code

這是MySql的一個特性，sqlite則默認大小寫敏感。

因爲MyBatis的緩存，在dao操做裏對select出來的對象直接解密，可能會對下一次同一個dao操做有影響。詳見：mybatis 的緩存坑

有任何問題歡迎留言交流~

看到這裏的小夥伴，若是你喜歡這篇文章的話，別忘了轉發、收藏、留言互動！

若是對文章有任何問題，歡迎在留言區和我交流~

最近我新整理了一些Java資料，包含面經分享、模擬試題、和視頻乾貨，若是你須要的話，歡迎留言or私信我！