網頁抓取數據的救星：HTML廣告移除工具實戰應用指南

信息爆炸的互聯網時代，網絡爬蟲如同一把神奇的鑰匙，幫助我們打開海量網頁內容的大門。然而，在實際操作過程中，不規范的網頁格式、紛繁復雜的干擾元素，特別是那些占據屏幕空間、影響閱讀體驗的廣告，往往成為獲取高質量數據的一大阻礙。因此，一款專為網絡爬蟲設計的HTML廣告移除神器顯得尤為重要。這款工具利用強大的HtmlAgilityPack庫，能夠迅速而精準地識別并剔除帶有class='ad'屬性的廣告標簽，讓抓取到的頁面內容回歸其最純粹的本質。

代碼執行效果如圖：

調用代碼：

// 假設這是從某個網頁上抓取的包含廣告的“混亂”HTML文本

string clutteredHtml = @"<html><head><title>網頁標題</title></head><body><div class='header'><h1>網站標題</h1></div><div class='nav'><ul><li><a href='#'>首頁</a></li><li><a href='#'>關于我們</a></li><li><a href='#'>聯系我們</a></li></ul></div><div class='content'><p>正文內容1...</p><p>正文內容2...</p><p>正文內容3...</p></div><div class='ad'>廣告1...</div><div class='ad'>廣告2...</div><div class='ad'>廣告3...</div><div class='footer'><p>© 2023 版權所有</p></div></body></html>";

// 使用廣告移除功能對抓取的“臟亂差”HTML進行深度清理

string polishedHtml = ScrubAndRemoveAds(clutteredHtml);

// 廣告移除及HTML內容凈化的具體實現方法

public static string ScrubAndRemoveAds(string messyHtmlContent)

{

// 創建一個可以解析和理解HTML結構的對象，并載入抓取的HTML文本

var htmlParser = new HtmlDocument();

htmlParser.LoadHtml(messyHtmlContent);

// 掃描整個HTML文檔，找到所有標記為廣告（class屬性值為"ad"）的部分并刪除

foreach (var adElement in htmlParser.DocumentNode.SelectNodes("//div[@class='ad']"))

{

adElement.Remove(); // 刪除廣告區域

}

// 返回已經清除廣告后的清爽HTML文本

return htmlParser.DocumentNode.OuterHtml;

}

這個代碼有效地解決了網絡爬蟲在抓取數據時遇到的廣告難題。無論對于追求極致閱讀體驗的個人用戶，還是力求優化數據質量、節省資源成本的企業級用戶，這個小工具都展現出了卓越的價值。無需繁瑣的操作流程，一鍵即可輕松擺脫廣告干擾，讓你獲得高質量、純凈的網頁內容。無論是單獨處理單個網頁，還是批量清洗大量的抓取數據，此工具都能得心應手，為您提供高效便捷的網絡數據整理解決方案。朋友們，喜歡就拿去吧，別忘記關注我：代碼領域的詩人XY，我是一個樂于分享的人。樂于將自己的知識和經驗分享給朋友們，幫助你們解決問題，啟發你們的思考。我相信，只有通過分享和交流，我們才能不斷進步，才能不斷創新。

源：麥叔編程

作者：麥叔

代碼評審會上，氣氛有點緊張！

羅老師正在看張三的代碼，并指出了一個問題：

你這個API，在用戶沒登錄的情況下，應該返回401，不應該返回200。要遵守HTTP協議的規范。

張三對此不以為然的說：

我們約定了都返回200的，具體的錯誤信息放在返回的JSON里。我又沒有違法，不能為了規范而規范吧。

羅老師竟無言以對。他趕快去查看Facebook，谷歌等業界大亨的做法，可是他們的做法也不統一。到底要不要遵守HTTP Status Code呢？

聽我細細道來，本文涵蓋：

HTTP和Rest API的基本知識
Rest API使用HTTP Status Code的最佳實踐
Rest API的錯誤處理最佳實踐

