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

前天，客戶來電說GPS巡線系統(tǒng)的后臺數(shù)據(jù)庫掛了，原因是原來分配給圖片存儲磁盤的空間不夠了，他調(diào)整了一下分區(qū)。我讓他把整個MySQL目錄的文件備份下來（后來發(fā)現(xiàn)這是多么重要），然后重裝一下數(shù)據(jù)庫試試。重裝以后發(fā)現(xiàn)不行。于是給我讓他發(fā)了MySQL下面的data目錄文件給我，還有今年二月份用后臺軟件備份下來的數(shù)據(jù)備份也發(fā)了過來。

網(wǎng)上查詢發(fā)現(xiàn)MySQL的數(shù)據(jù)存儲在data目錄下的ibdata1文件中，使用UE打開該文件，發(fā)現(xiàn)全是0，顯然不能包含數(shù)據(jù)，對比公司內(nèi)部測試使用的MySQL服務器，確認該文件用于存儲數(shù)據(jù)庫數(shù)據(jù)�？磥碇荒苁鞘褂枚�月份的備份數(shù)據(jù)了。
-
 

打開二月份備份數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)庫的字符集用的是binary，這是當時不太清楚字符集該怎么設，從別人那里繼承來的。試圖重裝一個MySQL，設定為binary，恢復還是有錯誤。在MySQL命令行中手動執(zhí)行恢復操作，提示是數(shù)據(jù)庫字段寬度不夠，手動調(diào)整數(shù)據(jù)庫字段大小，成功走完恢復過程，但是恢復出來的數(shù)據(jù)顯示是亂碼。

用UE打開備份文件，發(fā)現(xiàn)前面是FEFF，UTF的編碼標記，后面是有規(guī)律的一個字節(jié)數(shù)據(jù)，一個字節(jié)的零，手動提取字節(jié)數(shù)據(jù)，恢復出來時可讀的，于是想利用程序提取出來非零數(shù)據(jù)，然后恢復。結果，發(fā)現(xiàn)程序死活不能讀到標記字節(jié)FEFF。想可能VC2008+Win7可能自動給你處理了FEFF，于是上VMWare+DOS622+TC2，結果還是一樣，查到網(wǎng)上有一篇文章How NOT to skip BOM info (FF FE) when using fread or ifstream? 這個現(xiàn)象一摸一樣。就是沒有解答。

早晨又想到一個方法，利用文件傳輸，這下該啥碼都出來了吧，于是上串口互聯(lián)，一個串口打開串口調(diào)試軟件，另一個串口copy，發(fā)現(xiàn)接收出來數(shù)據(jù)不對，MODE命令設之，發(fā)現(xiàn)收到的數(shù)據(jù)和UE的還是不一樣啊。www.linuxidc.com對比利用EMEditor二進制打開的文件，卻發(fā)現(xiàn)串口接收的和EMEditor的一樣。對比EMEditor的字節(jié)數(shù)和文件屬性字節(jié)數(shù)，一致。驗證C程序，一致。用EMEditor給文件加上UTF編碼標記，C程序讀取，可以讀取到BOM數(shù)據(jù)。最后驗證UE中間做了手腳，天啊。哎，太相信UE了。

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

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

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