需求:导出一个测试库的数据(数据库不大,就几张表)
导出命令:
mysqldump -uroot -p --single-transaction --master-data=2 --triggers -f -R -E --databases test>test.sql
现象:查看test.sql中文居然是这个样子的 '浼氳瘽鍚嶇О'。
但是这个命令导出这套环境的其它包含中文的库确是正常的。
问题分析:
什么原因呢?先不管中文乱码的问题,先把备份的数据导入到新库看看,居然中文显示正常。这也是一个比较投机的做法,很多人看到乱码,就不敢继续操作了。
为什么敢这么做呢?因为之前老大的一句话,“计算机是一门实验科学,只相信被实验证明过的东西”。
既然导入后中文显示正常,还用去找乱码的原因吗?
vim :set fileencoding 查看文件编码 居然是latin1,能正常显示中文的备份文件时utf-8
为什么呢?怀疑是表结构或数据有问题。
只导出表结构,居然中文显示正常。
mysqldump -uroot -p --single-transaction --master-data=2 --triggers -f -R -E -d --databases test>test.sql
同时导出表结构和数据,显示乱码。猜想可能是数据有问题了。但数据在原库中文显示是正常的啊。
。。。
。。。
在仔细分析一下表结构,原来有blob类型。这下乱码就不奇怪了。
在原命令的基础上加上--hex-blob,搞定。
这个参数的含义是用16进制的方式导出BINARY, VARBINARY, BLOB类型的数据。
--hex-blob Dump binary strings (BINARY, VARBINARY, BLOB) in hexadecimal format.
mysqldump -uroot -p --single-transaction --master-data=2 --triggers -f -R -E --hex-blob --databases test>test.sql
其实在我们的备份脚本中早已经把这个参数加进去了,只是我们没有引起足够的重视罢了。