HTT協議和Restful API

你很可能已經熟悉HTTP和Restful API。不管你是否熟悉，讓我們用1分鐘的時間來簡單回顧一下：

HTTP協議定義了瀏覽器和網頁服務器之間的交互過程。它的核心概念就2個：

Request - 瀏覽器要打開一個網頁，給服務器發送一個Request，里面包含了網址，參數，及其他信息。
Response - 服務器返回一Response給瀏覽器，包括狀態碼，比如200表示成功，4xx和5xx都表示不同類型的失敗，以及網頁的具體內容。

有了標準的協議就好辦了，任何人都可以開發瀏覽器出來，只要你寫的軟件都能遵守這個協議就行。我記得我研究生時候一門課的大作業就是開發一個簡易的瀏覽器。

控制了瀏覽器，就控制了網絡流量，就不怕沒錢賺了，所以各大廠商都在努力推廣自己的瀏覽器，就有了IE, Edge，Chrome，FireFox，QQ瀏覽器，以及360瀏覽器等。有的瀏覽器又好用又文明，有的瀏覽器很流氓，有的瀏覽器不遵守協議，讓開發人員恨得牙根癢癢。

Rest API說白了就是一個網頁地址，不過它只返回JSON或者XML格式的數據，而不是HTML網頁。

HTTP Status Code

每個HTTP的Response都包含一個Status Code，表示請求的狀態，是成功，還是失敗，失敗的原因是什么等等。

HTTP的Status Code一共有幾十個，詳細列表可以查看相關標準。但絕大部分人平時只會接觸到最常見的少于10個的代碼：

代碼	含義	說明
200	請求成功
201	創建成功	專門用于創建新的記錄的時候
301	永久重定向	網址永久變更成另外一個網址
302	臨時重定向	網址臨時變更成另外一個網址
400	無效的請求	請求的網址無效等
401	沒有登錄	需要登錄才能訪問
403	沒有權限	雖然登陸了，但是沒有權限
404	請求資源不存在	請求的東西不存在，比如某個人的信息
500	服務器端錯誤	服務器端發生了錯誤

有了這套標準，處理請求的程序首先根據狀態碼判定請求是否成功，然后做相應的處理。

Rest API是否應該遵循HTTP Status Code

Rest API理論上也應該遵守HTTP的規定，根據不同的情況，返回相應的狀態碼。但理論只是理論，大家對此的認識是不同的。基本上分成了兩派：

200派：不管對錯，一律返回200，在返回的JSON中再具體指明錯誤的原因。
正規派：另外一派堅持使用規范的HTTP狀態碼。如果是沒有登錄，就返回401，如果是沒權限就返回403。

這兩派都有重量級的公司參與，比如FaceBook就是200派，而Google, Twilio等是正規派：

200派的理由很簡單：反正我都需要處理返回的JSON，干脆我就把具體狀態寫在JSON里面，就不用管HTTP的狀態碼了，都用200好了。你看Facebook這樣的大公司都用200了。

而正規派的人的理由就顯得略微有點不正規，大部分人說：因為這是規范。Rest API是基于HTTP的，就應該遵守HTTP的狀態碼。

我是正規派的人，但我也覺得上面的理由有點薄弱。到底有什么好處？在什么情況下有好處？拿點實實在在的好處或者理由來？

首先，這肯定不是一個非黑即白的問題，200派和正規派都是可行的。只要API的提供者和請求者協調好，都不會帶來很大的問題。但是我們仍然應該適度遵守HTTP的狀態碼。實實在在的理由如下：

