MySQL insert 记录后查询乱码问题解决方法
问题现象
后台应用程序使用的是云上的 MySQL 服务，需要给 MySQL 数据表里 insert 一些数据，平时都是先运行一个 MySQL 的 pod：
kubectl run mysql-client --rm -it --restart='Never' --image mysql:5.7 --command -- env LANG=C.UTF-8 mysql -hx.x.x.x -uusername -ppassword
然后将 insert SQL 文件复制到 MySQL pod 里面，在 MySQL pod 中执行 source SQL 文件命令。这次 insert 数据时发现环境上已经有运行的 MySQL pod了，就将 SQL 文件复制到已运行的 MySQL pod中，然后通过命令进入到MySQL pod里，再连接到云上 MySQL：
kubectl exec -it mysql-client -- bash mysql -hx.x.x.x -uusername -ppassword
接着执行 source SQL文件，然后通过前端页面查看录入的数据，发现是乱码。但是在执行 source 命令的 MySQL 客户端 select 查询录入的数据却是预期的中文字符。
问题原因
例如 source 执行的 SQL文件中的 SQL 语句是
INSERT INTO table_1 (title) VALUES ('好');SQL文件是UTF8编码的，MySQL 客户端向 MySQL 服务器发送的 title 字段值的 “好” 的 UTF8编码字节序列，十六进制表示是 E5A5BD。
mysql-client pod的字符集是 POSIX，MySQL 客户端向 MySQL 服务器发送数据采用的就是 latin1编码，MySQL 服务器收到数据后，使用 latin1 解码 E5A5BD ，得到字符串 好。
root@mysql-client:/# locale LANG= LANGUAGE= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= mysql> show variables like 'character_set_%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | latin1 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ 8 rows in set (0.01 sec)
由于数据表字段的字符集是 UTF8，MySQL 服务器再将字符串 好 用 UTF8 编码得到字节序列 C3A5C2A5C2BD，这个可以通过如下 SQL 语句查询证实。
select HEX(title) from table_1;
这里说一下在验证此过程时遇到的问题：
刚开始使用的中文字符“我”进行验证，对应的 UTF8 编码是 e68891，88 和 91 （位于 80 和 9f 之间）在 latin1 编码中对应的是控制字符，手动解码后的字符不是正常字符，再使用 UTF8 编码时为 C3A6C288C291，和数据表中存储的 C3A6CB86E28098 不一样（MySQL 代码中编码肯定对控制字符进行了正确编码），为了避免控制字符，想到选用不在 80 和 9f 之间的中文字符“好” E5A5BD ，这样手动编码后和数据表存储的都是 C3A5C2A5C2BD，这才验证了这个过程。
页面查询乱码的原因：
前端页面通过调用后台接口查询数据，后台服务连接 MySQL 使用的字符集是 UTF8，所以character_set_results 就是 UTF8。
MySQL 服务器从数据表中查询的字节序列是 C3A5C2A5C2BD，数据表字段的编码也是 UTF8，和 character_set_results 一样，发送给后台服务客户端的字节序列就是 C3A5C2A5C2BD。
后台服务使用 UTF8 对 C3A5C2A5C2BD 解码得到 好，所以前端页面显示的就是 好，而不是预期的中文字符 ”好“。
MySQL 命令行客户端select 查询正常的原因：
MySQL 命令行客户端 session 的 character_set_results 是 latin1 。
MySQL 服务器从数据表中查询的字节序列是 C3A5C2A5C2BD，使用 UTF8 解码后是 好。
再使用 character_set_results 的字符集 latin1 进行编码得到 E5A5BD，将字符序列 E5A5BD 发送给 MySQL 命令行客户端。
再发送给本地的图形界面的终端模拟器 MobaXterm，MobaXterm 使用的字符集是 UTF8，使用 UTF8 对 E5A5BD 解码输出中文字符“好”。
解决方法
连接云上 MySQL 时指定字符集为 utf8
mysql -hx.x.x.x -uusername -ppassword --default-character-set=utf8
将 MySQL pod 的字符编码设置为 UTF8， 这样 MySQL 客户端连接服务器时使用的字符集就是 utf8
export LANG=C.UTF-8
或者直接在如下命令启动的 MySQL 客户端中执行 source 命令，此命令通过 env LANG=C.UTF-8 设置了 pod的字符编码为 UTF8：
kubectl run mysql-client --rm -it --restart='Never' --image mysql:5.7 --command -- env LANG=C.UTF-8 mysql -hx.x.x.x -uusername -ppassword
这样，MySQL 的 character_set_client、character_set_connection、character_set_results都会设置为 utf8， 就和数据表字段的字符集保持一致，不会出现乱码问题。
mysql> show variables like 'character_set_%'; +--------------------------+----------------------------+ | 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 | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ 8 rows in set (0.00 sec)
MySQL 客户端和服务器通信中的字符集处理
客户端给服务器发送消息过程
- 如果 mysql 命令中没有指定 --default-character-set 参数，客户端使用操作系统字符集对消息编码发送给服务器，否则使用 --default-character-set 参数的字符集对消息编码。
- 服务器将 character_set_client、 character_set_connection、character_set_results 设置为客户端的字符集。
- 收到客户端的消息后，使用 character_set_client 字符集对消息解码。
- 再用 character_set_connection 对应的字符集对解码后的消息编码后处理。
服务器处理消息时要转换为 character_set_connection 字符集进行处理，比较规则只有 connection 有，character_set_client 和 character_set_results 都没有：
mysql> show variables like 'collation_%'; +----------------------+-------------------+ | Variable_name | Value | +----------------------+-------------------+ | collation_connection | latin1_swedish_ci | | collation_database | utf8_general_ci | | collation_server | utf8_general_ci | +----------------------+-------------------+ 3 rows in set (0.00 sec)
服务器给客户端发送消息过程
- 服务器从数据表中查询字段内容
- 将字符内容先使用字段的字符集解码，再使用 character_set_results 字符集编码后发给客户端。
- 客户端使用操作系统的字符集解码消息进行展示，这里对于使用本地图形界面的终端模拟器登录远程主机的场景来说，消息还会发送到本地图形界面的终端模拟器，使用终端模拟器的字符集对消息解码再展示出来。
到此这篇关于MySQL insert 记录后查询是乱码问题分析的文章就介绍到这了,更多相关mysql insert 查询乱码内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
相关文章
MySql5.6使用validate password 插件加强密码强度的安装及使用方法
在mysql5.6中使用validate password插件加强密码强度，支持密码的强度要求，是一款非常好用的密码加强插件，下面小编通过本文给大家介绍MySql5.6使用validate password 插件加强密码强度的安装及使用方法，小伙伴们一起学习吧2016-07-07
在MySQL中获取每个分组的最新记录可以通过子查询或窗口函数实现,使用子查询时,通过设定时间戳字段确定最新记录,并利用LIMIT子句获取,若MySQL版本支持窗口函数（如MySQL 8.0+）,可使用ROW_NUMBER()配合PARTITION BY和ORDER BY实现同样效果2024-09-09
ERROR: Error in Log_event::read_log_event()
ERROR: Error in Log_event::read_log_event(): read error, data_len: 438, event_type: 22014-02-02
本篇文章主要介绍了MySQL主从复制实战 - 基于GTID的复制，基于GTID的复制是MySQL 5.6后新增的复制方式.有兴趣的可以了解一下。2017-03-03
这篇文章主要介绍了mysql查看连接数和设置会话超时问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2024-01-01
本篇文章主要针对MYSQL中分组以及4种链接做了详细的分析，有助于大家对这2项MYSQL功能有深入的理解，参考学习下吧。2017-12-12
Linux下安装mysql的方式（yum和源码编译两种方式）
这里介绍Linux下两种安装mysql的方式：yum安装和源码编译安装。需要的朋友可以参考下2018-02-02
这篇文章主要给大家介绍了关于MySQL 5.X日期函数与时间函数的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2020-12-12
这篇文章主要介绍了mysql-8.0.17-winx64 部署方法,非常不错，具有一定的参考借鉴价值，需要的朋友可以参考下2019-08-08
这篇文章主要介绍了Mysql SQL服务器模式介绍,需要的朋友可以参考下MySQL服务器可以以不同的SQL模式来操作,并且可以为不同客户端应用不同模式,这样每个应用程序可以根据自己的需求来定制服务器的操作模式,需要的朋友可以参考下2014-12-12
最新评论