mysql中的utf8与utf8mb4存储及区别

目录
  • 一、如何设置utf8mb4
  • 二、问题
    • 1、为什么存储的时候要区分utf8和utf8mb4
    • 2、为什么读取的时候要区分utf8和utf8mb4

一、如何设置utf8mb4

mysql中针对字符串类型,在设置charset的时候可以精确到字段。

如果只将某个字段设置utf8mb4,那么其他字段不会受影响。

如果针对表来设置,那么已经存在的字段依然是utf8,并且会多出utf8的标记,之后所创建的字段才会是utf8mb4

如果针对库来设置,那么已经存在的表依然是utf8,之后所创建的表才会是utf8mb4

除此之外呢,我们在连接数据库的时候,也要指明charset=utf8mb4,否则的话,此连接无法向utf8mb4的字段写入数据,并且读取的时候是乱码。

在使用 navicat 的时候,发现没有地方设置连接的字符编码,他会自动扫面你的数据库,表,字段的编码,来自动设置一个合适的编码,当然,这也跟 navicat 版本有关,高版本才行,我的低版本就不行,如果你发现你的 navicat 无法显示表情,只能看到问好,那么可以通过show variables like '%char%'查看一下。

我还遇到一个情况,我的 navicat 没法自动设置 utf8mb4,因此,在 utf8 的情况下,我将线上的表情同步到了我本地,这使得我在后面即使设置了 utf8mb4 的情况下也看不到表情,这是因为我在 utf8 的时候同步过来的数据被破坏了,字符集不兼容,所以需要先设置好字符编码再拉取一次数据。

二、问题

1、为什么存储的时候要区分utf8和utf8mb4

按理说,不管我存进去的是单字节还是多字节,本质都是二进制,我写入什么你就存什么不就好了,干嘛还要有限制。这是因为,Mysql对每个字段都定义了长度,比如varchar(10)表示10个字符,而不是字节,所以当存入数据的时候,mysql是做了解析的,这样才能知道字符串里有几个字符;当面对4字节字符的时候,mysql依然会以3字节的编码规则来解析,显然会解析出错的,因此就不让写入。

MySQL在5.5.3之后增加了这个utf8mb4的编码,mb4就是most bytes 4的意思,专门用来兼容四字节的unicode。好在 utf8mb4 是 utf8 的超集,除了将编码改为 utf8mb4 外不需要做其他转换。当然,为了节省空间,一般情况下使用 utf8 也就够了。

utf8 是 Mysql 中的一种字符集,只支持最长三个字节的 UTF-8 字符,可能是因为 Mysql 刚开始开发那会,Unicode 还没有4字节的字符。至于后续的版本为什么不对 4 字节长度的 UTF-8 字符提供支持,应该是为了向后兼容性的考虑,还有就是4字节字符确实很少用到。

2、为什么读取的时候要区分utf8和utf8mb4

按理说,我读取的都是二进制,不管是三字节还是四字节,我自己来展示,为什么在读取 utf8mb4 字段的时候,我使用 utf8 的连接得到的是乱码,使用 utf8mb4 连接得到的是正常的。实际上我的电脑是能展示四字节字符的。

因为mysql有个连接器组件,它处于客户端和服务器之间,用于字符集的转换。

现在有一个字段name,为了兼容emoj表情,字段设置为utf8mb4,在写入的时候数据库连接设置了charset=utf8mb4,因此可以正常写入;在读取的时候数据库连接设置charset=utf8,于是读出来展示的时候是乱码,如果改成charset=utf8mb4,读出来就能正常展示,那就是说,utf8的连接读到的结果并不是真实的数据,而是经过了连接器的转换,它将utf8mb4转换成了utf8,四字节字符被转换成了三字节,自然就是乱码。

那么,为什么要有这个转码的过程呢?

那是因为mysql支持很多的字符编码。

