很抱歉，本站不歡迎來自 [百度] (Baidu.com) 的訪客 !!

摘要提示

• 盜文事件: 作者文章被他人在百度知道全文貼上且未標示出處，引發維權行動。
• 平台差異: 與先前向 Google 檢舉能迅速下架相比，百度回應消極且不採取處置。
• 留言遭刪: 作者在百度的抗議留言屢次被刪，累計至少五次以上。
• 站方態度: 百度站方認定侵權使用者未違規，令作者失望與憤怒。
• 智財權觀念: 作者強調免費資訊不代表可任意濫用，平台應負起把關責任。
• 消極抗議: 無法獲得正規處理後，作者採取以技術手段表達抗議。
• HttpModule: 以 ASP.NET HttpModule 判斷來源 Referer，攔截來自百度的流量。
• 導流機制: 來自百度的訪客先看到 60 秒抗議頁，隨後自動導回原連結頁面。
• 技術教學: 分享可復用的網站層級攔截實作，提供開發者處理類似情境。
• 事件時間線: 詳列 6 次抗議與 1 次站方回應的時間點與佐證連結。

全文重點

作者因再度遭遇網路盜文，這次發生在百度知道。有使用者將作者的文章「一字不漏」貼上、未註明來源，並藉此回答問題以換取點數。作者先在該頁面留言表明侵權並要求標示出處，亦向百度站方檢舉，希望比照以往向 Google 檢舉時能獲得迅速處理。然而事與願違：作者的抗議留言屢次被刪，向站方反映後亦被回覆「未違反規定」而不予處置。相較於 Google 過往對盜文案例的快速關閉處理，百度的消極態度與對智財權的不重視，讓作者感到挫折與憤怒。

作者主張，資訊取得容易不代表可任意踐踏，免費內容也需尊重智慧財產權。雖然自身損害主要是心理不悅，但平台放任侵權的處理方式令人失望。在無法透過正規管道獲得妥善回應後，作者選擇以技術手段進行消極抗議：為網站加上 ASP.NET HttpModule，只要判斷請求的 Referer 來源屬於百度網域，便先導向一頁抗議畫面，停留 60 秒後再自動跳回原本欲瀏覽的目標頁。此舉既不完全封鎖內容，亦能清楚表達對百度處理態度的不滿。

文末作者將此案例轉化為技術教學，示範如何在 Web.config 掛載自製 HttpModule，使全站所有 HTTP 請求都能被攔截與判斷 Referer，從而實作針對來源的路由引導或訊息提示。文中附上簡潔的 C# 範例，說明在 AuthenticateRequest 事件中解析 HTTP_REFERER，若主機名包含 BAIDU.COM，便以 Server.Transfer 轉至抗議頁面。最後作者記錄自 2008/6/22 至 6/28 的六次抗議留言與一次站方回應時間點與截圖，作為經過的佐證與備忘，並號召讀者留言或分享以表達對不重視智財權的抗議。

段落重點

事件起因與對平台差異的對照

作者回顧過去在 Blogger.com 遭盜文，向 Google 反映後獲即時處理並關閉侵權頁，形成正面對照。此次則在百度知道發現他人將其文章全文貼上未註明出處，作者立即留言要求標示來源，並同步向百度站方檢舉。期待比照 Google 的處置，但過程卻急轉直下：抗議留言頻繁被刪，站方回覆亦稱未違規，拒不處理。平台間對智財權的態度差異，成為作者不滿情緒的主因。

立場與訴求：尊重智財與消極抗議

作者強調，資訊免費不代表可以不尊重智財權；對岸使用者的觀念或有落差，但平台更應負責把關。面對留言被刪與站方漠視，作者自認「小蝦米對抗大鯨魚」，只能以消極方式表達立場。於是在站內加上技術性抗議機制：凡透過百度連結而來的使用者，先被導向一個抗議頁面，停留 60 秒後自動轉回原頁。此設計既維持內容可達性，又向百度與使用者清楚傳達抗議訊息，並號召讀者留言支持或以社群推文擴散。

技術實作：ASP.NET HttpModule 攔截來源導頁

作者以教學方式分享可複用的解法：透過 ASP.NET HttpModule 在 AuthenticateRequest 階段攔截全站請求，讀取 HTTP_REFERER，若非空則以 Uri 解析主機名並檢查是否包含 BAIDU.COM。符合條件時，以 Server.Transfer 導向站內抗議頁 ShowBlockedMessage.aspx。此作法的優點是部署簡單（於 Web.config 掛載模組）、作用範圍廣（所有請求皆會經過）、易於維護與擴充（可增加其他來源或條件）。同時，透過延時再導回原頁，兼顧用戶體驗與抗議訴求。

後記與證據備存：時間線紀錄

文末詳列 2008/6/22 至 6/28 的事件時間線：六次張貼抗議留言的時間戳與截圖連結，以及一次百度站方的正式回應截圖。此一紀錄除作為自我備忘，也提供事件經過的透明度與可驗證性，強化作者對平台處置不當的指控基礎。整體而言，本文從個人權益受損出發，經由與 Google 的對照，呈現不同平台對智財權態度的落差；並將不滿轉化為具體可重用的技術實踐，提供社群在面對類似問題時的參考解方。

