MySQL恢复和UTF文件BOM标志读取问题

MySQL最终恢复却都没用到这些，呵呵。今天客户又打电话过来，问我怎么样了，我交流以后发现，他还是按我说的备份了全部的MySQL安

前天，，客户来电说GPS巡线系统的后台数据库挂了，原因是原来分配给图片存储磁盘的空间不够了，他调整了一下分区。我让他把整个MySQL目录的文件备份下来（后来发现这是多么重要），然后重装一下数据库试试。重装以后发现不行。于是给我让他发了MySQL下面的data目录文件给我，还有今年二月份用后台软件备份下来的数据备份也发了过来。

网上查询发现MySQL的数据存储在data目录下的ibdata1文件中，使用UE打开该文件，发现全是0，显然不能包含数据，对比公司内部测试使用的MySQL服务器，确认该文件用于存储数据库数据。看来只能是使用二月份的备份数据了。

打开二月份备份数据，发现数据库的字符集用的是binary，这是当时不太清楚字符集该怎么设，从别人那里继承来的。试图重装一个MySQL，设定为binary，恢复还是有错误。在MySQL命令行中手动执行恢复操作，提示是数据库字段宽度不够，手动调整数据库字段大小，成功走完恢复过程，但是恢复出来的数据显示是乱码。

用UE打开备份文件，发现前面是FEFF，UTF的编码标记，后面是有规律的一个字节数据，一个字节的零，手动提取字节数据，恢复出来时可读的，于是想利用程序提取出来非零数据，然后恢复。结果，发现程序死活不能读到标记字节FEFF。想可能VC2008+Win7可能自动给你处理了FEFF，于是上VMWare+DOS622+TC2，结果还是一样，查到网上有一篇文章How NOT to skip BOM info (FF FE) when using fread or ifstream? 这个现象一摸一样。就是没有解答。

早晨又想到一个方法，利用文件传输，这下该啥码都出来了吧，于是上串口互联，一个串口打开串口调试软件，另一个串口copy，发现接收出来数据不对，MODE命令设之，发现收到的数据和UE的还是不一样啊。对比利用EMEditor二进制打开的文件，却发现串口接收的和EMEditor的一样。对比EMEditor的字节数和文件属性字节数，一致。验证C程序，一致。用EMEditor给文件加上UTF编码标记，C程序读取，可以读取到BOM数据。最后验证UE中间做了手脚，天啊。哎，太相信UE了。

MySQL最终恢复却都没用到这些，呵呵。今天客户又打电话过来，问我怎么样了，我交流以后发现，他还是按我说的备份了全部的MySQL安装目录，还有，他提到其他盘有一个ibdata1文件，时间太长了，我都忘了，应该是当时我为了数据安全，安装的时候将数据文件放到别的分区中了。这下好了，分析客户发过来的全部资料，清楚了原来安装MySQL的原始结构，并且发现原来的MySQL配置文件的MySQL自动备份存在MySQL目录中。于是就超级简单了。停止MySQL服务，移掉MySQL相关目录，解压客户发过来的数据到MySQL安装目录中，修改配置文件，在相应的路径中放置ibdata1，重启服务，OK，一切正常。

想想，Linux系的软件还是好啊，恢复起来赶紧利落。