这里需要注意如下几点：
1.向量必须是一个与密钥长度相等的数据
2.由于在加密前和解密后都会做异或运算，因此我们的明文可以不用补全，不是16个字节的倍数也可以，CBC中会自动用0补全进行异或运算
3.在解密时是解密后才会再做异或运算，保证数据解密成功
4.由于自动进行了补全，所以解密出的数据也会在后面补全0，因此获取到数据时，需要将末尾的0去除，或者根据源数据长度来截取解密后的数据
优点：每次加密密钥不同，加强了安全性
CBC的方式解决了EBC的缺点，但是也有其缺点：
1.加密无法并行运算，但是解密可以并行，必须在前一个块加密完成后，才能加密后块，并且也需要填充0在后面，所以并不适合流数据（不适合的原因可能是，需要满足128位的数据之后才能进行加密，这样后面才不会有0的补全）
2.如果前一个数据加密错误，那么后续的数据都是错的了
3.两端需要同时约定初始向量iv
** CFB模式： 密码反馈模式 Cipher FeedBack
这个模式只使用了加密方法，原理是用到了一个数值异或运算之后再进行一次异或运算，值不改变的原理。并且在加密的时候，如果数据并不满足一个密钥的字节，那么只做保存，待满足一个密钥的字节后再进行加密 过程如下：
加密：
明文（260个字节） iv（128个字节）
明文1（128个字节） 明文2（128个字节） 明文3（4个字节）
（iv+key）异或 明文1 （密文1+key）异或 明文1 （密文1+key）异或明文3
密文1（128个字节） 密文2（128个字节） 密文3（4个字节）
解密：
密文（260个字节） iv（128个字节）密钥（128字节）
密文1（128个字节） 密文2（128个字节） 密文3（4个字节）
（iv+key）异或密文1 （密文1+key）异或密文2 （密文1+key）异或密文3
明文1 （128个字节） 明文2 （128个字节） 明文3（4个字节）
这里需要注意如下几点：
1.加解密时会返回一个num，这个num表示还需要几个数字，才会使用上一个密文加密，否则一直使用上上一个
2.加解密时也需要传入字符串的长度
3.由于解密时使用的都是密文来进行解密，并没有使用上一次解密的明文，因此解密也可以并行
4.由于CFB模式并不需要补全，或者一个完整的128字节才能加解密，综合第三点，所以适合流数据的传输。
5.CFB模式不止有CFB128（即与密钥长度一致），还有CFB1 和CFB8 即加解密1或8位后，再调用一次加密器生成新的值，这样可以使加密更安全，但是就会处理更多的运算，CFB1的运算时间是CFB8的八倍 CFB128的128倍
6.使用CFB128或者CFB8的时候传入的length单位是字节，CFB1是length的单位是位。
7.使用CFB1和CFB8的时候，num值会始终为0
优点:解密可同步，可以传入非16字节倍数的数据，适合流数据
CFB模式当然也有一个缺点，解密的时候可以并行解密，但是加密的时候并不可以并行加密。并且也需要选择iv
** OFB模式： 输出反馈模式 Output FeedBack
该模式与CFB类似，但是是将iv或者上一个iv加密后的数据加密，生成的key与明文做异或运算，解密时采用的是同样的方法，利用了异或运算的对称性来进行加解密，除了这一点，其余与CFB一致
加密/解密：
CFB:
（iv+key）异或 明文1 （密文1+key）异或 明文1 （密文1+key）异或明文3
OFB
（iv+key)异或明文1 （（iv+key）+key)异或明文1 （（（iv+key）+key）+key）异或明文3
优点：与CFB一样，方便传输流数据
缺点：由于依赖上一次的加密结果，所以并不能并行处理，特性是解密步骤完全一致，因此使用方法上不会有区别。
** CTR模式： 计算器模式 Counter
OFB不能并行的原因就在于需要上一次的iv进行加密后的结果，因此在CTR中我们将（iv+key）+key替换成了（iv+1）+key,这样我们就不需要依赖上一次的加密结果了。对比如下:
OFB
（iv+key)异或明文1 （（iv+key）+key)异或明文1 （（（iv+key）+key）+key）异或明文3
CTR
（iv+key)异或明文1 （（iv+1）+key)异或明文1 （（（iv+1）+1）+key）异或明文3
优点：由于加解密可以并行，因此CTR模式的加解密速度也很快
缺点：iv+1的获取比较负责，需要获取瞬时iv
三、提供两个示例 1、java mysql 通用aes加密算法通用的aes加密，使用场景，插入数据时，使用java进行加密数据，查询时，通过sql进行解密，不用取出再遍历解密
注：to_base64只适用mysql5.6之后的，之前的没有这个函数，不适用，可以使用HEX，UNHEX ，当然java要用对应的方法解密