正文
背景
最近同事反馈公司的产品再更新了mysql-8.0.31的驱动jar包后部分功能报错.
问题核心原因 研发这边石磊老师已经找到了.
结论是Mysql8.0.26之后的数据库驱动好像会识别操作系统的编码格式.
进而会导致尤其是stringbuilder等对象的序列化与反序列化的问题.
这里想简单复盘一下. 加强对编码格式的学习和了解.
问题现象
最开始的数据库驱动版本是 mysql-8.0.23
最近为了安全与性能升级到 mysql-8.0.31
大部分功能没问题. linux系统下也么有问题.
但是Windows系统下面的程序就报错了.
查过表的字符集, 数据库的字符集, 甚至是列的字符集都没有问题
show full columns from table_name
均是符合要求的utf8mb3字符集
(知道utf8mb4,但是产品有他的局限性.)
问题解决
可以使用 启动脚本增加 -Dfile.encoding=UTF-8
或者是 降级Mysql的驱动到 8.0.23 就可以.
问题推测
获取系统的编码格式:
Windows: chcp
Linux: local
注意: 活动代码页 936 代表的就是GBK编码格式
很多解压缩会出现乱码需要使用
unzip -O CP936 xxxx.zip 的核心原理是一样的
CP 的含义就是code page
需要注意的一点是:
Windows诞生的比utf8编码格式要早很多.
他的国际化也一直沿用了比较早的语言编码格式.
Linux诞生的比Windows和utf8都要晚很多.
所以Linux很多默认的编码格式都是utf-8的
Linux再现问题
尝试修改Linux系统的编码格式.
网上的很多办法都不太好用.
我这边的方式为:
cat >/etc/profile.d/gbk.sh <<EOF
export LANG=zh_CN.GBK
EOF
source /etc/profile.d/gbk.sh
然后系统内验证一下 locale得出的结果为:
[root@centos7ver2009 myapp]# locale
LANG=zh_CN.GBK
LC_CTYPE="zh_CN.GBK"
LC_NUMERIC="zh_CN.GBK"
LC_TIME="zh_CN.GBK"
LC_COLLATE="zh_CN.GBK"
LC_MONETARY="zh_CN.GBK"
LC_MESSAGES="zh_CN.GBK"
LC_PAPER="zh_CN.GBK"
LC_NAME="zh_CN.GBK"
LC_ADDRESS="zh_CN.GBK"
LC_TELEPHONE="zh_CN.GBK"
LC_MEASUREMENT="zh_CN.GBK"
LC_IDENTIFICATION="zh_CN.GBK"
LC_ALL=
然后在这个shell上面启动服务进行验证.
nohup ./startup-linux.sh >locale_gbk_startup.log &
问题确认
导致具体问题的原因不是很清楚.
但是发现跟数据库版本.和系统版本其实关系不大.
只不过因为默认的系统编码格式不一致导致了问题.
编码格式,时区,字符集,字体 其实都很关键.
有差异都会导致产品出现不一致的情况.
