服務器中毒太頭疼了，網站被加惡意代碼很常見，一般用正則批量替換能搞定。但坑爹的是有些用戶為了防下載Access數據庫，把.mdb改成.asp后綴，結果病毒也往.asp文件里塞代碼，連帶這個假asp真數據庫的文件也被感染了。
更慘的是，批量替換時一處理這文件，它就損壞，打都打不開，或者能打開但刪不了代碼，導致所有連數據庫的頁面全報毒，必須解決。
作為虛擬主機黨，這種情況真不少見，黑客永遠快一步……
解決辦法：
1. 批量替換前先備份文件（很多編輯器自帶備份功能）。換完如果網站正常就OK；要是出錯，大概率是數據庫壞了，直接拿備份里的原文件替換回去就行。
2. 替換前先搜一下所有*.asp文件，把體積超過200K的單獨拎出來備份——這種多半是大容量數據庫，別亂動。
3. 上面兩步搞完，基本只剩數據庫文件還有毒。我當時也懵了，后來靈機一動：既然改名成.asp都能跑，那我再改回.mdb是不是也能用？一試，還真行！
然后習慣性壓縮了一下數據庫，結果打開一看，臥槽！惡意代碼沒了！原來壓縮過程自動清掉了那些垃圾數據，問題徹底解決。
服務器一般不裝Access軟件，但有引擎支持，所以我寫了個VBS小工具：ACCESS數據庫壓縮.vbs，直接在服務器上跑，一鍵壓縮修復，完美收工。
更慘的是，批量替換時一處理這文件，它就損壞，打都打不開，或者能打開但刪不了代碼，導致所有連數據庫的頁面全報毒，必須解決。
作為虛擬主機黨，這種情況真不少見，黑客永遠快一步……
解決辦法：
1. 批量替換前先備份文件（很多編輯器自帶備份功能）。換完如果網站正常就OK；要是出錯，大概率是數據庫壞了，直接拿備份里的原文件替換回去就行。
2. 替換前先搜一下所有*.asp文件，把體積超過200K的單獨拎出來備份——這種多半是大容量數據庫，別亂動。
3. 上面兩步搞完，基本只剩數據庫文件還有毒。我當時也懵了，后來靈機一動：既然改名成.asp都能跑，那我再改回.mdb是不是也能用？一試，還真行！
然后習慣性壓縮了一下數據庫，結果打開一看，臥槽！惡意代碼沒了！原來壓縮過程自動清掉了那些垃圾數據，問題徹底解決。
服務器一般不裝Access軟件，但有引擎支持，所以我寫了個VBS小工具：ACCESS數據庫壓縮.vbs，直接在服務器上跑，一鍵壓縮修復，完美收工。