最近臨時受命，要針對采集我司網站的爬蟲進行反制。雖然不太熟悉這個領域，但既然分到咱這兒了，那就上唄，有啥說的，誰讓咱是“全棧工程師”呢（牛逼吹的大了點）。

原本公司已經有了一套字體反爬的機制，但效果還是不很理想。花了一周的時間進行研究，最終在現有反爬基礎之上，總結了本文要講的方案。

說是終極方案，是有些吹牛了，大家都知道爬蟲和反爬之家的道高一尺魔高一丈的關系。但這個方案可以很大程度上可以增加普通爬蟲的采集成本，在不使用OCR的前提下，算是比較極致的方案了。

直接說重點吧！

1、掃盲：

字體反爬也就是自定義字體反爬，通過調用自定義的ttf文件來渲染網頁中的文字，而網頁中的文字不再是文字，而是相應的字體編碼，通過復制或者簡單的采集是無法采集到編碼后的文字內容!

上圖吧：

源碼截圖

頁面展示效果

如圖上面圖片所看到的，爬蟲是無法采集到編碼后的文字內容，貌似起到了防爬的效果，呵呵，事實上這個只能防到簡單的爬蟲。一會我們再繼續講更深一層的防爬機制。

2、思路設計

講到這里，細心的人會問，為什么不把所有的內容都替換成編碼呢？這個就涉及到加載和渲染速度的問題。

我們知道，單純漢字就有好幾千個，如果全部放到自定義字體庫中的話，這個文件會有灰常大，幾十兆是肯定有的了，那后果啥樣就很清楚了，加載肯定很慢，更糟糕的是如此之多的字體需要瀏覽器去渲染，那效果，OMG！（產品、運營憤怒的小拳頭撲面而來）

好吧，這個時候就提現出我們高級程序的價值所在了（嗯、嗯，清清嗓子）。

為了解決這個問題，我們可以選擇只渲染少量的、部分的文字，假設50個字，那么字體庫就會小到幾十K了，相當于一個小圖片而已，加上CDN加速之類的，歐耶，解決了。

如此簡單？No、No，表著急，童鞋。50個字兒呢可不是隨便隨便選擇的，要選擇那些爬蟲采集不到就會很大改變整個語句的語義的詞，直接點吧，也就是量詞、否定詞之類的。如原文“我有一頭小毛驢，我從來都不騎”，我們把其中的“一”、“不”放到我們的自定義字庫中，這樣一來，爬蟲采集到的就是“我有?頭小毛驢，我從來都?騎”，OMG，這結果完美。嘿嘿，如果加上阿拉伯數字就更完美了，“獵豹以時速????公里/小時的速度奔跑在非洲的大草原上”，同學，請問時速多少來著？哈哈哈，好爽.......

3、PK升級

“老李、老李，不行了，不行了。”運營扯著脖子喊到。

“什么玩意不行了，說清楚，一驚一乍的！”

“反爬、反爬不行了，數據被人采到了！”運營氣喘吁吁的.....

哎媽呀，貌似方案挺完美的嘍，怎么就輕易被爬蟲采集到了呢？

Why？Fuck，還沒開心一分鐘呢，就被狠狠打臉了，怎么回事呢？

貌似自定義字體已經不能被采集到了，但事實可沒這么簡單呀，要知道，反爬工程師面對的可是N多個大牛群毆的狀態，什么神箭手、Gooseeker，隨便一個都是谷歌工程師出身的（買糕的，還讓人活不啦）。

來，看看他們是怎么破的。

思路很簡單，通過fonttools（python工具）將ttf文件轉成ttx文件打開后，什么都明白了！

ttx代碼

看到了嗎，ed12的編碼就是“是”字的unicode編碼，這樣一來，爬蟲只要把采集到"?"直接替換成“是”字就可以了，以此類推，然后，沒有然后了，啥都被采集到了，白忙了半天（我艸%#*%$##%^_+!>.........）。

這可如何是好呢？表急，辦法總是有的！

如果讓“是”字的編碼隨機變化，但字體信息不變，瀏覽器渲染出來還是“是”字那不就完美了，哎媽呀，太聰明了，對就這樣干。

于是，每個網頁加載的時候，都隨機加載了一套字體庫，字體庫的內容還是50個字，但每個字的順序編碼都是變化的，爬蟲也就無法用直接替換的方式進行采集了。

4、PK再次升級

“老李、老李，不行了，不行了。”運營又扯著脖子喊著。（我tmd真想掐死他）

“說，咋了！”

“反爬、反爬又不行了，又被人采到了！”運營無奈的看著我.....

好吧，兵來將擋水來土掩，還能咋滴，先看看情況再說。

原來，還是跟ttx有關，雖然我們打亂了關鍵字的編碼順序，但是每個字對應的字體信息是不變的，例如，“是”字一共有9劃，每一筆劃都有相應的x、y坐標信息，瀏覽器正是根據這些筆劃信息渲染出對應的字的，看圖：

爬蟲工程師先手動下載了一個ttf文件，然后根據ttf文件中的文字圖形位置再爬蟲代碼中做一個映射，然后使用程序動態獲取到采集的每一篇文章，使用fonttools來循環對比本地之前下載的標本中的字體信息，對比一直，那就是某一個字，如此一來，反爬就輕松被破了。

細節可參考下面文章，我就不啰嗦了！

Python爬蟲雜記 - 字體文件反爬（二）?www.jianshu.com

那怎么辦呢？只要肯用心，方法總比困難多呀！

既然你對比字體信息，ok，那我就把字型的信息給你隨機了，讓字變形，這樣你就無法對比了，歐耶。看下變形后的圖片：

變形后的字體，即便是下載了當前文章的字庫，也需要手動去做字體和字的映射，那么多文章呢，手工匹配，顯然是不可能的了。事實上，我們準備了幾千套的字體，用于應對爬蟲的采集，每次刷新文章，字體庫就會更換，每篇文章的字體庫都不一樣，但是替換的文字都是一樣的，這樣以來，爬蟲采集的難度就越來越高了。

反爬本來就是不歸路，沒有終點，有反爬就有反反爬；

最好的方案，就是讓爬蟲采集的成本不斷增加，直到放棄，那么反爬也就算那是成功了。

至此，字體反爬策略已經基本達到了頂峰。

那么，這是終點嗎？是終極方案嗎？

OCR一臉奸笑的走來........

備注：

關于這個方案具體業務代碼涉及公司利益，就不公布了。而反反爬的文章網上已經挺多了，就不羅列了！

大概思路：基于微軟雅黑字庫信息，抽取其中的關鍵字的字體信息，然后隨機生成上千套字庫，同時做好字與編碼和字庫文件的mapping關系，持久化到數據庫，然后文章顯示時隨機從庫中查詢出一套字庫，并把文章中的關鍵字替換成Unicode編碼，over!

總結

以上是生活随笔為你收集整理的反爬终极方案总结---字体反爬的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。