如何修复mysql中gbk与其他编码互转时gbk增补汉字的乱码问题(比如gbk<->utf-8)

「已注销」 2017-06-09 04:05:59
加精
简述:
当以gbk编码sql向一个utf8编码的表中写入数据时,gbk中部分增补汉字在内码中没有对应编码,导致存储到数据库中的中文变为0x3F (“?”) 。因此,想求教如何修改mysql使用的内码页来修复此问题。
期待各位达人解答!~

已确认影响范围: mysql 5.5.56,5.6.36,5.7.18;mariadb-10.2.6。

问题详细描述:
安装设置mysql5.6使用utf8字符集。
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 |

创建数据库tmp; 创建表a
create table a (name varchar(32) not null);

mysql> SELECT character_set_name, collation_name
-> FROM information_schema.columns
-> WHERE table_schema = 'tmp'
-> AND table_name = 'a'
-> AND column_name = 'name';
+--------------------+-----------------+
| character_set_name | collation_name |
+--------------------+-----------------+
| utf8 | utf8_general_ci |
+--------------------+-----------------+

创建/tmp/gbk.sql文件,内容如下(sql语句使用gbk编码):
set names gbk;
SELECT '眼' AS `眼`;
SELECT '' AS ``;

结果为:
mysql> source /tmp/gbk.sql;
Query OK, 0 rows affected (0.00 sec)

+----+
| 眼 |
+----+
| 眼 |
+----+
1 row in set (0.00 sec)

+----+
| ? |
+----+
|  |
+----+
1 row in set (0.00 sec)


mysql5.6的手册中如此说:

• MySQL's gbk is in reality “Microsoft code page 936”. This differs from the official gbk for characters A1A4 (middle dot), A1AA (em dash), A6E0-A6F5, and A8BB-A8C0.


• For a listing of gbk/Unicode mappings, see http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT.

在CP936.TXT的最后只到0xFE4F,后面的编码完全没有 0xFE50~0XFE7E,0xFE80~0xFEA0 共计80个字符


0xFD9A 0x9FA4 #CJK UNIFIED IDEOGRAPH
0xFD9B 0x9FA5 #CJK UNIFIED IDEOGRAPH
0xFD9C 0xF92C #CJK COMPATIBILITY IDEOGRAPH
0xFD9D 0xF979 #CJK COMPATIBILITY IDEOGRAPH
0xFD9E 0xF995 #CJK COMPATIBILITY IDEOGRAPH
0xFD9F 0xF9E7 #CJK COMPATIBILITY IDEOGRAPH
0xFDA0 0xF9F1 #CJK COMPATIBILITY IDEOGRAPH
0xFE40 0xFA0C #CJK COMPATIBILITY IDEOGRAPH
0xFE41 0xFA0D #CJK COMPATIBILITY IDEOGRAPH
0xFE42 0xFA0E #CJK COMPATIBILITY IDEOGRAPH
0xFE43 0xFA0F #CJK COMPATIBILITY IDEOGRAPH
0xFE44 0xFA11 #CJK COMPATIBILITY IDEOGRAPH
0xFE45 0xFA13 #CJK COMPATIBILITY IDEOGRAPH
0xFE46 0xFA14 #CJK COMPATIBILITY IDEOGRAPH
0xFE47 0xFA18 #CJK COMPATIBILITY IDEOGRAPH
0xFE48 0xFA1F #CJK COMPATIBILITY IDEOGRAPH
0xFE49 0xFA20 #CJK COMPATIBILITY IDEOGRAPH
0xFE4A 0xFA21 #CJK COMPATIBILITY IDEOGRAPH
0xFE4B 0xFA23 #CJK COMPATIBILITY IDEOGRAPH
0xFE4C 0xFA24 #CJK COMPATIBILITY IDEOGRAPH
0xFE4D 0xFA27 #CJK COMPATIBILITY IDEOGRAPH
0xFE4E 0xFA28 #CJK COMPATIBILITY IDEOGRAPH
0xFE4F 0xFA29 #CJK COMPATIBILITY IDEOGRAPH


