字型加密反爬也就是自定義字型反爬，通過呼叫自定義的ttf檔案來渲染網頁中的文字，而網頁中的文字不再是文字，而是相應的字型編碼，通過複製或者簡單的採集是無法採集到編碼後的文字內容！

上圖看真像：

原始碼截圖：

頁面中的效果：

如圖上面圖片所看到的，爬蟲是無法採集到編碼後的文字內容，這樣就起到了防爬的效果

講到這裡，細心的人會問，為什麼不把所有的內容都替換成編碼呢？應該影響載入和渲染速度！

我們知道，單純漢字就有好幾千個，如果全部放到自定義字型庫中的話，這個檔案會有灰常大，幾十兆是肯定有的了，那載入肯定很慢，更糟糕的是如此之多的字型需要瀏覽器去渲染，渲染也會非常慢。

為了解決這個問題，我們可以選擇只渲染少量的、部分的文字，假設50個字，那麼字型庫就會小到幾十K了，相當於一個小圖片而已。

但破解思路也很簡單，通過fonttools類工具將ttf檔案轉成ttx檔案開啟後，什麼都明白了！

ttx程式碼：

看到了嗎，ed12的編碼就是“是”字的unicode編碼，這樣一來，爬蟲只要把採集到""直接替換成“是”字就可以了，以此類推。

這可如何是好呢？

如果讓“是”字的編碼隨機變化，但字型資訊不變，瀏覽器渲染出來還是“是”字那不就完美了。

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

但還有可能被破解：還是跟ttx有關，雖然我們打亂了關鍵字的編碼順序，但是每個字對應的字型資訊是不變的，例如，“是”字一共有9劃，每一筆劃都有相應的x、y座標資訊，瀏覽器正是根據這些筆劃資訊渲染出對應的字的，看圖：

爬蟲先手動下載了一個ttf檔案，然後根據ttf檔案中的文字圖形位置再爬蟲程式碼中做一個對映，然後使用程式動態獲取到採集的每一篇文章，使用fonttools類工具來迴圈對比本地之前下載的標本中的字型資訊，對比一直，那就是某一個字，如此一來，反爬就輕鬆被破了。

再次升級：

既然爬蟲對比字型資訊，那我就把字型的資訊給你隨機了，讓字變形，這樣你就無法對比了，歐耶。看下變形後的圖片：

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

還有更為高階的反爬思路：

大概：基於微軟雅黑字型檔資訊，抽取其中的關鍵字的字型資訊，然後隨機生成上千套字型檔，同時做好字與編碼和字型檔檔案的mapping關係，持久化到資料庫，然後文章顯示時隨機從庫中查詢出一套字型檔，並把文章中的關鍵字替換成Unicode編碼！

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

除了這種技術性的對抗，我們還可以採用WAF進行防爬蟲，比如ShareWAF就有很好的防爬蟲能力。

最後，我想說的是：最好的方案，就是讓爬蟲採集的成本不斷增加，直到放棄，那麼反爬也就算那是成功了。