项目因为历史原因使用了 GBK编码，遇到非GBK编码字符时出现乱码问题，情况比较严重，暂时先打算修改 列的字符编码为 utf8mb4.
查看 mysql 手册：
用 GBK 编码转 utf8 进行说明：
他的大概意思是，如果 是 char varchar text 等类型的，并且这些列的内容也是采用的正确的编码(GBK)，也就是列的内容的编码和列的定义中指定的编码一致时，可以直接使用类似下面的语句进行处理：
ALTER TABLE t MODIFY COLUMN col_name varchar(60) CHARACTER SET utf8mb4;
如果 列的内容和列定义中指定的编码不一致时，需要先 转成 binary, 在转出自己想要的字符集 utf8mb4.
但是实际测试发现，这里表达有误。如果按照他这个说明进行转的话，100%会乱码！ 这里的: with the desird character set 应该改成：with the right charcter set, then to the desired character set.
如果列的内容和列定义中指定的编码不一致时，需要先转出 binary, 再转成 内容编码的那个编码字符集(the right charcter set) , 然后再转成 自己想要的 utf8mb4( the desired character set)。这样才不会乱码。
总结一下：
1）如果你能确保你 gbk 编码的列中的内容也是gkb编码格式存储的那么，转utf8mb4时，很简单，直接转就可以了：
alter table t modify column col varchar(60) character set utf8mb4;
2) 如果你不能确定 你 gbk 编码的列中的内容不是 gbk 编码格式存储的时，你需要先转成 binary, 再 转出 内容实际编码的字符集, 最后转出 utf8mb4:
alter table t modify column col binary;
alter table t modify column col varchar(60) character set 内容实际编码的字符集;
alter table t modify column col varchar(60) character set utf8mb4;
3) 不乱码还有一个前提，就是 子集转超集。比如 GBK 转 utf8. 也就是GBK 编码的字符，UTF8都可以编码。
如果是 utf8 转 GBK，那么那些 utf8可以编码的，GBK不能编码的字符就会乱码了，就会丢失内容。