資訊整理

知識架構圖

1. 前置知識：
   • 基本 HTTP 概念（請求/回應、HTTP header，特別是 Referer）
   • ASP.NET 架構與管線（HttpApplication、HttpModule、事件生命週期）
   • C# 基礎語法與 .NET 類別（Uri、字串處理）
   • Web.config 設定（HttpModule 註冊）
   • 網站內容授權與智慧財產權基本觀念
2. 核心概念：
   • 智慧財產權與內容盜用：文章被無授權全文複製未註明出處
   • 平台處置差異：Google 迅速下架 vs 百度認定不違規且刪除抗議留言
   • HttpModule 截流：在 ASP.NET 管線中攔截所有請求並依條件處置
   • 依 Referer 來源導流：辨識來自 baidu.com 的流量導向抗議頁
   • 用技術表達抗議：顯示 60 秒抗議頁後再導回原目標

   關係：內容盜用引發 → 平台溝通無效 → 採技術手段（HttpModule） → 以 Referer 判斷來源 → 顯示抗議頁並延遲導回

3. 技術依賴：
   • ASP.NET 管線事件順序（AuthenticateRequest 觸發時機）依賴 HttpApplication
   • 讀取 ServerVariables[HTTP_REFERER] 依賴伺服器/IIS 提供 Header
   • 網域比對依賴 Uri 解析與字串比對（大小寫不敏感）
   • 伺服器端跳轉依賴 Server.Transfer（或可替代為 Response.Redirect）
   • Web.config 中 HttpModule 註冊使所有請求進入模組
4. 應用場景：
   • 抗議或合規提醒：來自特定來源的訪客先看到聲明/抗議頁
   • 來源導流控制：根據 Referer 做白名單/黑名單的頁面管制
   • 行銷活動頁：特定合作來源先進入活動落地頁再導回
   • 法務告示：在偵測疑似侵權引用來源時顯示版權聲明
   • 流量品質控管：對可疑來源加上節流或延遲（限度內不影響正常用戶）

學習路徑建議

1. 入門者路徑：
   • 了解 HTTP Referer 基本概念與限制
   • 認識 ASP.NET HttpModule 與管線事件（BeginRequest、AuthenticateRequest 等）
   • 動手建立最小可行 HttpModule：讀取 Referer、記錄 Log
   • 在 Web.config 註冊模組並於本機測試
2. 進階者路徑：
   • 比較 Server.Transfer 與 Response.Redirect 差異與適用時機
   • 強化來源判斷：處理無 Referer、子網域、HTTPS、機器人/爬蟲
   • 增加例外清單與可設定化（web.config appSettings）
   • 友善 UX：抗議頁加計時自動導回、保留原始目標 URL
   • 觀測與記錄：加入事件追蹤、日誌、告警
3. 實戰路徑：
   • 實作抗議頁（顯示 60 秒倒數，計時後導向原 URL）
   • 以條件邏輯攔截 baidu.com Referer 並 Server.Transfer 至抗議頁
   • 建立單元測試/整合測試（模擬不同 Referer、無 Referer）
   • 部署到測試/生產環境並監控影響（跳出率、搜索引擎抓取）
   • 規劃回退機制與灰度發布（可開關的功能旗標）

關鍵要點清單

• 內容盜用與版權意識：無授權全文轉載且未註明出處屬侵權與不尊重作者權益（優先級: 高）
• 平台處置差異：Google 快速下架 vs 百度認定不違規且刪留言，反映平台治理差異（優先級: 中）
• HttpModule 角色：在 ASP.NET 管線中攔截與處理所有請求的擴充點（優先級: 高）
• AuthenticateRequest 時機：在驗證階段即可判斷並導流，效能/控制較佳（優先級: 高）
• 讀取 HTTP_REFERER：使用 ServerVariables[“HTTP_REFERER”]，但可能為空或被偽造（優先級: 高）
• 網域判斷策略：以 Uri 解析並以不分大小寫方式比對包含 “baidu.com”（優先級: 中）
• Server.Transfer vs Redirect：Transfer 留在伺服器端、不改變 URL；Redirect 回 302/307 至客戶端（優先級: 中）
• 無 Referer 情境：直打網址、HTTPS→HTTP、隱私/防追蹤可能導致無 Referer，需避免誤攔（優先級: 高）
• 抗議頁 UX 設計：顯示 60 秒訊息後自動導回原目標，減少對一般用戶干擾（優先級: 中）
• 可設定化與維運：將來源清單、啟用開關放入設定，便於快速調整（優先級: 高）
• 爬蟲與 SEO 影響：攔截搜索引擎爬蟲可能影響收錄與排名，需白名單處理（優先級: 中）
• 記錄與稽核：記錄被攔截的請求以便分析來源與調整策略（優先級: 中）
• 法律與溝通途徑：技術抗議外，仍建議保留法務/通知管道與證據（優先級: 中）
• 安全考量：避免以 Referer 作為安全決策唯一依據，僅用於 UX/導流（優先級: 高）
• ASP.NET Core 對應：在 Core 中以中介軟體（Middleware）實作等效功能（優先級: 中）