mysql> show character set;
+----------+-----------------------------+---------------------+--------+
| Charset  | Description                 | Default collation   | Maxlen |
+----------+-----------------------------+---------------------+--------+
| big5     | Big5 Traditional Chinese    | big5_chinese_ci     |      2 |
| dec8     | DEC West European           | dec8_swedish_ci     |      1 |
| cp850    | DOS West European           | cp850_general_ci    |      1 |
| hp8      | HP West European            | hp8_english_ci      |      1 |
| koi8r    | KOI8-R Relcom Russian       | koi8r_general_ci    |      1 |
| latin1   | cp1252 West European        | latin1_swedish_ci   |      1 |
| latin2   | ISO 8859-2 Central European | latin2_general_ci   |      1 |
| swe7     | 7bit Swedish                | swe7_swedish_ci     |      1 |
| ascii    | US ASCII                    | ascii_general_ci    |      1 |
| ujis     | EUC-JP Japanese             | ujis_japanese_ci    |      3 |
| sjis     | Shift-JIS Japanese          | sjis_japanese_ci    |      2 |
| hebrew   | ISO 8859-8 Hebrew           | hebrew_general_ci   |      1 |
| tis620   | TIS620 Thai                 | tis620_thai_ci      |      1 |
| euckr    | EUC-KR Korean               | euckr_korean_ci     |      2 |
| koi8u    | KOI8-U Ukrainian            | koi8u_general_ci    |      1 |
| gb2312   | GB2312 Simplified Chinese   | gb2312_chinese_ci   |      2 |
| greek    | ISO 8859-7 Greek            | greek_general_ci    |      1 |
| cp1250   | Windows Central European    | cp1250_general_ci   |      1 |
| gbk      | GBK Simplified Chinese      | gbk_chinese_ci      |      2 |
| latin5   | ISO 8859-9 Turkish          | latin5_turkish_ci   |      1 |
| armscii8 | ARMSCII-8 Armenian          | armscii8_general_ci |      1 |
| utf8     | UTF-8 Unicode               | utf8_general_ci     |      3 |
| ucs2     | UCS-2 Unicode               | ucs2_general_ci     |      2 |
| cp866    | DOS Russian                 | cp866_general_ci    |      1 |
| keybcs2  | DOS Kamenicky Czech-Slovak  | keybcs2_general_ci  |      1 |
| macce    | Mac Central European        | macce_general_ci    |      1 |
| macroman | Mac West European           | macroman_general_ci |      1 |
| cp852    | DOS Central European        | cp852_general_ci    |      1 |
| latin7   | ISO 8859-13 Baltic          | latin7_general_ci   |      1 |
| utf8mb4  | UTF-8 Unicode               | utf8mb4_general_ci  |      4 |
| cp1251   | Windows Cyrillic            | cp1251_general_ci   |      1 |
| utf16    | UTF-16 Unicode              | utf16_general_ci    |      4 |
| utf16le  | UTF-16LE Unicode            | utf16le_general_ci  |      4 |
| cp1256   | Windows Arabic              | cp1256_general_ci   |      1 |
| cp1257   | Windows Baltic              | cp1257_general_ci   |      1 |
| utf32    | UTF-32 Unicode              | utf32_general_ci    |      4 |
| binary   | Binary pseudo charset       | binary              |      1 |
| geostd8  | GEOSTD8 Georgian            | geostd8_general_ci  |      1 |
| cp932    | SJIS for Windows Japanese   | cp932_japanese_ci   |      2 |
| eucjpms  | UJIS for Windows Japanese   | eucjpms_japanese_ci |      3 |
+----------+-----------------------------+---------------------+--------+
40 rows in set

collation为排序规则,Maxlen为最大字节数。

不同的编码规则,会得到不同的二进制数,因此正确的编码转换是必要的。

查看当前的编码

mysql> show variables like '%char%';
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| character_set_client     | utf8   |
| character_set_connection | utf8   |
| character_set_database   | utf8   |
| character_set_filesystem | binary |
| character_set_results    | utf8   |
| character_set_server     | utf8   |
| character_set_system     | utf8   |
| character_sets_dir       |        |
+--------------------------+--------+

设置当前连接的编码,只针对此连接有效

mysql -h xxxxxx.mysql.rds.aliyuncs.com -u xxxxxx -p xxxxxx

mysql> set names gbk;

mysql> show variables like '%char%';
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| character_set_client     | gbk    |
| character_set_connection | gbk    |
| character_set_database   | utf8   |
| character_set_filesystem | binary |
| character_set_results    | gbk    |
| character_set_server     | utf8   |
| character_set_system     | utf8   |
| character_sets_dir       |        |
+--------------------------+--------+

