这个问题困扰着该站点的参与者以及其他许多人。
您列出了五个主要的
CHARACTER SET麻烦案例。
最佳实践
展望未来，最好使用
CHARACTER SET utf8mb4和
COLLATIONutf8mb4_unipre_520_ci。（管道中有更新版本的Unipre排序规则。）
utf8mb4是的超集
utf8，它处理4字节utf8代码，表情符号和某些中文需要这些代码。
在MySQL之外，“ UTF-8”是指所有大小的编码，因此实际上与MySQL相同
utf8mb4，而不是
utf8。
在下文中，我将尝试使用这些拼写和大写字母来区分MySQL内部和外部。
您 应 该做什么概述
- 将您的编辑器等设置为UTF-8。
- HTML表单应以开头
<form accept-charset="UTF-8">
。 - 将您的字节编码为UTF-8。
- 建立UTF-8作为客户端中使用的编码。
- 声明列/表
CHARACTER SET utf8mb4
（使用进行检查SHOW CREATE TABLE
。） <meta charset=UTF-8>
在HTML的开头- 存储的例程获取当前的字符集/排序规则。他们可能需要重建。
UTF-8贯穿始终
有关计算机语言的更多详细信息（及其后续部分）
测试数据
使用工具或工具查看数据
SELECt是不可信的。太多这样的客户端，尤其是浏览器，试图补偿不正确的编码，并向您显示正确的文本，即使数据库已损坏。因此，选择一个包含非英语文本的表和列，然后执行
SELECT col, HEx(col) FROM tbl WHERe ...
正确存储的UTF-8的十六进制将为
- 对于空格（任何语言）：
20
- 对于英语：
4x
，5x
，6x
，或者7x
- 在西欧大部分地区，带重音符号的字母应为
Cxyy
- 西里尔文，希伯来文和波斯文/阿拉伯文：
Dxyy
- 亚洲大部分地区：
Exyyzz
- 表情符号和一些中文：
F0yyzzww
- 更多细节
出现问题的具体原因和解决方法
截断的 文字（
Se为
Señor）：
- 要存储的字节未编码为utf8mb4。解决这个问题。
- 另外，在读取过程中检查连接是否为UTF-8。
黑钻石 与问号（
Se�or对
Señor）; 存在以下情况之一：
情况1（原始字节 不是 UTF-8）：
- 要存储的字节未编码为utf8。解决这个问题。
- 的连接（或
SET NAMES
为）INSERT
和 所述SELECT
不UTF8 / utf8mb4。解决这个问题。 - 另外，检查数据库中的列是否为
CHARACTER SET utf8
（或utf8mb4）。
情况2（原始字节 为 UTF-8）：
- 的连接（或
SET NAMES
）SELECT
不是utf8 / utf8mb4。解决这个问题。 - 另外，检查数据库中的列是否为
CHARACTER SET utf8
（或utf8mb4）。
仅当浏览器设置为时，才会出现黑色菱形
<meta charset=UTF-8>。
问号 （常规的，不是黑钻石）（
Se?or用于
Señor）：
- 要存储的字节未编码为utf8 / utf8mb4。解决这个问题。
- 数据库中的列不是
CHARACTER SET utf8
（或utf8mb4）。解决这个问题。（使用SHOW CREATE TABLE
。） - 另外，在读取过程中检查连接是否为UTF-8。
Mojibake （
Señorfor
Señor）：（此讨论也适用于 Double Encoding ，它不一定可见。）
- 要存储的字节需要UTF-8编码。解决这个问题。
- 当
INSERTing
和SELECTing
文本的连接需要指定utf8或utf8mb4。解决这个问题。 - 该列需要声明
CHARACTER SET utf8
（或utf8mb4）。解决这个问题。 - HTML应该以开头
<meta charset=UTF-8>
。
如果数据看起来正确，但排序不正确，则说明您选择了错误的排序规则，或者没有适合您的排序规则，或者您使用 Double Encoding 。
*通过执行SELECT .. HEX ..
上述操作，可以确认 *双重编码 。
é should come back C3A9, but instead shows C383C2A9The Emoji
