MySQL恢復和UTF文件BOM標志讀取問題

前天，客戶來電說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的還是不一樣啊。www.linuxidc.com對比利用EMEditor二進制打開的文件，卻發現串口接收的和EMEditor的一樣。對比EMEditor的字節數和文件屬性字節數，一致。驗證C程序，一致。用EMEditor給文件加上UTF編碼標記，C程序讀取，可以讀取到BOM數據。最后驗證UE中間做了手腳，天啊。哎，太相信UE了。

MySQL最終恢復卻都沒用到這些，呵呵。今天客戶又打電話過來，問我怎么樣了，我交流以后發現，他還是按我說的備份了全部的MySQL安裝目錄，還有，他提到其他盤有一個ibdata1文件，時間太長了，我都忘了，應該是當時我為了數據安全，安裝的時候將數據文件放到別的分區中了。這下好了，分析客戶發過來的全部資料，清楚了原來安裝MySQL的原始結構，并且發現原來的MySQL配置文件的MySQL自動備份存在MySQL目錄中。于是就超級簡單了。停止MySQL服務，移掉MySQL相關目錄，解壓客戶發過來的數據到MySQL安裝目錄中，修改配置文件，在相應的路徑中放置ibdata1，重啟服務，OK，一切正常。

想想，Linux系的軟件還是好啊，恢復起來趕緊利落。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]