整合營銷服務商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
信息爆炸的互聯(lián)網(wǎng)時代，網(wǎng)絡爬蟲如同一把神奇的鑰匙，幫助我們打開海量網(wǎng)頁內(nèi)容的大門。然而，在實際操作過程中，不規(guī)范的網(wǎng)頁格式、紛繁復雜的干擾元素，特別是那些占據(jù)屏幕空間、影響閱讀體驗的廣告，往往成為獲取高質(zhì)量數(shù)據(jù)的一大阻礙。因此，一款專為網(wǎng)絡爬蟲設計的HTML廣告移除神器顯得尤為重要。這款工具利用強大的HtmlAgilityPack庫，能夠迅速而精準地識別并剔除帶有class='ad'屬性的廣告標簽，讓抓取到的頁面內(nèi)容回歸其最純粹的本質(zhì)。
代碼執(zhí)行效果如圖：
調(diào)用代碼：
// 假設這是從某個網(wǎng)頁上抓取的包含廣告的“混亂”HTML文本
string clutteredHtml = @"<html><head><title>網(wǎng)頁標題</title></head><body><div class='header'><h1>網(wǎng)站標題</h1></div><div class='nav'><ul><li><a href='#'>首頁</a></li><li><a href='#'>關于我們</a></li><li><a href='#'>聯(lián)系我們</a></li></ul></div><div class='content'><p>正文內(nèi)容1...</p><p>正文內(nèi)容2...</p><p>正文內(nèi)容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內(nèi)容凈化的具體實現(xiàn)方法
public static string ScrubAndRemoveAds(string messyHtmlContent)
{
// 創(chuàng)建一個可以解析和理解HTML結構的對象，并載入抓取的HTML文本
var htmlParser = new HtmlDocument();
htmlParser.LoadHtml(messyHtmlContent);
// 掃描整個HTML文檔，找到所有標記為廣告（class屬性值為"ad"）的部分并刪除
foreach (var adElement in htmlParser.DocumentNode.SelectNodes("//div[@class='ad']"))
{
adElement.Remove(); // 刪除廣告區(qū)域
}
// 返回已經(jīng)清除廣告后的清爽HTML文本
return htmlParser.DocumentNode.OuterHtml;
}
這個代碼有效地解決了網(wǎng)絡爬蟲在抓取數(shù)據(jù)時遇到的廣告難題。無論對于追求極致閱讀體驗的個人用戶，還是力求優(yōu)化數(shù)據(jù)質(zhì)量、節(jié)省資源成本的企業(yè)級用戶，這個小工具都展現(xiàn)出了卓越的價值。無需繁瑣的操作流程，一鍵即可輕松擺脫廣告干擾，讓你獲得高質(zhì)量、純凈的網(wǎng)頁內(nèi)容。無論是單獨處理單個網(wǎng)頁，還是批量清洗大量的抓取數(shù)據(jù)，此工具都能得心應手，為您提供高效便捷的網(wǎng)絡數(shù)據(jù)整理解決方案。朋友們，喜歡就拿去吧，別忘記關注我：代碼領域的詩人XY，我是一個樂于分享的人。樂于將自己的知識和經(jīng)驗分享給朋友們，幫助你們解決問題，啟發(fā)你們的思考。我相信，只有通過分享和交流，我們才能不斷進步，才能不斷創(chuàng)新。
源：麥叔編程
作者：麥叔
代碼評審會上，氣氛有點緊張！
羅老師正在看張三的代碼，并指出了一個問題：
你這個API，在用戶沒登錄的情況下，應該返回401，不應該返回200。要遵守HTTP協(xié)議的規(guī)范。
張三對此不以為然的說：
我們約定了都返回200的，具體的錯誤信息放在返回的JSON里。我又沒有違法，不能為了規(guī)范而規(guī)范吧。
羅老師竟無言以對。他趕快去查看Facebook，谷歌等業(yè)界大亨的做法，可是他們的做法也不統(tǒng)一。到底要不要遵守HTTP Status Code呢？
聽我細細道來，本文涵蓋：
你很可能已經(jīng)熟悉HTTP和Restful API。不管你是否熟悉，讓我們用1分鐘的時間來簡單回顧一下：
HTTP協(xié)議定義了瀏覽器和網(wǎng)頁服務器之間的交互過程。它的核心概念就2個：
有了標準的協(xié)議就好辦了，任何人都可以開發(fā)瀏覽器出來，只要你寫的軟件都能遵守這個協(xié)議就行。我記得我研究生時候一門課的大作業(yè)就是開發(fā)一個簡易的瀏覽器。
控制了瀏覽器，就控制了網(wǎng)絡流量，就不怕沒錢賺了，所以各大廠商都在努力推廣自己的瀏覽器，就有了IE, Edge，Chrome，F(xiàn)ireFox，QQ瀏覽器，以及360瀏覽器等。有的瀏覽器又好用又文明，有的瀏覽器很流氓，有的瀏覽器不遵守協(xié)議，讓開發(fā)人員恨得牙根癢癢。
Rest API說白了就是一個網(wǎng)頁地址，不過它只返回JSON或者XML格式的數(shù)據(jù)，而不是HTML網(wǎng)頁。
每個HTTP的Response都包含一個Status Code，表示請求的狀態(tài)，是成功，還是失敗，失敗的原因是什么等等。
HTTP的Status Code一共有幾十個，詳細列表可以查看相關標準。但絕大部分人平時只會接觸到最常見的少于10個的代碼：
代碼 | 含義 | 說明 |
200 | 請求成功 | |
201 | 創(chuàng)建成功 | 專門用于創(chuàng)建新的記錄的時候 |
301 | 永久重定向 | 網(wǎng)址永久變更成另外一個網(wǎng)址 |
302 | 臨時重定向 | 網(wǎng)址臨時變更成另外一個網(wǎng)址 |
400 | 無效的請求 | 請求的網(wǎng)址無效等 |
401 | 沒有登錄 | 需要登錄才能訪問 |
403 | 沒有權限 | 雖然登陸了，但是沒有權限 |
404 | 請求資源不存在 | 請求的東西不存在，比如某個人的信息 |
500 | 服務器端錯誤 | 服務器端發(fā)生了錯誤 |
有了這套標準，處理請求的程序首先根據(jù)狀態(tài)碼判定請求是否成功，然后做相應的處理。
Rest API理論上也應該遵守HTTP的規(guī)定，根據(jù)不同的情況，返回相應的狀態(tài)碼。但理論只是理論，大家對此的認識是不同的。基本上分成了兩派：
這兩派都有重量級的公司參與，比如FaceBook就是200派，而Google, Twilio等是正規(guī)派：
200派的理由很簡單：反正我都需要處理返回的JSON，干脆我就把具體狀態(tài)寫在JSON里面，就不用管HTTP的狀態(tài)碼了，都用200好了。你看Facebook這樣的大公司都用200了。
而正規(guī)派的人的理由就顯得略微有點不正規(guī)，大部分人說：因為這是規(guī)范。Rest API是基于HTTP的，就應該遵守HTTP的狀態(tài)碼。
我是正規(guī)派的人，但我也覺得上面的理由有點薄弱。到底有什么好處？在什么情況下有好處？拿點實實在在的好處或者理由來？
首先，這肯定不是一個非黑即白的問題，200派和正規(guī)派都是可行的。只要API的提供者和請求者協(xié)調(diào)好，都不會帶來很大的問題。但是我們?nèi)匀粦撨m度遵守HTTP的狀態(tài)碼。實實在在的理由如下：
使用了HTTP狀態(tài)碼以后，讓API符合了一定的標準，這很好。但HTTP狀態(tài)碼不能涵蓋我們具體的業(yè)務場景，我們?nèi)匀恍枰x和業(yè)務場景相對應的錯誤碼。下面我推薦一個錯誤處理的返回格式，舉例如下：
{ "status":403,
"error": {
"code":'40041',
"message":"用戶缺少訪問特工名單權限",
"moreInfo":"https://maishucode.com/errors/40041",
"traceId":"9527"
},
"data":{
}
}下面是對每個字段的解釋：
我要說的說完了！雖然這沒有絕對的對錯，但是符合良好的規(guī)范，提供充分的信息給調(diào)用用肯定是沒錯的。你覺得呢？在留言區(qū)留下你的意見吧！
圖1
圖2
圖3
圖4
就愛UI - 分享UI設計的點點滴滴
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