作為一個開放的API，可能會被不同的消費者使用。為了最大限度的適應不同的消費者，最好的方法就是大家遵守一個業界規范，那就是HTTP的狀態碼。下面的2點都是舉例來證明第1點。
很多JavaScript框架設計上就是基于HTTP協議的，根據不同的狀態碼做不同的處理，比如下面的JQuery的Ajax請求就可以根據HTTP的狀態碼執行不同的代碼塊：$.ajax({
url: 'https://maishucode.com/page/2',
type: 'GET',
success: function(data){
alert('成功返回'); //返回2xx，執行這個代碼塊
},
error: function(data) {
alert('出錯啦!'); //返回4xx或者5xx，執行這個代碼塊
}
});如果API沒有正確的使用HTTP狀態碼，上面的代碼中需要手動解析JSON里面的狀態碼，再做分支的判斷。
為了通用，很多中間系統根據狀態碼來分析系統的訪問數據，比如ELK可以根據HTTP的狀態碼分析有多少成功的請求，多少失敗的請求。如果都統一返回200，那么就沒法分析出：有哪些未登錄的訪問，有哪些未授權的訪問，有多少服務器端錯誤等。但是這里有利也有弊，有些流氓的中間系統會根據狀態碼劫持網頁，比如有些瀏覽器和路由器就會劫持404網頁，顯示它自己的廣告頁。具體做法是：當路由器或者瀏覽器發現請求返回的是404，它們就會丟掉Response，而顯示一個自己的廣告網頁。這種劫持是非常無恥的行為。404也是服務器返回給請求者的一個消息，網頁仍然可能包含重要的內容。再說了，不管什么消息，中間人都不應該劫持。

總結一下，我支持使用合理的HTTP狀態碼的。原因上面已經說了。但是慎用404，因為可能會被眾多流氓劫持。但是還有兩點:
不要濫用HTTP狀態碼，基本上就用我前面列舉出來的那些就夠了。
使用HTTP狀態碼后，仍然需要使用和業務相關的狀態碼。這就是下面要說的。

Rest API的錯誤處理最佳實踐

使用了HTTP狀態碼以后，讓API符合了一定的標準，這很好。但HTTP狀態碼不能涵蓋我們具體的業務場景，我們仍然需要定義和業務場景相對應的錯誤碼。下面我推薦一個錯誤處理的返回格式，舉例如下：

{ "status":403,
   "error": {     
      "code":'40041',      
      "message":"用戶缺少訪問特工名單權限",     
      "moreInfo":"https://maishucode.com/errors/40041", 
      "traceId":"9527"
     }, 
   "data":{
  }
}

下面是對每個字段的解釋：

status: HTTP狀態碼，不能為空，必須和HTTP header中的狀態碼一致。
code: 具體業務代碼，可以為空。這里需要技術人員和業務人員一起定義一套錯誤代碼規則。
message: 對錯誤信息的簡單解釋
moreInfo: 對錯誤信息的詳細解釋的網址。包含錯誤的詳細解釋，可能的原因，如何修正等。
traceId: 通過這個字段可以去日志文件中查找和本次操作相關的日志。
data: 存放具體的業務數據。

我要說的說完了！雖然這沒有絕對的對錯，但是符合良好的規范，提供充分的信息給調用用肯定是沒錯的。你覺得呢？在留言區留下你的意見吧！

家好，今天給大家介紹一款，jquery實現的，在網頁中一鍵返回頂部的火箭發射特效源碼（圖1）。送給大家哦，獲取方式在本文末尾。

圖1

當頁面位置在頂部的時候，火箭圖標是不會出現的，只有在下拉過程中，火箭會以陰影的方式出現，將鼠標放上去后，火箭才會出現。（圖2）

圖2

點擊火箭，火箭圖標就會有發射效果，并且網頁也會回到頂部（圖3）

圖3

代碼完整，需要的朋友可以下載學習（圖4）

圖4

本源碼編碼：10145，需要的朋友，點擊下面的鏈接后，搜索10145，即可獲取。

就愛UI - 分享UI設計的點點滴滴

在線咨詢

上一篇：前端入門-html 表單控件使用
下一篇：HTML使用Canvas繪制動畫時鐘

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商