MySQL恢復(fù)和UTF文件BOM標(biāo)志讀取問題

前天，客戶來電說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服務(wù)器，確認(rèn)該文件用于存儲數(shù)據(jù)庫數(shù)據(jù)。看來只能是使用二月份的備份數(shù)據(jù)了。
-
 

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

用UE打開備份文件，發(fā)現(xiàn)前面是FEFF，UTF的編碼標(biāo)記，后面是有規(guī)律的一個字節(jié)數(shù)據(jù)，一個字節(jié)的零，手動提取字節(jié)數(shù)據(jù)，恢復(fù)出來時可讀的，于是想利用程序提取出來非零數(shù)據(jù)，然后恢復(fù)。結(jié)果，發(fā)現(xiàn)程序死活不能讀到標(biāo)記字節(jié)FEFF。想可能VC2008+Win7可能自動給你處理了FEFF，于是上VMWare+DOS622+TC2，結(jié)果還是一樣，查到網(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命令設(shè)之，發(fā)現(xiàn)收到的數(shù)據(jù)和UE的還是不一樣啊。www.linuxidc.com對比利用EMEditor二進(jìn)制打開的文件，卻發(fā)現(xiàn)串口接收的和EMEditor的一樣。對比EMEditor的字節(jié)數(shù)和文件屬性字節(jié)數(shù)，一致。驗證C程序，一致。用EMEditor給文件加上UTF編碼標(biāo)記，C程序讀取，可以讀取到BOM數(shù)據(jù)。最后驗證UE中間做了手腳，天啊。哎，太相信UE了。

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

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

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