2021-11-09 18:47:58 +08:00
---
2022-11-05 18:24:11 +08:00
title: 字符集详解
2026-01-16 21:04:11 +08:00
description: 详解字符集与字符编码原理， ，
2021-11-09 18:47:58 +08:00
category: 数据库
tag:
- 数据库基础
2025-11-17 11:52:20 +08:00
head:
- - meta
- name: keywords
2026-01-16 20:09:23 +08:00
content: 字符集,字符编码,UTF-8,UTF-16,GBK,GB2312,utf8mb4,ASCII,Unicode,MySQL字符集,emoji存储
2021-11-09 18:47:58 +08:00
---
2021-10-13 19:46:50 +08:00
MySQL 字符编码集中有两套 UTF-8 编码实现：**`utf8` ** 和 * * `utf8mb4` **。
2023-04-28 17:12:53 +08:00
如果使用 * * `utf8` ** 的话，存储 emoji 符号和一些比较复杂的汉字、繁体字就会出错。
2021-10-13 19:46:50 +08:00
为什么会这样呢？这篇文章可以从源头给你解答。
2024-01-08 23:00:42 +08:00
## 字符集是什么？
2021-10-13 19:46:50 +08:00
字符是各种文字和符号的统称，包括各个国家文字、标点符号、表情、数字等等。 **字符集 ** 就是一系列字符的集合。字符集的种类较多，每个字符集可以表示的字符范围通常不同，就比如说有些字符集是无法表示汉字的。
**计算机只能存储二进制的数据，那英文、汉字、表情等字符应该如何存储呢？ **
2022-04-07 14:25:36 +08:00
我们要将这些字符和二进制的数据一一对应起来， ， ，
2021-10-13 19:46:50 +08:00
2024-01-08 23:00:42 +08:00
## 字符编码是什么？
字符编码是一种将字符集中的字符与计算机中的二进制数据相互转换的方法，可以看作是一种映射规则。也就是说，字符编码的目的是为了让计算机能够存储和传输各种文字信息。
每种字符集都有自己的字符编码规则，常用的字符集编码规则有 ASCII 编码、 GB2312 编码、GBK 编码、GB18030 编码、Big5 编码、UTF-8 编码、UTF-16 编码等。
2021-10-13 19:46:50 +08:00
## 有哪些常见的字符集？
2024-01-08 23:00:42 +08:00
常见的字符集有：
2021-10-13 19:46:50 +08:00
不同的字符集的主要区别在于：
- 可以表示的字符范围
- 编码方式
### ASCII
**ASCII ** (**A**merican **S**tandard **C**ode for **I**nformation **I**nterchange，
**为什么 ASCII 字符集没有考虑到中文等其他字符呢？ ** 因为计算机是美国人发明的，当时，计算机的发展还处于比较雏形的时代，还未在其他国家大规模使用。因此，美国发布 ASCII 字符集的时候没有考虑兼容其他国家的语言。
ASCII 字符集至今为止共定义了 128 个字符，其中有 33 个控制字符（比如回车、删除）无法显示。
一个 ASCII 码长度是一个字节也就是 8 个 bit， ， ， ， （ ）
由于， **ASCII 扩展字符集 ** 。ASCII 扩展字符集使用 8 位（ ） ， ， （ ）
2023-03-10 11:52:00 +08:00
2021-10-13 19:46:50 +08:00
### GB2312
我们上面说了，
GB2312 字符集是一种对汉字比较友好的字符集，共收录 6700 多个汉字， ，
对于英语字符， ，
### GBK
GBK 字符集可以看作是 GB2312 字符集的扩展，兼容 GB2312 字符集，共收录了 20000 多个汉字。
GBK 中 K 是汉语拼音 Kuo Zhan（ ）
### GB18030
GB18030 完全兼容 GB2312 和 GBK 字符集，纳入中国国内少数民族的文字，且收录了日韩汉字，是目前为止最全面的汉字字符集，共收录汉字 70000 多个。
### BIG5
BIG5 主要针对的是繁体中文，收录了 13000 多个汉字。
2024-01-08 23:00:42 +08:00
### Unicode & UTF-8
2021-10-13 19:46:50 +08:00
为了更加适合本国语言，诞生了很多种字符集。
我们上面也说了不同的字符集可以表示的字符范围以及编码规则存在差异。这就导致了一个非常严重的问题：**使用错误的编码方式查看一个包含字符的文件就会产生乱码现象。**
就比如说你使用 UTF-8 编码方式打开 GB2312 编码格式的文件就会出现乱码。示例：“牛”这个汉字 GB2312 编码后的十六进制数值为 “C5A3”，
2023-04-28 17:12:53 +08:00
你可以通过这个网站在线进行编码和解码：<https://www.haomeili.net/HanZi/ZiFuBianMaZhuanHuan>
2021-10-13 19:46:50 +08:00
2023-03-10 11:52:00 +08:00
2021-10-13 19:46:50 +08:00
2023-05-05 12:33:52 +08:00
这样我们就搞懂了乱码的本质：**编码和解码时用了不同或者不兼容的字符集** 。
2021-10-13 19:46:50 +08:00
2023-03-10 11:52:00 +08:00
2021-10-13 19:46:50 +08:00
为了解决这个问题，人们就想：“如果我们能够有一种字符集将世界上所有的字符都纳入其中就好了！”。
然后，**Unicode** 带着这个使命诞生了。
2021-10-14 11:27:39 +08:00
Unicode 字符集中包含了世界上几乎所有已知的字符。不过，
2021-10-13 19:46:50 +08:00
然后，就有了 **UTF-8 ** （ ）
UTF-8 使用 1 到 4 个字节为每个字符编码， UTF-16 使用 2 或 4 个字节为每个字符编码，
UTF-8 可以根据不同的符号自动选择编码的长短，像英文字符只需要 1 个字节就够了，这一点 ASCII 字符集一样 。因此， ，
UTF-32 的规则最简单，不过缺陷也比较明显，对于英文字母这类字符消耗的空间是 UTF-8 的 4 倍之多。
2023-07-02 18:59:39 +08:00
**UTF-8 ** 是目前使用最广的一种字符编码。
2021-10-13 19:46:50 +08:00
2023-03-10 11:52:00 +08:00
2021-10-13 19:46:50 +08:00
## MySQL 字符集
2024-01-08 23:00:42 +08:00
MySQL 支持很多种字符集的方式，比如 GB2312、GBK、BIG5、多种 Unicode 字符集（
2021-10-13 19:46:50 +08:00
2023-07-07 10:45:49 +08:00
### 查看支持的字符集
2023-07-07 18:49:53 +08:00
你可以通过 `SHOW CHARSET` 命令来查看，支持 like 和 where 子句。
2021-10-13 19:46:50 +08:00
2023-03-10 11:52:00 +08:00
2021-10-13 19:46:50 +08:00
2023-07-07 10:45:49 +08:00
### 默认字符集
2023-07-07 18:49:53 +08:00
在 MySQL5.7 中，默认字符集是 `latin1` ；在 MySQL8.0 中，默认字符集是 `utf8mb4`
2023-07-07 10:45:49 +08:00
### 字符集的层次级别
2023-07-07 18:49:53 +08:00
MySQL 中的字符集有以下的层次级别：
2023-07-07 10:45:49 +08:00
2023-07-07 18:49:53 +08:00
- `server` （
- `database` （库级别）
- `table` （表级别）
- `column` （字段级别）
2023-07-07 10:45:49 +08:00
2023-07-07 18:49:53 +08:00
它们的优先级可以简单的认为是从上往下依次增大，也即 `column` 的优先级会大于 `table` 等其余层次的。如指定 MySQL 实例级别字符集是`utf8mb4` ，指定某个表字符集是`latin1` ，那么这个表的所有字段如果不指定的话，编码就是`latin1` 。
2023-07-07 10:45:49 +08:00
#### server
2023-07-07 18:49:53 +08:00
不同版本的 MySQL 其 `server` 级别的字符集默认值不同，在 MySQL5.7 中，其默认值是 `latin1` ；在 MySQL8.0 中，其默认值是 `utf8mb4` 。
2023-07-07 10:45:49 +08:00
2023-07-07 18:49:53 +08:00
当然也可以通过在启动 `mysqld` 时指定 `--character-set-server` 来设置 `server` 级别的字符集。
``` bash
mysqld
mysqld --character-set-server= utf8mb4
mysqld --character-set-server= utf8mb4 \
--collation-server= utf8mb4_0900_ai_ci
```
或者如果你是通过源码构建的方式启动的 MySQL， `cmake` 命令中指定选项：
2023-07-07 10:45:49 +08:00
``` sh
cmake . -DDEFAULT_CHARSET= latin1
2023-07-07 18:49:53 +08:00
或者
cmake . -DDEFAULT_CHARSET= latin1 \
-DDEFAULT_COLLATION= latin1_german1_ci
2023-07-07 10:45:49 +08:00
```
2023-07-07 18:49:53 +08:00
此外，你也可以在运行时改变 `character_set_server` 的值，从而达到修改 `server` 级别的字符集的目的。
2023-07-07 10:45:49 +08:00
2023-07-07 18:49:53 +08:00
`server` 级别的字符集是 MySQL 服务器的全局设置，它不仅会作为创建或修改数据库时的默认字符集（如果没有指定其他字符集），还会影响到客户端和服务器之间的连接字符集，具体可以查看 [MySQL Connector/J 8.0 - 6.7 Using Character Sets and Unicode ](https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-charsets.html )。
2023-07-07 10:45:49 +08:00
#### database
`database` 级别的字符集是我们在创建数据库和修改数据库时指定的：
``` sql
CREATE DATABASE db_name
[ [ DEFAULT ] CHARACTER SET charset_name ]
[ [ DEFAULT ] COLLATE collation_name ]
ALTER DATABASE db_name
[ [ DEFAULT ] CHARACTER SET charset_name ]
[ [ DEFAULT ] COLLATE collation_name ]
```
2023-07-07 18:49:53 +08:00
如前面所说，如果在执行上述语句时未指定字符集，那么 MySQL 将会使用 `server` 级别的字符集。
2023-07-07 10:45:49 +08:00
可以通过下面的方式查看某个数据库的字符集：
``` sql
USE db_name ;
SELECT @ @ character_set_database , @ @ collation_database ;
```
``` sql
SELECT DEFAULT_CHARACTER_SET_NAME , DEFAULT_COLLATION_NAME
FROM INFORMATION_SCHEMA . SCHEMATA WHERE SCHEMA_NAME = ' db_name ' ;
```
#### table
`table` 级别的字符集是在创建表和修改表时指定的：
``` sql
CREATE TABLE tbl_name ( column_list )
[ [ DEFAULT ] CHARACTER SET charset_name ]
[ COLLATE collation_name ] ]
ALTER TABLE tbl_name
[ [ DEFAULT ] CHARACTER SET charset_name ]
[ COLLATE collation_name ]
```
2023-07-07 18:49:53 +08:00
如果在创建表和修改表时未指定字符集，那么将会使用 `database` 级别的字符集。
2023-07-07 10:45:49 +08:00
#### column
`column` 级别的字符集同样是在创建表和修改表时指定的，只不过它是定义在列中。下面是个例子：
``` sql
CREATE TABLE t1
(
col1 VARCHAR ( 5 )
CHARACTER SET latin1
COLLATE latin1_german1_ci
) ;
```
2023-07-07 18:49:53 +08:00
如果未指定列级别的字符集，那么将会使用表级别的字符集。
2023-07-07 10:45:49 +08:00
### 连接字符集
2023-07-07 18:49:53 +08:00
前面说到了字符集的层次级别，它们是和存储相关的。而连接字符集涉及的是和 MySQL 服务器的通信。
2023-07-07 10:45:49 +08:00
连接字符集与下面这几个变量息息相关：
2023-07-07 18:49:53 +08:00
- `character_set_client` ：描述了客户端发送给服务器的 SQL 语句使用的是什么字符集。
- `character_set_connection` ：描述了服务器接收到 SQL 语句时使用什么字符集进行翻译。
- `character_set_results` ：描述了服务器返回给客户端的结果使用的是什么字符集。
2023-07-07 10:45:49 +08:00
2023-07-07 18:49:53 +08:00
它们的值可以通过下面的 SQL 语句查询：
2023-07-07 10:45:49 +08:00
``` sql
SELECT * FROM performance_schema . session_variables
WHERE VARIABLE_NAME IN (
' character_set_client ' , ' character_set_connection ' ,
' character_set_results ' , ' collation_connection '
) ORDER BY VARIABLE_NAME ;
```
``` sql
SHOW SESSION VARIABLES LIKE ' character\_set\_% ' ;
```
如果要想修改前面提到的几个变量的值，有以下方式：
2023-07-07 18:49:53 +08:00
1、修改配置文件
2023-07-07 10:45:49 +08:00
2023-07-07 18:49:53 +08:00
``` properties
2023-07-07 10:45:49 +08:00
[ m y s q l ]
# 只针对MySQL客户端程序
default-character-set = utf8mb4
```
2023-07-07 18:49:53 +08:00
2、使用 SQL 语句
2023-07-07 10:45:49 +08:00
``` sql
set names utf8mb4
# 或 者 一 个 个 进 行 修 改
# SET character_set_client = utf8mb4 ;
# SET character_set_results = utf8mb4 ;
# SET collation_connection = utf8mb4 ;
```
2024-01-08 23:00:42 +08:00
### JDBC 对连接字符集的影响
2023-07-07 10:45:49 +08:00
2024-01-08 23:00:42 +08:00
不知道你们有没有碰到过存储 emoji 表情正常，但是使用类似 Navicat 之类的软件的进行查询的时候，发现 emoji 表情变成了问号的情况。这个问题很有可能就是 JDBC 驱动引起的。
2023-07-07 10:45:49 +08:00
2024-01-08 23:00:42 +08:00
根据前面的内容，我们知道连接字符集也是会影响我们存储的数据的，而 JDBC 驱动会影响连接字符集。
2023-07-07 10:45:49 +08:00
2024-01-08 23:00:42 +08:00
`mysql-connector-java` （
2023-07-07 10:45:49 +08:00
2023-07-07 10:59:19 +08:00
- `characterEncoding`
- `characterSetResults`
2023-07-07 18:49:53 +08:00
以 `DataGrip 2023.1.2` 来说，在它配置数据源的高级对话框中，可以看到 `characterSetResults` 的默认值是 `utf8` ，在使用 `mysql-connector-java 8.0.25` 时，连接字符集最后会被设置成 `utf8mb3` 。那么这种情况下 emoji 表情就会被显示为问号，并且当前版本驱动还不支持把 `characterSetResults` 设置为 `utf8mb4` ，不过换成 `mysql-connector-java driver 8.0.29` 却是允许的。
2023-07-07 10:59:19 +08:00
2023-07-07 18:49:53 +08:00
具体可以看一下 StackOverflow 的 [DataGrip MySQL stores emojis correctly but displays them as? ](https://stackoverflow.com/questions/54815419/datagrip-mysql-stores-emojis-correctly-but-displays-them-as )这个回答。
2023-07-07 10:45:49 +08:00
2023-07-07 18:49:53 +08:00
### UTF-8 使用
2023-07-07 10:45:49 +08:00
2021-10-13 19:46:50 +08:00
通常情况下，我们建议使用 UTF-8 作为默认的字符编码方式。
不过，这里有一个小坑。
MySQL 字符编码集中有两套 UTF-8 编码实现：
2023-05-05 12:39:01 +08:00
- **`utf8` **： `utf8` 编码只支持`1-3` 个字节 。 在 `utf8` 编码中，中文是占 3 个字节，其他数字、英文、符号占一个字节。但 emoji 符号占 4 个字节，一些较复杂的文字、繁体字也是 4 个字节。
- **`utf8mb4` **：
2021-10-13 19:46:50 +08:00
**为什么有两套 UTF-8 编码实现呢？ ** 原因如下：
2023-03-10 11:52:00 +08:00
2021-10-13 19:46:50 +08:00
因此，如果你需要存储`emoji` 类型的数据或者一些比较复杂的文字、繁体字到 MySQL 数据库的话，数据库的编码一定要指定为`utf8mb4` 而不是`utf8` ，要不然存储的时候就会报错了。
演示一下吧！ （ ： ）
建表语句如下，我们指定数据库 CHARSET 为 `utf8` 。
``` sql
CREATE TABLE ` user ` (
2023-07-07 10:45:49 +08:00
` id ` varchar ( 66 ) CHARACTER SET utf8mb3 NOT NULL ,
` name ` varchar ( 33 ) CHARACTER SET utf8mb3 NOT NULL ,
` phone ` varchar ( 33 ) CHARACTER SET utf8mb3 DEFAULT NULL ,
` password ` varchar ( 100 ) CHARACTER SET utf8mb3 DEFAULT NULL
2021-10-13 19:46:50 +08:00
) ENGINE = InnoDB DEFAULT CHARSET = utf8 ;
```
当我们执行下面的 insert 语句插入数据到数据库时，果然报错！
``` sql
INSERT INTO ` user ` ( ` id ` , ` name ` , ` phone ` , ` password ` )
VALUES
2023-04-28 17:12:53 +08:00
( ' A00003 ' , ' guide哥😘😘😘 ' , ' 181631312312 ' , ' 123456 ' ) ;
2021-10-13 19:46:50 +08:00
```
报错信息如下：
2023-10-10 14:43:53 +08:00
``` plain
2021-10-13 19:46:50 +08:00
Incorrect string value: '\xF0\x9F\x98\x98\xF0\x9F...' for column 'name' at row 1
```
## 参考
2023-05-05 12:33:52 +08:00
- 字符集和字符编码（ ） ：
2023-04-28 17:12:53 +08:00
- 十分钟搞清字符集和字符编码：<http://cenalulu.github.io/linux/character-encoding/>
- Unicode-维基百科：<https://zh.wikipedia.org/wiki/Unicode>
- GB2312-维基百科：<https://zh.wikipedia.org/wiki/GB_2312>
- UTF-8-维基百科：<https://zh.wikipedia.org/wiki/UTF-8>
- GB18030-维基百科: <https://zh.wikipedia.org/wiki/GB_18030>
2023-07-07 18:49:53 +08:00
- MySQL8 文档：<https://dev.mysql.com/doc/refman/8.0/en/charset.html>
- MySQL5.7 文档：<https://dev.mysql.com/doc/refman/5.7/en/charset.html>
- MySQL Connector/J 文档：<https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-charsets.html>
2023-08-07 18:56:33 +08:00
2023-10-27 06:44:02 +08:00
<!-- @include: @article -footer.snippet.md -->
