我正在尝试导出我们非常大的MySQL数据库(1.6GB - 主要是BLOB)并导入到新服务器中。我已经解决了大部分问题,最终完成了导入而没有任何错误。使用MySQL查询浏览器我在一个带有BLOB图像的表上运行查询并将其保存到磁盘(使用查询浏览器中的保存图标)。当我尝试打开文件时收到“无效的图像格式”错误。哦,哦。
使用查询浏览器我检查了源数据库和最近导入的新数据库的值。我想,价值观是不同的。它可能只是编码问题或其他东西。这就是我所看到的:
源(有效数据)服务器:
FF D8 FF E0 00 10 4A 46 49 46 00 01 01 01 00 60
00 60 00 00 FF DB 00 43 00 08 06 06 07 06 05 08
and so on...
新服务器:
C3 BF C3 98 C3 BF C3 A0 00 10 4A 46 49 46 00 01
01 01 00 60 00 60 00 00 C3 BF C3 9B 00 43 00 08
and so on...
在这个例子中,我的新手眼看来,“新”服务器上的数据前面有3个字节的额外数据。
然后我使用010 editor检出了sql转储文件。我找到了这个特定例子的行,这就是我所看到的:
FF D8 FF E0 5C 30 10 4A 46 49 46 5C 30 01 01 01
5C 30 60 5C 30 60 5C 30 5C 30 FF DB 5C 30 43 5C
30 08 06 06 07 06 05 08 and so on...
现在,我已经超越了我的头脑。我看到模式,我注意到HEX对5C 30看起来和00相同,但我不明白为什么。在这一点上,我有一个即将被擦除的源服务器和一个我担心已导入损坏数据的新服务器。我希望这是某种编码问题,可以通过在MySQL中设置一个全局变量来解决,但我真的不知道。
我还应该提一下,当我从源(工作)服务器和新的(损坏的)服务器保存文件时,文件大小对于损坏的文件大约大40%。
我检查了两台服务器上的字符集变量:
SHOW VARIABLES LIKE '%char%'
源服务器:
character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8
新服务器:
character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8
他们是一样的。
答案 0 :(得分:6)
来自新数据库的损坏数据看起来像是将源数据从ISO-8859-1转换为UTF-8(例如U + 00FF - ÿ - 前者FF
和{{1}的结果在后者)。
由于BLOB没有字符集,因此字符编码不受服务器变量的控制;我怀疑C3 BF
正在以UTF-8编码的文件(which is the default)输出您的BLOB数据,并且通过某种方式对服务器设置和选项传递给{{1 }}
最佳解决方案可能是在导出BLOB字段时使用--hex-blob
选项,这会导致类似:
mysqldump