...全文
4988 31 打赏 收藏 转发到动态 举报
写回复
用AI写文章
31 条回复
切换为时间正序
请发表友善的回复…
发表回复
凉山老殷 2017-08-03
  • 打赏
  • 举报
回复
南京男人的天堂,温泉会所服务,微xinxin54122.
nettman 2017-08-02
  • 打赏
  • 举报
回复
sqpgyIDC 2017-08-01
  • 打赏
  • 举报
回复
为什么要在数据库里面改,
qq_24679409 2017-07-26
  • 打赏
  • 举报
回复
666学习了
weixin_39530971 2017-07-16
  • 打赏
  • 举报
回复
谢谢分享谢谢分享
zhujinqiang 2017-07-11
  • 打赏
  • 举报
回复
为什么要在数据库里面改, 而不是客户端先调整好编码之后再往库里保存。
dbxiaokai 2017-07-06
  • 打赏
  • 举报
回复
凡竹 2017-07-06
  • 打赏
  • 举报
回复
nettman 2017-07-04
  • 打赏
  • 举报
回复
nettman 2017-07-02
  • 打赏
  • 举报
回复
sinat_39383572 2017-07-02
  • 打赏
  • 举报
回复
lx318 2017-07-02
  • 打赏
  • 举报
回复
learning~
yingtaowei 2017-06-30
  • 打赏
  • 举报
回复
好实用已收藏
nettman 2017-06-30
  • 打赏
  • 举报
回复
cattpon 2017-06-29
  • 打赏
  • 举报
回复
learning~
nettman 2017-06-29
  • 打赏
  • 举报
回复
hugh_z 2017-06-29
  • 打赏
  • 举报
回复
6666666666666666666666
hugh_z 2017-06-28
  • 打赏
  • 举报
回复
6666666666666666666
cattpon 2017-06-28
  • 打赏
  • 举报
回复
learning~
luochaoming1900 2017-06-28
  • 打赏
  • 举报
回复
mysql 应该尽量用UTF-8吧
加载更多回复(10)
Re: 《文件备份与压缩命令》 ---------------------------------------内容提要: 1/6)tar   命令:打包备份/解压打包(将文件或目录的压缩或不解压查看查看)2/6)gzip  命令:压缩或解压文件3/6)zip   命令:打包和压缩文件4/6)unzip 命令:解压zip文件5/6)scp   命令:远程文件复制(全量备份)6/6)rsync 命令:文件同步工具(增量备份)  本人在教学和实战过程发现,即便是有一定运维经验的人,可能已经能够搭建一定复杂度的Linux架构,但是在来来回回的具体操作,还是体现出CLI(命令界面)功底不够扎实,甚至操作的非常‘拙’、处处露‘怯’。 对一个士兵来说,枪就是他的武器,对于一个程序员来说,各种library(工具库)就是他的武器;而对于Linux运维人员来说,无疑命令行工具CLI(命令界面)就是他们的武器;高手和小白之间的差距往往就体现在对于这些“武器”的掌握和熟练程度上。有候一个参数就能够解决的事情,小白们可能要写一个复杂的Shell脚本才能搞定,这就是对CLI(命令界面)没有理解参悟透彻导致。 研磨每一个命令就是擦拭手的作战武器,平不保养不理解,等到作战的候,一定不能够将手的武器发挥到最好,所以我们要平心、静气和专注,甘坐冷板凳一段间,才能练就一身非凡的内功! 本教程从实战出发,结合当下流行或最新的Linux(v6/7/8 版本)同演示,将命令行结合到解决企业实战问题来,体现出教学注重实战的务实精神,希望从事或未来从事运维的同学,能够认真仔细的学完Linux核心命令的整套课程。 本课程系列将逐步推出,看看我教学的进度和您学习的步伐,孰占鳌头! 注:关于教学环境搭建,可以参考本人其它课程系列,本教学就不再赘述! 《参透 VMware 桌面级虚拟化》 《在虚拟机安装模版机(包括应用软件等)》 《SecureCRT 连接 GNS3/Linux 的安全精密工具》

56,681

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