MySQL 的 utf8 字符集的问题

理论上说起来，设置为 utf8 也并非一个完全合适、100% 没毛病的值，即便你将 MySQL 的字符集设置为 utf8 ，也有可能出现乱码！

通过以下命令，你可以查看 MySQL 所支持的所有『字符集』编码：

在显示的 Charset ，你会看见熟悉的 utf8 。

如果你再仔细看一下这一行，你会发现这一行的 Maxlen 列中的值居然是 3 ！？

这是 MySQL 中的 utf8 并非我们现在常说的 『真·UTF8』 。它『 最多 』只用 3 个字节存储一个字符，而有些中日韩生僻字<small>（包括 emoji 表情）</small>的 Unicode 编码是需要 4 个字节宽度才能存储的，这就会导致一些乱码的隐患。

MySQL 解决这个问题的方案是绕过 utf8 提出一种新的字符集来实现 『 真·UTF8 』 功能： utf8mb4 。

实际上，为了统一称呼，MySQL 在提出 utf8mb4 字符集之后，就将 utf8 改为 utf8mb3 的别名，因此，你设置字符集为 utf8 本质上就是设置成了 utf8mb3 。

在更高版本（8.x）的 mysql 中，MySQL 直接将 utf8 改为了 utfmb4 的别名。

MySQL字符集设置

• 系统变量：

– character_set_server：默认的内部 *** 作字符集

– character_set_client：客户端来源数据使用的字符集

– character_set_connection：连接层字符集

– character_set_results：查询结果字符集

– character_set_database：当前选中数据库的默认字符集

– character_set_system：系统元数据(字段名等)字符集

– 还有以collation_开头的同上面对应的变量，用来描述字符序。

• 用introducer指定文本字符串的字符集：

– 格式为：[_charset] ’string’ [COLLATE collation]

– 例如：

SELECT _latin1 ’string’

SELECT _utf8 ‘你好’ COLLATE utf8_general_ci

– 由introducer修饰的文本字符串在请求过程中不经过多余的转码，直接转换为内部字符集处理。

MySQL中的字符集转换过程

1. MySQL Server收到请求时将请求数据从character_set_client转换为character_set_connection；

2. 进行内部 *** 作前将请求数据从character_set_connection转换为内部 *** 作字符集，其确定方法如下：

- 使用每个数据字段的CHARACTER SET设定值；

- 若上述值不存在，则使用对应数据表的DEFAULT CHARACTER SET设定值(MySQL扩展，非SQL标准)；

- 若上述值不存在，则使用对应数据库的DEFAULT CHARACTER SET设定值；

- 若上述值不存在，则使用character_set_server设定值。

跟mysql字符集有关的有：

1. 数据库的的字符集

2. 文本字段( varchar , text ,char ) 的字符集

你指的是哪个呢？

以下例子以utf8为字符集（注意是utf8 不是 utf-8 )

建库时指定字符集： create database XXXX charset utf8

一旦在建库时指定了字符集，在建表时就可以不用指定字符集了，它会默认继承数据库的字符集。

如果建表时还想指定字符集：create table XXXX ( xxxxxxx ) type=MyISAM default charset utf8

或

create table XXXX ( aa varchar(8) charset utf8, bb char(4) charset utf8) type=MyISAM default charset utf8

一旦设置了utf8为字符集，在读取时，特别是用作网页作为输出 和 从网页接受数据时，要注意：

1. 请将网页的编码设置为 utf-8 (请注意是 utf-8 不是 utf8 )

2. 在进行 数据库 *** 作 之前请先执行一下SQL： set names utf8 ， 然后再执行其它SQL语句

上面的思想是：请尽量保持所有的 *** 作都用同一种编码。

---