前言：本文章为解决在mysql中使用AES_ENCRYPT、AES_DECRYPT解密时的中文乱码问题。一定注意：数据库端一切正常，在java代码和页面显示中变为问号“�”乱码！（不是数据库乱码！！！）
之前做了一个人信息存储的网站，主要是用于存放个人的一些账号信息（比如游戏账号），所有字符集（数据库和java和页面）都已经设置为UTF-8。mysql5.1.49数据库部分存放的诸如账号、密码之类的数据都是明文存放的（只有自己访问，一开始觉得没什么）。后来看到些文章说mysql5.1有漏洞，容易被人攻破从而看到里面的数据。所以想到使用加密的方式存放数据！
然后经过查找资料，最终决定使用mysql中自带的加密、解密函数来将原始数据加密后存入，取出时解密后再把数据拿到后端（Java代码）中进行使用。好处是加解密都在数据库端完成，不影响代码逻辑；坏处是这样做可能会加重数据库的压力。
使用的加密算法为（加密的算子文章中为abc123，实际我的不是这个，为了个人安全嘛~~~并不影响文章阅读啊）：
insert into USER_INFO values(HEX(AES_ENCRYPT('中文账号', 'abc123')), HEX(AES_ENCRYPT('中文密码', 'abc123')));
解密算法为：
select AES_DECRYPT(UNHEX(USER_NAME),'abc123') as 'USER_NAME' from USER_INFO;
加解密后再转变为16进制的原因，和加解密本身函数的使用，请参见其他作者的文章：
再之后，发现数据库执行上述的语句，在navicat中加解密正常，比如：“中文账号”四个汉字加密为：A560B16DC95484329CD82412347B9A72
它解密后在navicat中也正常显示为：“中文账号”。
到此为止，数据库端一切正常！
/************************************分割线****************************************/
但是！
所有信息一旦在页面上展示，中文部分都会变成问号乱码！
然后写了个单元测试，直接在Dao层获取到User对象后，直接控制台输出对象的账号、密码属性，也都是问号乱码！
������������������������
此时的我是无助的、想哭的、懵逼的！
然后我继续查找资料，一无所获，因为：网上都是说数据库端中文乱码问题的，压根没有我这种数据库正常，页面乱码的！
Holly Shit！我自己研究！
然后仔细排查思路：sql中加解密都正常，能正确解密出“中文账号”四个字的中文。那就应该不是单纯的数据库问题了，所以我在java测试代码中，将“中文账号”四个中文的字符串打散成单个字节16进制输出：
e4b8ade69687e8b4a6e58fb7
按UTF-8标准，一个汉字占3个字节，所以上面“中文账号”一共占12个字节。
再将来自数据库的USER_NAME字段数据打散成单个字节，16进制输出：
efbfbdefbfbdefbfbdefbfbdefbfbdefbfbdefbfbdefbfbdefbfbdefbfbdefbfbdefbfbd
在UTF-8规范中，0xefbfbd为所谓的“占位符”，在转码过程中遇到无法转换为UTF-8的字符时，用它来占位代替！
所以首先想到的还是：“是不是某个环节底层还是把中文转换为了非 UTF-8字符集，而导致转换失败”。
然后，搜索mysql相关乱码问题，发现一个大坑！mysql5.3以前老版本，内置的utf8字符是“假的”，不能完全兼容真正的UTF-8编码！！！
解决方案是安装新版mysql数据库，将字符集设置为：“utf8mb4”！我最后安装的是5.7.23，按照下面教程设置了utf8mb4字符集：
安装设置完毕后，怀着忐忑的心运行代码，玛德不是问号了，变成了其他乱码：
“中文账号”四个汉字变为：
ä¸æè´¦å·
………………我忍，我不哭，我不闹。。。
继续排查………………
我觉得至少这组乱码看起来是有意义的，比问号友好很多的！（捂脸哭）
继续用之前的思路，打散成字节16进制输出！
c3a4c2b8c2adc3a6c296c287c3a8c2b4c2a6c3a5c28fc2b7
变成了24个字节！再仔细观察：
正确的16进制：e4b8ade69687e8b4a6e58fb7
变成了：c3a4c2b8c2adc3a6c296c287c3a8c2b4c2a6c3a5c28fc2b7
看出来了吗，正确的数据（基本正确吧。。。）每个字节前面都加了个c3或者c2！
继续分析：“中文账号”4个汉字，编码成UTF-8的12个字节，然后每个字节又被加了个前缀。按我多年的经验，觉得应当是“mysql将结果通过网络发给后端java代码时，代码中错误的认为这组12个字节数据不是正确的转换后的数据，因此再次尝试了utf-8转码！”
换句话说，就是java代码这边接收到这组数据时，认为是12个字节的字符，但不认为是一个整体，所以继续自动按照utf-8的规则把12个字节转换成了24个字节！
所以按此种思路，大体解决方案就是“让java认为这12个字节已经是最终utf-8字符串，无需再处理一遍”！
经过查阅，最终解决方案是：在原有解密出的结果sql语句基础上，再套一层方法，让结果“成为一个整体”！
select CAST(AES_DECRYPT(UNHEX(USER_NAME),'abc123') as char) as 'USER_NAME' from USER_INFO;
上面sql中红色部分，就是使用cast方法，把结果“强行转换为字符串类型”！
最终，打印发现控制台输出正常！页面显示也正常了！
结论：老外对于中文的处理，永远都有坑。只有你想不到，没有不可能！
/********************************分割线***************************************/
最后总结下解决的总体步骤：
一、安装新版mysql（至少5.5以上），将数据库端字符集设置为“utf8mb4”！
二、在查询出的解密字段结果之上，再套一层cast()，让它“成为一个整体”！
