標題好長。
今天整理數據發現06年之前我的博客數據還在，都有備份，所以打算都導入到現在的博客里。
????????今天備份數據進行修改，直接使用chrome瀏覽器備份導出為xx.sql.gz文件。 修改過程發現問題，進行數據恢復， fuck！ 只導入了部分數據。
? ? ? ? 查找資料發現這篇文章的：?http://www.c-dd.cn/phpmyadmin%E5%AF%BC%E5%87%BA%E7%9A%84sql-gz%E6%95%B0%E6%8D%AE%E4%BF%AE%E5%A4%8D.html,? 感謝博主！
在操作的過程中，用phpmyadmin導出數據庫做了備份，當時導出選擇的GZIP壓縮，導出以后也沒注意導出的文件是否正常。在我清理了數據庫，打算重新導入的時候，悲劇發生了！MYSQL報錯，經查看是導出的sql.gz文件有問題，用rar都不能打開！
服務器清空了，備份文件損壞。老話說的好，生命可貴，數據無價。對于一個程序員，這是天下最悲慘的事。在腦中浮現了N個臟話之后，懷著悲慘的心情，開始了慢慢的數據修復之路。任重而道遠啊。
先確定問題發生原因。因為是導入時MYSQL報錯#1064，自然的以為是SQL語句有問題。想查看SQL語句，發現備份文件打不開。當時還沒想到是文件有問題，還以為是非標準GZIP壓縮，不能被壓縮軟件識別，所以開始分析phpmyadmin代碼，想看看這個GZIP文件是如何生成的，如何解壓。但是phpmyadmin代碼太龐大，嵌套模塊太多，讀起來很浪費時間，所以嘗試了一下放棄，換用另一思路。考慮是否因為MYSQL和phpmyadmin版本兼容性問題，所以先嘗試替換MYSQL版本，從5.1最早版本到5.7最新版本，挑了幾個嘗試，都未果，于是嘗試替換phpmyadmin版本。在替換了幾個版本也都失敗以后，忽然發現新版的phpmyadmin導出的數據用winrar能打開，而我之前的打不開！恍然大悟，原來真是導出的數據出了問題！也就是說，是phpmyadmin本身的問題了。查看phpmyadmin更新文檔，在4.4.9更新日志里看見“- bug #4942 Export to gzip saves plain text under Chrome”。這這句話有兩個重點，一是說明4.4.9修復BUG了，二是說明這個BUG只在chrome瀏覽器下存在。為了進一步確認，分別用4.4.8和4.4.9測試了一下，結果IE下都正常，chrome下8導出異常9導出正常。好了，下一步拿出BC，對比一下兩個版本源碼，看看修改了什么地方，在“libraries\core.lib.php”發現一段代碼
$notChromeOrLessThan43 = PMA_USR_BROWSER_AGENT != 'CHROME' // see bug #4942
|| (PMA_USR_BROWSER_AGENT == 'CHROME' && PMA_USR_BROWSER_VER < 43);
if (strpos($mimetype, 'gzip') !== false && $notChromeOrLessThan43) {
header('Content-Encoding: gzip');
}
這是.9版修復的，看出來了吧，這個補丁只針對chrome43以后版本，作用就是不輸出HTTP頭GZIP。再對比兩個版本導出的數據，發現數據的后半部分是一樣的，區別只在前半部分，就是.8導出的數據前面一部分是解壓以后的，而.9的都是壓縮的。
找到問題原因，開始嘗試修復。這里走了很多彎路，因為在分析數據時受到了很多誤導，結果干了一宿一天。苦逼的過程自不必細說，那些成天查異常的兄弟們肯定都深有體會，只說結果吧。不說看似山，說了隔層紙，其實很簡單：GZIP文件并不是整體壓縮，而是分成一個一個數據塊壓縮并拼接起來的，輸出損壞的數據，單純是因為chrome在下載文件時，把第一個數據塊解壓了。后面的數據塊并沒有東，沒有損壞。這樣就簡單了，把解壓的那部分數據剪出來，通過GZIP算法壓縮，在粘回去，壓縮包就修復好了。
手工操作代碼數據比較麻煩，所以寫了個PHP小程序代勞，這里分享給大家。
竟然真有人搜索過來，那我詳細說說修復文件用法吧。用16進制編輯器打開待修復的數據文件，搜索代碼“1F 8B 08 00”第一次出現的位置，把$i這個變量的值改成搜到的位置，然后在$fi變量定義待修復文件名，$fo定義輸出文件名，在WEB頁執行這個PHP，處理完畢。
1F 8B 08 00（1F8B 0800） 標示是gzip壓縮文件的標識。??
