哎，朋友们，今天咱们不聊风花雪月，也不谈星辰大海，就唠唠我这两天差点被逼疯的AES加密器中文乱码问题！说真的，这玩意儿比甲方改需求还让人头大，我差点把键盘给砸了！（最后没舍得，毕竟换轴也要钱啊！）
事情是这样的，前阵子我负责一个小项目，需要把用户输入的敏感信息（比如手机号、身份证号）在前端用JS加密，然后传到后端用Java解密，听起来很简单对吧？我也以为很简单，结果加密出来的字符串，在后台一解密，明文字段居然是一堆“锟斤拷”和“烫烫烫”！我当时心情就是：？？？我写的是宇宙级Bug吗？还是这加密器跟我有仇？
后来我冷静下来，喝了口保温杯里的枸杞茶，仔细排查了一遍，嘿，你猜怎么着？问题就出在这个万恶的字符编码上！AES加密器在处理的时候，默认用的是UTF-8，但我前端页面是GBK传来的中文，这不就相当于你拿一把英制扳手去拧公制螺丝——对不上号嘛！中文乱码立马就现出原形了。
我跟你说，为了解决这个AES加密器中文乱码，我可是把Stack Overflow都快翻烂了，最后总结出几个血泪教训,你们可得记好了：
第一点，也是最关键的：编码统一！统一！再统一！ 就像谈恋爱，三观必须一致！加密前，一定要把字符串转成UTF-8的字节数组，具体操作就是用encodeURIComponent把含中文的字符串先转为百分号编码，让那帮老外写的库也能“看”懂中文，然后再去AES加密，解密后，再用decodeURIComponent反转回来，就这么个简单的操作，直接把我从“乱码地狱”里捞了出来！真的，那一刻我差点热泪盈眶,感觉整个世界都清新了！
第二点，千万别用默认的AES模式，尤其是ECB！ 不是说不行，是太不安全了，而且如果数据量大了，容易泄密，咱就用CBC模式，还得配一个随机初始向量（IV），你想想，如果每次加密用的钥匙都一样，那跟把密码写在门上有什么区别？所以IV一定得随机，而且最好跟随密文一起传输，解密的时候再取出来用，这样即使别人截获了密文，没有IV他也白搭，中文乱码的概率也大大降低了（因为数据块对齐了，就不会出现那种残缺的�字符了）。
第三点，这块儿最容易偷懒犯错：密钥长度。 AES是支持128、192、256位密钥的，但好多小工具或者在线网站只给你默认128位，如果你后端用256位解，前端用128位加，那出来的结果……嘿嘿，我保证你连“�”字都能看吐，必须要两边完全一致，缺一不可,否则就是个死循环。
哎，其实事后想想，这个AES加密器中文乱码的问题，说白了就是个“沟通”问题，你让一个不懂中文的老外（AES算法）去处理中文，中间得有个“翻译官”（编码转换），只要把“翻译官”请到位了，那妥妥的没问题，现在我的程序跑得飞起，中文显示得明明白白,清爽得很！
写下这篇文章，就是希望跟我在同样坑里挣扎过的朋友们提个醒，搞技术这条路啊，真的是“坑坑更健康”，但遇到问题别慌，咱们拍拍屁股爬起来，把编码捋顺了，把逻辑理清了，基本上都能解决，以后咱们再遇到这捣蛋的AES加密器，就能心平气和地跟它说：“小样儿，还治不了你了？”
行啦，今天就啰嗦到这儿,我得去喝口茶润润嗓子了。
学习网络安全可以加QQ：3382688692（备注“博客学习”哦）
