我的halo是用mysql作为数据库搭建的，今天写了一篇netty的入门博客，死活保存失败，然后远程连接到服务器，发现有个字段报错了。为什么会报错呢？
Caused by: org.hibernate.exception.GenericJDBCException: could not execute statement
.......
**Caused by: java.sql.SQLException: Incorrect string value: 'xF0x9Fx88xB6xEFxB8...' for column 'post_summary' at row 1**
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:129)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
... 99 more这里，我截取了关键的异常堆栈信息，发现是字符串的错误，于是，百度了一下，找到了原因
MySQL简史
为什么MySQL开发者会让“utf8”失效？我们或许可以从提交日志中寻找答案。
MySQL从4.1版本开始支持UTF-8，也就是2003年，而今天使用的UTF-8标准（RFC 3629）是随后才出现的。
旧版的UTF-8标准（RFC 2279）最多支持每个字符6个字节。2002年3月28日，MySQL开发者在第一个MySQL 4.1预览版中使用了RFC 2279。
同年9月，他们对MySQL源代码进行了一次调整：“UTF8现在最多只支持3个字节的序列”。
是谁提交了这些代码？他为什么要这样做？这个问题不得而知。在迁移到Git后（MySQL最开始使用的是BitKeeper），MySQL代码库中的很多提交者的名字都丢失了。2003年9月的邮件列表中也找不到可以解释这一变更的线索。
不过我可以试着猜测一下。
2002年，MySQL做出了一个决定：如果用户可以保证数据表的每一行都使用相同的字节数，那么MySQL就可以在性能方面来一个大提升。为此，用户需要将文本列定义为“CHAR”，每个“CHAR”列总是拥有相同数量的字符。如果插入的字符少于定义的数量，MySQL就会在后面填充空格，如果插入的字符超过了定义的数量，后面超出部分会被截断。
MySQL开发者在最开始尝试UTF-8时使用了每个字符6个字节，CHAR(1)使用6个字节，CHAR(2)使用12个字节，并以此类推。
应该说，他们最初的行为才是正确的，可惜这一版本一直没有发布。但是文档上却这么写了，而且广为流传，所有了解UTF-8的人都认同文档里写的东西。
不过很显然，MySQL开发者或厂商担心会有用户做这两件事：
1.使用CHAR定义列（在现在看来，CHAR已经是老古董了，但在那时，在MySQL中使用CHAR会更快，不过从2005年以后就不是这样子了）。 2.将CHAR列的编码设置为“utf8”。 我的猜测是MySQL开发者本来想帮助那些希望在空间和速度上双赢的用户，但他们搞砸了“utf8”编码。
所以结果就是没有赢家。那些希望在空间和速度上双赢的用户，当他们在使用“utf8”的CHAR列时，实际上使用的空间比预期的更大，速度也比预期的慢。而想要正确性的用户，当他们使用“utf8”编码时，却无法保存像“”这样的字符。
在这个不合法的字符集发布了之后，MySQL就无法修复它，因为这样需要要求所有用户重新构建他们的数据库。最终，MySQL在2010年重新发布了“utf8mb4”来支持真正的UTF-8。
修改如下：
修改数据库报错字段的字符集，完美解决
参考地址：修改utf8mb4
