数据库utf8

1. 如何修改数据库的字符集utf8

在使用可视化操作界面时，修改数据库的字符集变得非常简单。例如，在使用Navicat for MySQL时，只需右键点击目标数据库，然后选择“数据库属性”选项。在弹出的窗口中，找到“字符集”一栏，将其设置为“utf8”或“utf8_unicode_ci”，这是最常用的排序规则。

如果你更倾向于通过命令行来操作，可以使用以下SQL语句来修改字符集。首先，你需要登录到MySQL服务器，然后执行以下命令：

ALTER DATABASE 数据库名 CHARACTER SET utf8 COLLATE utf8_unicode_ci;

这条命令会将指定的数据库的字符集和排序规则更改为utf8。

值得注意的是，在修改数据库字符集之前，最好先备份相关数据，以防万一出现意外情况。同时，确认你所使用的MySQL版本支持utf8字符集。一些较早的MySQL版本可能不支持。

此外，如果需要修改表的字符集，可以通过以下命令实现：

ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

这条命令会将指定表的字符集和排序规则更改为utf8。

在完成上述操作后，记得检查所有相关表和字段的字符集设置是否正确。确保所有数据都能正确显示和存储。

最后，建议定期检查数据库的字符集设置，确保其符合当前项目的需求。随着项目的扩展和数据的增长，字符集设置可能会变得不再合适，因此定期检查和调整是必要的。

在修改字符集的过程中，务必小心谨慎，以免影响数据库的正常运行。

2. 为什么不建议在 MySQL 中使用 UTF-8

MySQL中的UTF-8编码问题分析与解决方案

一、报错回顾

在尝试将包含emoji文字直接写入SQL中时，执行INSERT语句后，出现了错误提示：“Incorrect string value: 'xF0x9Fx98x93' for column 'NAME' at row 1”。这表明MySQL在处理包含emoji符号的字符串时遇到了问题。修改数据库编码、系统编码以及表字段的编码格式为utf8mb4后，问题得以解决。

二、MySQL中utf8的趣事

MySQL的“utf8”编码实际上与标准UTF-8并不完全相同。在MySQL中，“utf8”编码只支持每个字符最多三个字节，而标准UTF-8编码每个字符最多四个字节。中文在utf8中占用3个字节，其他数字、英文、符号占用1个字节。由于emoji符号和某些复杂文字在标准UTF-8中占用4个字节，而MySQL的“utf8”编码仅支持3个字节，因此直接插入会导致错误。

三、UTF-8编码选择与理解

在使用MySQL时，应当选择“utf8mb4”作为编码，以支持真正的UTF-8编码。MySQL的“utf8”编码被设计为一种“专属的编码”，其能够编码的Unicode字符数量有限，且在处理包含4字节字符的emoji时存在限制。因此，所有在使用“utf8”的MySQL和MariaDB用户都应该改用“utf8mb4”，以避免潜在的编码问题。

四、编码与Unicode字符集

理解编码与Unicode字符集对于正确使用MySQL至关重要。Unicode字符集包含上百万个字符，UTF-32是最简单且直接的编码方式，每个字符使用32位存储，但这可能导致空间浪费。相比之下，UTF-8编码可以节省空间，字符“C”只需要8位，而一些不常用的字符如“ ”则可能需要32位。使用UTF-8编码，一篇类似本文的文章，占用的空间仅为UTF-32的四分之一左右。

五、utf8编码的历史

MySQL从4.1版本开始支持UTF-8编码，当时使用的标准是旧版的RFC 2279，该标准最多支持每个字符6个字节。然而，在2002年，MySQL开发者将“utf8”编码的字符序列限制为最多3个字节。这一变更的原因尚不明确，但推测可能是为了在性能与空间效率之间做出权衡，以适应特定的用户需求。

六、总结

在当前网络上，几乎所有的文章都将MySQL的“utf8”编码当作真正的UTF-8，包括作者之前的文章和项目。为了帮助更多朋友了解这一关键信息，本文旨在强调在MySQL数据库中使用“utf8mb4”编码的重要性，以避免遇到编码相关的错误和问题。在搭建数据库时，记得将编码设置为“utf8mb4”，以确保能够正确处理包含emoji、复杂文字以及各种Unicode字符的数据。

3. UTF8与GBK数据库字符集

现有数据库A与数据库B，数据库A服务端由GBK编码，数据库B服务端由UTF8编码，需完成数据库A至数据库B的数据导入。测试中发现A库数据在插入B数据库时，部分数据查询时存在编码转换报错。影响字符编码的几个要素如下：

首先阐述影响字符编码的几个要素：Terminal-encoding、Client-encoding与Database-encoding。Terminal-encoding负责将一个字符串映射成字符编码，如'镓'在GBK解析为0xE689，在UTF8解析为0xE98EB5。Client-encoding是数据库识别编码格式的参考，数据库中二进制编码的原本格式由Client-encoding标识。Database-encoding是数据库服务器编码，对数据库B来说是UTF8模式，不支持GBK格式。数据库在处理非UTF8编码时，会转义成UTF8编码入库；读出时，如果client_encoding不是UTF8，会转义成其他二进制编码。

具体场景如下：

场景a：终端字符集为GBK，数据库client_encoding为GBK，database_encoding为UTF8。镓弿被还原出正确原编码，但因转义错误导致转义失败。

场景b：终端字符集为UTF8，数据库client_encoding为UTF8，database_encoding为UTF8。镓弿被正确还原并入库，按照UTF8读取可以得到原字符，但按照GBK读取时失败。

场景c：终端字符集为GBK，数据库client_encoding为UTF8，database_encoding为UTF8。镓弿被正确还原并入库，无论按照UTF8或GBK读取均可读出正确字符串。

问题原因在于A库中的GBK范围大于B库中设置的GBK，A库所谓“GBK”实际上为GB18030编码集。编码背景资料如下：

GB2312、GBK与GB18030是中国国家标准简体中文字符集，GB2312通行于中国大陆，GBK包含GB2312全部汉字、非汉字符号及BIG5全部汉字，GB18030包含所有汉字、部首、符号，且兼容GB2312及GBK，收录汉字70244个。

解决方法是在导入与导出数据时，如果A库为“GBK”或类“GBK”字符集传输或存储数据，B库需设置客户端字符集为“GB18030”。