最近臨時受命，要針對采集我司網(wǎng)站的爬蟲進(jìn)行反制。雖然不太熟悉這個領(lǐng)域，但既然分到咱這兒了，那就上唄，有啥說的，誰讓咱是“全棧工程師”呢（牛逼吹的大了點(diǎn)）。
原本公司已經(jīng)有了一套字體反爬的機(jī)制，但效果還是不很理想?；艘恢艿臅r間進(jìn)行研究，最終在現(xiàn)有反爬基礎(chǔ)之上，總結(jié)了本文要講的方案。
說是終極方案，是有些吹牛了，大家都知道爬蟲和反爬之家的道高一尺魔高一丈的關(guān)系。但這個方案可以很大程度上可以增加普通爬蟲的采集成本，在不使用OCR的前提下，算是比較極致的方案了。
直接說重點(diǎn)吧！
1、掃盲：
字體反爬也就是自定義字體反爬，通過調(diào)用自定義的ttf文件來渲染網(wǎng)頁中的文字，而網(wǎng)頁中的文字不再是文字，而是相應(yīng)的字體編碼，通過復(fù)制或者簡單的采集是無法采集到編碼后的文字內(nèi)容！
上圖吧：
源碼截圖
頁面展示效果
如圖上面圖片所看到的，爬蟲是無法采集到編碼后的文字內(nèi)容，貌似起到了防爬的效果，呵呵，事實(shí)上這個只能防到簡單的爬蟲。一會我們再繼續(xù)講更深一層的防爬機(jī)制。
2、思路設(shè)計
講到這里，細(xì)心的人會問，為什么不把所有的內(nèi)容都替換成編碼呢？這個就涉及到加載和渲染速度的問題。
我們知道，單純漢字就有好幾千個，如果全部放到自定義字體庫中的話，這個文件會有灰常大，幾十兆是肯定有的了，那后果啥樣就很清楚了，加載肯定很慢，更糟糕的是如此之多的字體需要瀏覽器去渲染，那效果，OMG！（產(chǎn)品、運(yùn)營憤怒的小拳頭撲面而來）
好吧，這個時候就提現(xiàn)出我們高級程序的價值所在了（嗯、嗯，清清嗓子）。
為了解決這個問題，我們可以選擇只渲染少量的、部分的文字，假設(shè)50個字，那么字體庫就會小到幾十K了，相當(dāng)于一個小圖片而已，加上CDN加速之類的，歐耶，解決了。
如此簡單？No、No，表著急，童鞋。50個字兒呢可不是隨便隨便選擇的，要選擇那些爬蟲采集不到就會很大改變整個語句的語義的詞，直接點(diǎn)吧，也就是量詞、否定詞之類的。如原文“我有一頭小毛驢，我從來都不騎”，我們把其中的“一”、“不”放到我們的自定義字庫中，這樣一來，爬蟲采集到的就是“我有?頭小毛驢，我從來都?騎”，OMG，這結(jié)果完美。嘿嘿，如果加上阿拉伯?dāng)?shù)字就更完美了，“獵豹以時速????公里/小時的速度奔跑在非洲的大草原上”，同學(xué)，請問時速多少來著？哈哈哈，好爽.......
3、PK升級
“老李、老李，不行了，不行了?！边\(yùn)營扯著脖子喊到。
“什么玩意不行了，說清楚，一驚一乍的！”
“反爬、反爬不行了，數(shù)據(jù)被人采到了！”運(yùn)營氣喘吁吁的.....
哎媽呀，貌似方案挺完美的嘍，怎么就輕易被爬蟲采集到了呢？
Why？Fuck，還沒開心一分鐘呢，就被狠狠打臉了，怎么回事呢？
貌似自定義字體已經(jīng)不能被采集到了，但事實(shí)可沒這么簡單呀，要知道，反爬工程師面對的可是N多個大牛群毆的狀態(tài)，什么神箭手、Gooseeker，隨便一個都是谷歌工程師出身的（買糕的，還讓人活不啦）。
來，看看他們是怎么破的。
思路很簡單，通過fonttools（python工具）將ttf文件轉(zhuǎn)成ttx文件打開后，什么都明白了！
ttx代碼
看到了嗎，ed12的編碼就是“是”字的unicode編碼，這樣一來，爬蟲只要把采集到"?"直接替換成“是”字就可以了，以此類推，然后，沒有然后了，啥都被采集到了，白忙了半天（我艸%#*%$##%^_+!>.........）。
這可如何是好呢？表急，辦法總是有的！
如果讓“是”字的編碼隨機(jī)變化，但字體信息不變，瀏覽器渲染出來還是“是”字那不就完美了，哎媽呀，太聰明了，對就這樣干。
于是，每個網(wǎng)頁加載的時候，都隨機(jī)加載了一套字體庫，字體庫的內(nèi)容還是50個字，但每個字的順序編碼都是變化的，爬蟲也就無法用直接替換的方式進(jìn)行采集了。
4、PK再次升級
“老李、老李，不行了，不行了?！边\(yùn)營又扯著脖子喊著。（我tmd真想掐死他）
“說，咋了！”
“反爬、反爬又不行了，又被人采到了！”運(yùn)營無奈的看著我.....
好吧，兵來將擋水來土掩，還能咋滴，先看看情況再說。
原來，還是跟ttx有關(guān)，雖然我們打亂了關(guān)鍵字的編碼順序，但是每個字對應(yīng)的字體信息是不變的，例如，“是”字一共有9劃，每一筆劃都有相應(yīng)的x、y坐標(biāo)信息，瀏覽器正是根據(jù)這些筆劃信息渲染出對應(yīng)的字的，看圖：
爬蟲工程師先手動下載了一個ttf文件，然后根據(jù)ttf文件中的文字圖形位置再爬蟲代碼中做一個映射，然后使用程序動態(tài)獲取到采集的每一篇文章，使用fonttools來循環(huán)對比本地之前下載的標(biāo)本中的字體信息，對比一直，那就是某一個字，如此一來，反爬就輕松被破了。
細(xì)節(jié)可參考下面文章，我就不啰嗦了！
Python爬蟲雜記 - 字體文件反爬（二）?www.itdecent.cn
那怎么辦呢？只要肯用心，方法總比困難多呀！
既然你對比字體信息，ok，那我就把字型的信息給你隨機(jī)了，讓字變形，這樣你就無法對比了，歐耶。看下變形后的圖片：
變形后的字體，即便是下載了當(dāng)前文章的字庫，也需要手動去做字體和字的映射，那么多文章呢，手工匹配，顯然是不可能的了。事實(shí)上，我們準(zhǔn)備了幾千套的字體，用于應(yīng)對爬蟲的采集，每次刷新文章，字體庫就會更換，每篇文章的字體庫都不一樣，但是替換的文字都是一樣的，這樣以來，爬蟲采集的難度就越來越高了。
反爬本來就是不歸路，沒有終點(diǎn)，有反爬就有反反爬；
最好的方案，就是讓爬蟲采集的成本不斷增加，直到放棄，那么反爬也就算那是成功了。
至此，字體反爬策略已經(jīng)基本達(dá)到了頂峰。
那么，這是終點(diǎn)嗎？是終極方案嗎？
OCR一臉奸笑的走來........
備注：
關(guān)于這個方案具體業(yè)務(wù)代碼涉及公司利益，就不公布了。而反反爬的文章網(wǎng)上已經(jīng)挺多了，就不羅列了！
大概思路：基于微軟雅黑字庫信息，抽取其中的關(guān)鍵字的字體信息，然后隨機(jī)生成上千套字庫，同時做好字與編碼和字庫文件的mapping關(guān)系，持久化到數(shù)據(jù)庫，然后文章顯示時隨機(jī)從庫中查詢出一套字庫，并把文章中的關(guān)鍵字替換成Unicode編碼，over！
QQ: 446089152