这个命令会同时修改character_set_client, character_set_connection, character_set_results

我们在接数据库的时候设置的charset=utf8在内部就是调用的set names utf8

所以,代表客户端的编码有三个,这三个编码基本是一致的。其他的都是服务端的的编码。

character_set_client 客户端

character_set_connection 连接器

character_set_results 返回的结果集

既然是一样的,为什么客户端要搞三个配置呢,这就要从数据传输的流程上来看。

连接器:连接客户端与服务端,进行字符集的转换。

连接器的工作流程:

请求

character_set_client --> character_set_connection -->character_set_server

响应

character_set_server --> character_set_connection --> character_set_results

图示

到此这篇关于mysql中的utf8与utf8mb4存储及区别的文章就介绍到这了,更多相关mysql utf8与utf8mb4内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 设置mysql5.7编码集为utf8mb4的方法

    最近遇到一个问题,移动端的表情或者一些emoji是4字节的,但是utf-8是3字节的,查了很多网上的解决方法,最后提供一套自己的解决方案.如果当前的困境是:自己的mysql版本为5.5.3以前(版本为5.5.3以前将不能使用utf-8mb4编码),需要重装更高版本的mysql,然后获得该编码. 1,检查自己当前数据库版本 使用命令: select version(); 如果发现当前的数据库版本在5.5.3以前,则需要重装数据库,如果在该版本之后跳过第二步和第三步. 2,备份当前数据库中的数据 这

  • 详解JDBC对Mysql utf8mb4字符集的处理

    写在前面 在开发微信小程序的时候,评论服务模块希望添加上emoji表情,但是emoji表情是4个字节长度的,所以需要进行设置 当前项目是JAVA编写, 使用JDBC连接操作数据库, 如下针对的JDBC操作的解决方案 一.JDBC的URL的正常操作 复制代码 代码如下: jdbc.url=jdbc:mysql://HOST:3306/your_database?useUnicode=true&characterEncoding=utf8&useSSL=false 在连接配置中,声明UTF-8

  • Spring Data Jpa Mysql使用utf8mb4编码的示例代码

    1 问题:数据库字符集和排序规则不一致 最近需要向一个已有的数据库进行扩充(已有数据库是由PHP建的,后来由Java进行扩展),但是出现了新表和旧表无法建立外键的问题,后来发现是因为编码问题,服务器数据库和我本地数据库的字符集和排序规则不对应,服务器数据库使用的是utf8mb4,utf8mb4_unicode_ci而我本地使用的是utf8,utf8_general_ci. 2 解决方法 2.1 将本地数据库改成utf8mb4,utf8mb4_unicode_ci 该方法参考: 更改MySQL数据

  • 更改MySQL数据库的编码为utf8mb4问题

    目录 1. MySQL的版本 2. MySQL驱动 3. 修改MySQL配置文件 4. 重启数据库,检查变量 5. 数据库连接的配置 6. 将数据库和已经建好的表也转换成utf8mb4 utf-8编码可能1个字节.2个字节.3个字节.4个字节的字符,但是MySQL的utf8编码只支持最多3字节的数据,也就是说mysql最开始的时候,对utf-8的支持是不完整的.而emoji表情字符是4个字节的字符. 如果直接往采用utf-8编码的数据库中插入表情数据 java程序中将报SQL异常: java.s

  • 如何更改MySQL数据库的编码为utf8mb4

    utf8mb4编码是utf8编码的超集,兼容utf8,并且能存储4字节的表情字符. 采用utf8mb4编码的好处是:存储与获取数据的时候,不用再考虑表情字符的编码与解码问题. 更改数据库的编码为utf8mb4: 1. MySQL的版本 utf8mb4的最低mysql版本支持版本为5.5.3+,若不是,请升级到较新版本. 2. MySQL驱动 5.1.34可用,最低不能低于5.1.13 SHOW VARIABLES WHERE Variable_name LIKE 'character_set_%

  • 全面了解mysql中utf8和utf8mb4的区别

    一.简介 MySQL在5.5.3之后增加了这个utf8mb4的编码,mb4就是most bytes 4的意思,专门用来兼容四字节的unicode.好在utf8mb4是utf8的超集,除了将编码改为utf8mb4外不需要做其他转换.当然,为了节省空间,一般情况下使用utf8也就够了. 二.内容描述 那上面说了既然utf8能够存下大部分中文汉字,那为什么还要使用utf8mb4呢? 原来mysql支持的 utf8 编码最大字符长度为 3 字节,如果遇到 4 字节的宽字符就会插入异常了.三个字节的 UT

  • MySQL字符集utf8修改为utf8mb4的方法步骤

    对于mysql 5.5 而言,如果不设定字符集,mysql默认的字符集是 latin1 拉丁文字符集: 但随着各种业务的进一步发展,除了各个国家的本身语言字符,经常也会有一些表情符号出现在应用程序中,而在mysql 5.5 之前,UTF-8编码只支持1-3个字节,支持BMP这部分的Unicode编码区:从MySQL 5.5开始,可以支持4个字节UTF编码 utf8mb4 ,一个字符能够支持更多的字符集,也能够支持更多表情符号. utf8mb4兼容utf8,且比utf8能表示更多的字符,是utf8

  • mysql存储emoji表情报错的处理方法【更改编码为utf8mb4】

    本文实例分析了mysql存储emoji表情报错的处理方法.分享给大家供大家参考,具体如下: utf-8编码可能2个字节.3个字节.4个字节的字符,但是MySQL的utf8编码只支持3字节的数据,而移动端的表情数据是4个字节的字符.如果直接往采用utf-8编码的数据库中插入表情数据,Java程序中将报SQL异常: java.sql.SQLException: Incorrect string value: '\xF0\x9F\x92\x94' for column 'name' at row 1

  • MySQL 编码utf8 与 utf8mb4 utf8mb4_unicode_ci 与 utf8mb4_general_ci

    参考:mysql字符集小结 utf8mb4 已成为 MySQL 8.0 的默认字符集,在MySQL 8.0.1及更高版本中将 utf8mb4_0900_ai_ci 作为默认排序规则. 新项目只考虑 utf8mb4 UTF-8 编码是一种变长的编码机制,可以用1~4个字节存储字符. 因为历史遗留问题,MySQL 中的 utf8 编码并不是真正的 UTF-8,而是阉割版的,最长只有3个字节.当遇到占4个字节的 UTF-8 编码,例如 emoji 字符或者复杂的汉字,会导致存储异常. 从 5.5.3

  • mysql中的utf8与utf8mb4存储及区别

    目录 一.如何设置utf8mb4 二.问题 1.为什么存储的时候要区分utf8和utf8mb4 2.为什么读取的时候要区分utf8和utf8mb4 一.如何设置utf8mb4 mysql中针对字符串类型,在设置charset的时候可以精确到字段. 如果只将某个字段设置utf8mb4,那么其他字段不会受影响. 如果针对表来设置,那么已经存在的字段依然是utf8,并且会多出utf8的标记,之后所创建的字段才会是utf8mb4. 如果针对库来设置,那么已经存在的表依然是utf8,之后所创建的表才会是u

  • 为何不要在MySQL中使用UTF-8编码方式详解

    MySQL的UTF-8编码方式 MySQL 从 4.1 版本开始支持 UTF-8,也就是 2003 年,然而目前流行的UTF-8 标准(RFC 3629)是在此之后规定的.正因此,才造就了MySQL中的UTF-8与我们日常开发中的UTF-8不一致,从到导致了些问题.MySQL的UTF-8只支持每个字符最多三个字节,而真正的 UTF-8 是每个字符最多四个字节. 问题复现 有数据库表如下:utf8编码方式 往数据库存一条记录: @Test public void testInsert() { Us

  • 解读MySQL中一个B+树能存储多少数据

    目录 MySQL中一个B+树能存储多少数据 MySQL聚簇索引的存储结构 MySQL中B树与B+树的区别 B树 B+树 B树与B+树的区别 总结 MySQL中一个B+树能存储多少数据 MySQL聚簇索引的存储结构 MySQL中InnoDB页的大小默认是16k.也可以自己进行设置.(计算机在存储数据的时候,最小存储单元是扇区,一个扇区的大小是 512 字节,而文件系统(例如 XFS/EXT4)最小单元是块,一个块的大小是 4KB. InnoDB 引擎存储数据的时候,是以页为单位的,每个数据页的大小

  • 浅谈mysql中int(1)和int(10)的区别

    目录 困惑 数据说话 零填充 总结 困惑 最近遇到个问题,有个表的要加个user_id字段,user_id字段可能很大,于是我提mysql工单alter table xxx ADD user_id int(1).领导看到我的sql工单,于是说:这int(1)怕是不够用吧,接下来是一通解释. 其实这不是我第一次遇到这样的问题了,其中不乏有工作5年以上的老司机.包括我经常在也看到同事也一直使用int(10),感觉用了int(1),字段的上限就被限制,真实情况肯定不是这样. 数据说话 我们知道在mys

  • MySQL中Decimal类型和Float Double的区别(详解)

    MySQL中存在float,double等非标准数据类型,也有decimal这种标准数据类型. 其区别在于,float,double等非标准类型,在DB中保存的是近似值,而Decimal则以字符串的形式保存数值. float,double类型是可以存浮点数(即小数类型),但是float有个坏处,当你给定的数据是整数的时候,那么它就以整数给你处理.这样我们在存取货币值的时候自然遇到问题,我的default值为:0.00而实际存储是0,同样我存取货币为12.00,实际存储是12. 幸好mysql提供

  • MySQL中索引与视图的用法与区别详解

    前言 本文主要给大家介绍了关于MySQL中索引与视图的使用与区别的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 索引 一.概述 所有的Mysql列类型都可以被索引. mysql支持BTREE索引.HASH索引.前缀索引.全文本索引(FULLTEXT)[只有MyISAM引擎支持,且仅限于char,varchar,text列].空间列索引[只有MyISAM引擎支持,且索引的字段必须非空],但不支持函数索引. MyISAM和InnoDB存储引擎的表默认创建BTREE索引,

  • MySQL中int (10) 和 int (11) 的区别

    mysql 中整数数据类型: 不同类型的取值范围: 不同数据类型的默认v显示宽度: 显示的宽度跟负号没有关系,它只在人工设置了 ZEROFILL 属性有效.一旦人工设置了 ZEROFILL 属性,MySQL 会自动设置 UNSIGNED 属性(即 ZEROFILL 不能存储负数). 那取值范围和显示宽度到底有什么关系呢?利用 tinyint 做了个实验, 首先创建一张表如下: mysql> desc test_integer; +-----------+------------+------+-

  • MySQL中int(10)和int(11)的区别详解

    目录 一.背景 二.MySQL整数类型 总结: 一.背景 在创建数据库表的时候,我们经常会用到int(x)来定义一个字段的类型,一直误以为这里的x表示存储数字的长度. 其实大错特错,这里的 x 指的是 最大显示宽度(最大有效显示宽度是255),且显示宽度与存储大小或类型包含的值的范围无关. 二.MySQL整数类型 类型 字节 取值范围 显示宽度 tinyint 1 -128 ~ 127 4 smallint 2 -32768 ~ 32767 6 mediumint 3 -8388608 ~ 83

  • MySQL中create table as 与like的区别分析

    本文分析了MySQL中create table as 与like的区别.分享给大家供大家参考,具体如下: 对于mysql的复制相同表结构方法,有create table as 和create table like 两种,区别是什么呢? 复制代码 代码如下: create table t2 as select * from t1 where 1=2; 或者 复制代码 代码如下: limit 0; as创建出来的t2表(新表)缺少t1表(源表)的索引信息,只有表结构相同,没有索引. 复制代码 代码如

  • MySQL中in与exists的使用及区别介绍

    先放一段代码 for(int i=0;i<1000;i++){ for(int j=0;j<5;j++){ System.out.println("hello"); } } for(int i=0;i<5;i++){ for(int j=0;j<1000;j++){ System.out.println("hello"); } } 分析以上代码可以看到两行代码除了循环的次序不一致意外,其他并无区别,在实际执行时两者所消耗的时间和空间应该也是一

随机推荐