【新聞挖掘工坊：第 2 篇】Google News RSS 祕密通道：怎麼抓新聞連結？

開啟 RSS 密道的初衷

那天，我們在討論如何快速收集海量新聞時，無意間發現 Google News 提供的 RSS 功能就像一條隱藏的捷徑。這條捷徑並非一般人手機、電腦上常用的新聞推播，而是基於開放標準的資訊分發管道。對於想要系統化蒐集新聞的我們來說，RSS 就像從地圖上挖出了一條秘密通道，能讓我們不必再一條條打開網站。

當我們第一次點入 RSS 的連結，映入眼簾的是一長串 XML 格式的內容，裡頭包含著最新的標題、摘要、連結與發佈時間。雖然對一般使用者而言顯得有些「科學怪人」，但對資深的數據偵探來說，這些條目就是每天新鮮出爐的「情報清單」。於是，我們決定用程式自動去讀這份清單，替後續的大規模分析打下基礎。

更妙的是，RSS 這條密道還有一個好處：它不需要登入、沒有人機介面互動，就能定時更新。只要我們把 RSS 的網址丟到程式中，它便會在固定間隔自動拉取最新條目。如此一來，我們不必再手動刷網頁，也能將所有符合關鍵字的新聞一網打盡，讓自動化腳本化身最貼心的「情報小幫手」。

RSS 的力量：從資訊洪流中擷取重點

在正式投入程式撰寫之前，我們先思考了一件事：每天媒體發出的新聞量龐大，要是從各個網站手動複製標題和連結，肯定力不從心。RSS 的出現，就像在資訊洪流中架設了一台水車，只要你預先定義好水車的濾網，源源不絕的資料就會被自動收集下來。

接著，我們將這條 RSS 線路視為「每日固定包裹」，包裹裡裝著符合「台灣警政」等條件的文章摘要。每次程式啟動，它就會向那條管道發訊號，取回最新的條目列表。從 JSON 轉成 DataFrame，再把每一列的 link 欄位存入清單，就是我們蒐集工作的第一步。這樣的做法不僅穩定，也避免了直接爬取所有媒體首頁所帶來的反爬風險。

值得一提的是，RSS 還能大幅減少網路流量與運算負擔。一般爬蟲要下載整頁 HTML，解析後再擷取標題與摘要，十分耗時。使用 RSS，我們只需要處理輕量化的 XML 結構，就能把重點欄位提取出來，真正做到「按需取材」，讓程式運行更有效率，也能更快地進入下一個分析階段。

when="1y" 的陷阱：粗篩無法滿足需求

帶著對 RSS 的信心，我們首先嘗試了 pygooglenews 套件提供的 when="1y" 參數，想要一次抓取過去一整年的新聞。理論上，一年內所有與警政有關的條目都能被篩出，十分酷炫；可實際來看，方法「太過粗糙」。

當我們把抓下來的海外媒體、去年下半年更新的新聞也收進來時，才發現一個問題：想精準只取 2024 年 1 月到 4 月的內容，when="1y" 顯然不夠精準。去年 5、6 月的舊聞、還有一些其他語言來源，統統像硬幣上的雜訊，混淆了我們真正想要的資訊。

這時候，程式就像拿著一把大網，撈到一堆小魚小蝦，卻漏掉了那幾條稀有的魚類。我們意識到，只依賴「過去一年」的粗篩參數，反倒會讓後續清洗變得冗長，還可能把錯誤數據當成真材料保留下來。因此，必須找到能更精準鎖定特定時段的方法，才能讓蒐集結果更具品質。

嘗試與失敗：字串檢查與時間解析的教訓

在發現 when="1y" 不夠用後，我們立刻想到了最直接的解法：程式裡用字串檢查年份，像是 if "2024" not in entry.published 就跳過不處理。這似乎簡單又粗暴，但實際執行時，我們卻碰上了預料之外的狀況。

新聞的發佈時間字串格式多變，有的是英文縮寫、有的是中文日期，還有些帶毫秒或時區標記。當程式只靠 in去判斷「是否包含 ’2024’」時，那些標記在後面、或被轉譯成中文「114 年」，就被漏掉或誤保留下來。這種脆弱的匹配，讓我們在測試階段就經常錯過關鍵條目。

於是，我們又嘗試把時間字串轉成 datetime 物件，再用 pub_dt.month 精準比對。但這回卻遇到 ValueError，因為 strptime 模式必須跟字串完全吻合，稍有差異就全部崩潰。第一次一行程式就卡死、第二次又被格式給絆住，我們才真正理解：看似小小的字串檢查，其實隱藏了格式一致性的巨大挑戰。

失敗的教訓：粗糙篩選帶來的亂象

回顧那幾輪失敗，我們發現自己忽略了一個道理：程式對外部資料的「假設」必須要格外謹慎。以為只要寫上 if "2024" in entry.published 就能準確篩選，卻沒注意到不同媒體、不同語言、不同時區都可能造成格式差異，甚至「2024」這個關鍵字本身，也有可能出現在非發佈時間的上下文裡。

更糟的是，這些粗糙篩選的方法還會讓後續清洗工作大增。我們必須多寫幾段程式碼去一一排除雜訊，再次比對時間正確性。結果不但拉長了開發時間，也提高了維護成本；每次網站稍有改版，程式就要跟著重新調整。

這些亂象一再提醒我們：在大規模蒐集與過濾資料的過程中，務必要先做好「格式一致性」的基礎工作，而非把所有邏輯都塞在主流程裡。只有建立穩固的前置準備，才能讓後續分析更順暢，也能把更多精力放在真正有價值的數據探索上。

進階搜尋語法的救贖

當我們意識到字串篩選與 strptime 通通不夠堅韌後，便轉向了 Google News 搜尋本身的「進階語法」。在關鍵字後面直接拼接 after:2024-01-01 before:2024-04-30，讓搜尋引擎先在伺服器端過濾掉所有不符合時段的新聞，再把「乾淨的」結果送到我們的 RSS 或 API。

這種做法相當於把最難的工作交給了搜尋引擎，程式端只要接收已經處理過的資料，就能少寫很多過濾程式碼。實測結果顯示，搭配 dateutil.parser.parse 解析補強，最終只要做一次月份篩選，即可完全匹配目標時間範圍，成功率大幅提升。

從此以後，我們在建立搜尋 Query 時，便會先思考：有沒有能在源頭解決的條件？若能在搜尋階段就消滅 80% 的雜訊，後續就能專心在資料分析與可視化，讓整個流水線更高效，也能避免一次又一次的「程式微調地獄」。

底層邏輯點睛：工具優先與流程賦能

透過這段「RSS 篩選」的開發經驗，我們深刻體會到一個原則——工具優先。凡是搜尋引擎、第三方 API 或標準管道能完成的事情，就不要急著在程式裡重寫；唯有充分利用「已有的能力」，才能將複雜度留給真正需要精細控制的環節。

同時，流程賦能也是關鍵：我們先把整個蒐集過程拆成「訂閱 RSS → 搜尋語法過濾 → 解析時間 → 初步篩選 → 最終清單」五個模組，每一個都自成一個小流程，並設定清晰的輸入與輸出。如此一來，未來若要改動任何一個環節，都能快速定位而不影響其他部分，整體開發與維護成本大幅降低。

在下一篇文章裡，我們將帶你揭開「重導向大追蹤」的神秘面紗，示範如何從 Google News 的中繼連結，一路追蹤到原始新聞網址，並分享那些讓程式服服貼貼跟隨跳轉的秘訣。數據偵探之旅，愈挖愈精彩，敬請期待！