前言
本次使用Navicat时遇到了2个数据库相关的bug,但是是同一个原因导致的。
这两个故障分别是:
- 中文乱码
- 无法执行带中文注解的SQL语句
由于我是先遇到困难,再依次解决表面问题,最后才发现根本问题。
因此本次我将先讲核心解决方案,再讲故障的具体表现。
一方面方便遇到同类型故障的人可以更为轻松的找到适合自己的解决方案,另一方面,本次解决故障的思路值得作为参考。
核心解决方案
本次故障的根本原因是Navicat连接数据库时编码选择错误,我原本的编码为936(ANSI)当我修改编码为自动时,两个故障不会发生。
需要注意的是,应该改为自动而不是(65001)utf-8
修改如下:
故障1:Failed to update tables dictionary object
含义直译为:未能更新表字典对象。
这个故障是我在进行数据库导入的时候发生的,并且发生多处,初步搜索同类型问题后得到基础解决方案:
删除中文注解。
删除后导入成功,但是后期排查发现是连接数据库时编码格式错误导致中文不可被识别。
同理,我推断,用其他方式导入时如果遇到同类型问题,应该先研究观察环境是否匹配。中文注解只是故障的形成因素,不是根本原因。
故障2:表内中文字符串乱码
这个故障是在和前端交互时发现的,当时并未认为是数据库错误,因为在Navicat的预览界面上或者是命令行语句执行中,所获得的中文都是正确的。
Navicat内置命令行:
但是在后续的抓包中发现传输的中文的确为乱码,进一步用系统命令行连接数据库进行查找和观察,发现中文为乱码,并且和前端显示一致(也许会不一致,但是此处的一致启发了我,我意识到出错误的是Navicat)
于是先在系统命令行完成字段导入再在前端页面观察,发现此时中文内容正常。再用Navicat进行预览,明确发现在预览中中文为乱码。
最终通过修改连接数据库的编码格式解决问题,可以正常显示中文,并且导入结果也是正确的。
面对同类型问题,中文类问题,除了要观察表的编码格式,还需要关注数据源的编码格式,例如本次的连接数据库的工具选择了不兼容的编码,导致了乱码的发生。
结语
中文类乱码,通常是编码格式错误导致的,遇到此类问题,应该从多个角度切入解决,先定位具体出错的位置,再考虑解决方案,否则只可能是解决了表面问题。