RSS 分裂、蘋果壟斷、Spotify 圈地：播客背後那場從未結束的標準戰爭

整理者／作者：Gavin Chen

一位 14 歲少年、一位 MTV 主持人，以及一位脾氣火爆的程式設計師，如何一起發明了播客。

從網景的入口網站戰爭，到比特幣打賞，播客 RSS 的歷史其實就是一部開放網路的拉鋸史。

一個隨手造出的詞、一行當年看似不起眼的程式碼，最終撐起了今天價值數百億美元的播客產業。

在流媒體與演算法推薦幾乎全面主導內容分發的今天，播客依然保留了一個古老卻開放的技術核心：RSS（Really Simple Syndication）。無論你在 Apple Podcasts、小宇宙還是 Spotify 上訂閱節目，背後真正驅動內容更新的，往往仍是一份 XML Feed。

但只要稍微打開幾份真實的播客 RSS，你就會發現它們長得完全不一樣。有的塞滿 itunes: 標籤，有的倚賴 content:encoded，有的又加入 podcast:transcript、podcast:value 等新欄位。這些差異，不只是技術選型問題，而是二十多年來標準之爭、平台博弈與開放網路理念衝突的結果。

本文會沿著時間線，重新梳理播客 RSS 如何從 1990 年代末的極客實驗，變成今天音訊產業的基礎設施。

本文也同步發佈於作者個人的微信公眾號與 X 帳號，歡迎關注。

微信公眾號：小陈的科技日常

X 個人帳號：GavinC

如有轉載、引用或合作需求，歡迎透過本站、微信公眾號訊息或 X 私訊聯絡作者。

第一章 混沌初開：RSS 的起源與網景的入口網站之爭（1997—1999）

要理解播客 RSS，必須先回到 1998 年的矽谷。那時網景正在被微軟 IE 全面追擊，為了替 My.Netscape.Com 建立內容聚合能力，網景希望讓不同網站能用標準格式把最新標題與連結送進入口頁面。這個需求，直接催生了 RSS。

圖源：wired

1.1 Guha、MCF 與 RDF 的影子

Ramanathan V. Guha 原本在蘋果的高級技術研究組工作，主導過 Meta Content Framework（MCF）。MCF 企圖描述文件與文件之間的關係，後來成為 RDF 的重要前身。蘋果砍掉這個專案後，Guha 轉投網景，帶著對「機器可理解內容」的執念繼續推進。

圖源：w3.org - An MCF Tutorial

1999 年，網景推出 RSS 0.90，全名當時叫 RDF Site Summary。名義上它帶著 RDF 的血統，但實作上其實極度簡化，遠稱不上真正的 RDF 系統。

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns="http://my.netscape.com/rdf/simple/0.9/">
  <channel>
    <title>My Netscape News</title>
    <link>http://www.my.netscape.com</link>
    <description>The best news on the web.</description>
  </channel>
  <item>
    <title>Breaking News</title>
    <link>http://www.my.netscape.com/news/breaking</link>
  </item>
</rdf:RDF>

它很簡陋，只支援標題與連結，卻成功開啟了內容聚合的新時代。

1.2 Dave Winer 登場

與網景幾乎同步，另一位關鍵人物 Dave Winer 也在推動 XML 內容分發。他是博客、內容管理與大綱軟體的重要先驅，早在 1997 年就替自己的 Scripting News 設計過 XML 格式。對 Winer 來說，網景的 RSS 0.90 太瘦了，因為博客不只需要標題與連結，還需要段落、摘要與更完整的內容。他甚至公開把 Netscape 的格式稱作「嚴重不足」，並說它「缺少網路寫作者與讀者真正需要的關鍵部分」。

英文原文："woefully inadequate"；"missing the key thing web writers and readers need"。

於是 1999 年夏天，他推出自己的 ScriptingNews 2.0b1。很快，網景也讓步，發表 RSS 0.91，全面放棄複雜 RDF 路線，改走更簡單、更面向實作的方向，並把全名改成 Rich Site Summary。Dan Libby 也在新規範中直接解釋了這次轉向：

「RSS 最初被構想為一種用來提供網站摘要的中繼資料格式。現在有兩件事已經很清楚：第一，提供者想要的其實更像是一種內容聚合格式，而不只是中繼資料格式。RDF 檔案的結構非常精確，若要有效就必須符合 RDF 資料模型。這不容易讓人理解，也讓實用 RDF 檔案變得難以製作。第二，可用於 RDF 產生、驗證與處理的工具太少。因此，我們決定改採標準 XML 方法。」

English original: "RDF references removed. RSS was originally conceived as a metadata format providing a summary of a website. Two things have become clear: the first is that providers want more of a syndication format than a metadata format. The structure of an RDF file is very precise and must conform to the RDF data model in order to be valid. This is not easily human-understandable and can make it difficult to create useful RDF files. The second is that few tools are available for RDF generation, validation and processing. For these reasons, we have decided to go with a standard XML approach."

1.3 網景退出後留下的真空

AOL 收購網景後，My.Netscape 在 2001 年改版時移除了 RSS 支援，連 RSS 0.91 的 DTD 都被刪掉。標準失去了官方維護者，但 RSS 早已在博客圈擴散。誰來接手？答案是沒有人真正接手，於是標準戰爭開始了。

第二章 諸神之戰：RSS 分裂與 Atom 的誕生（2000—2005）

網景退出後，RSS 社群迅速分裂成兩條路線。

2.1 RSS 1.0：學術派與 RDF 路線

RSS-DEV 工作組由 Rael Dornfest、Guha 等人推動，希望讓 RSS 回到更嚴謹的 RDF 軌道。2000 年，他們發表 RSS 1.0，核心特色是模組化與命名空間擴展，這也是後來播客生態大量使用 namespace 的重要源頭。

其中最傳奇的參與者，是當時只有 14 歲的 Aaron Swartz。他年紀輕輕就加入標準制定，也成了 RSS 1.0 的象徵人物之一。

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://purl.org/rss/1.0/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel rdf:about="http://www.example.com/rss">
    <title>Example Channel</title>
    <link>http://www.example.com</link>
    <description>An example RSS 1.0 feed</description>
    <dc:creator>John Doe</dc:creator>
  </channel>
  <item rdf:about="http://www.example.com/article1">
    <title>Article One</title>
    <content:encoded><![CDATA[<p>Full HTML content here.</p>]]></content:encoded>
  </item>
</rdf:RDF>

2.2 RSS 2.0：實用派的勝利

Dave Winer 對 RDF 持續反感。他認為 RSS 最重要的不是「語義正確」，而是「任何人都做得出來」。2002 年，他推出 RSS 2.0，並給出後來最有名的全名：Really Simple Syndication。

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Example Podcast</title>
    <link>http://www.example.com</link>
    <description>An example podcast feed</description>
    <item>
      <title>Episode 1</title>
      <description>In this episode, we discuss...</description>
      <enclosure url="http://www.example.com/ep1.mp3" length="12345678" type="audio/mpeg"/>
      <guid>http://www.example.com/episode1</guid>
    </item>
  </channel>
</rss>

RSS 2.0 的關鍵不只是簡單，而是它保留了 命名空間擴展機制。這意味著核心格式可以保持穩定，功能則由 itunes:、content:、podcast: 等外掛式欄位慢慢長出來。Winer 甚至在郵件列表裡預告分裂幾乎無可避免：

「我仍在思考該如何推動 RSS 前進。我確實想把類似 ICE 的東西放進 RSS2，發佈與訂閱是我清單中的首位，但我會為了簡單性拚到底。我喜歡可選元素。我不想走向 namespace 與 schema 那條路，也不想把它做成 RDF 的一種方言。我知道其他人想這麼做，所以我猜我們最後會出現分叉。」

English original: "I'm still pondering how to move RSS forward. I definitely want ICE-like stuff in RSS2, publish and subscribe is at the top of my list, but I am going to fight tooth and nail for simplicity. I love optional elements. I don't want to go down the namespaces and schema road, or try to make it a dialect of RDF. I understand other people want to do this, and therefore I guess we're going to get a fork."

2.3 Atom 的崛起

由於 Winer 宣布「凍結」RSS 2.0，不少開發者認為 RSS 已經無法再健康演化。於是，以 Sam Ruby 為代表的一批人另起爐灶，最終催生 Atom。2005 年，Atom 成為 IETF 的正式 RFC 標準。

Atom 的優勢包括：

1. 強制性的 <id>，解決 RSS guid 可有可無的問題。
2. 更清晰的時間語義，區分 published 與 updated。
3. 內建內容類型宣告，不必完全依賴額外 namespace。

雖然 Atom 沒能在播客世界取代 RSS 2.0，但它留下了 atom:link rel="self" 這個至今仍大量出現在播客 Feed 裡的重要遺產。

2.4 Aaron Swartz 的悲劇

Aaron Swartz 後來不只參與 RSS，也參與 Creative Commons 與 Markdown 的技術建設。2013 年，他在高壓司法追訴下自殺身亡。對許多人來說，RSS 歷史不只是標準演化史，也是開放網路理想主義者的代價史。

第三章 播客的誕生：那個神奇的 <enclosure> 標籤（2000—2004）

播客不是哪家大公司規劃出來的產品，而是博客時代一群極客把現有工具硬組出來的結果。

3.1 一個看似不起眼的標籤

2000 年底，Dave Winer 在 RSS 0.92 裡加入 <enclosure>，原本只是為了讓 Feed 可以附帶音訊或影片檔案。

<enclosure url="http://www.scripting.com/mp3s/weatherReportSuite.mp3"
           length="12216320"
           type="audio/mpeg" />

它只有三個欄位：

• url：檔案位置
• length：位元組大小
• type：MIME 類型

當時這個設計幾乎沒人注意，但後來它成了整個播客產業的技術地基。2001 年 1 月 11 日，Winer 首次在自己的部落格上示範這個功能，還附上了 Grateful Dead 的〈Weather Report Suite〉，並寫道：「這是我們加進 RSS 的第一個音訊 enclosure，希望它能成為一種新的聚合方式。」

英文原文："This is the first audio enclosure we've added to RSS, hopefully this will become a new way of syndicating."

3.2 Adam Curry 與 iPodder

如果說 Dave Winer 是播客的技術之父，Adam Curry 就是播客的傳播之父。這位前 MTV VJ 在 2003 年受到 <enclosure> 啟發，打造了 iPodder 腳本，讓使用者能自動下載 RSS 裡的音訊並同步到 iPod。

「iPod + broadcast」的組合，最後產生了 podcast 這個詞。

3.3 「Podcast」這個名字

2004 年，英國記者 Ben Hammersley 在《衛報》文章裡隨手提出了幾個名稱候選，其中一個就是 podcasting。這原本只是寫稿時湊字數的即興命名，最後卻被整個產業採納。Hammersley 後來也承認，這個詞幾乎是他為了湊篇幅才順手寫下的。

圖源：benhammersley.com

同年，Adam Curry 推出《Daily Source Code》，播客正式從極客玩法進入大眾視野。他那段著名開場白也成了播客史上的經典：

「……屁股上綁著一架價值 1600 萬美元的噴射機，耳朵裡塞著下一代廣播，我想我正飛向未來。」

English original: "...with a 16 million dollar jet strapped to my ass and the next generation of radio in my ears, I think I'm flying into the future."

圖源：Oxford University Press

第四章 蘋果入局與命名空間混戰（2005—2010）

當播客開始爆發，RSS 2.0 原生欄位明顯不夠用了。節目封面、季集資訊、時長、分類、成人內容標記，全都需要新欄位。

4.1 itunes: 命名空間成為事實標準

2005 年，蘋果在 iTunes 4.9 中正式整合播客，並推出 itunes: 命名空間。從此之後，「播客標準」在很長一段時間裡幾乎就等於「Apple Podcasts 能不能正確吃下去」。

圖源：@MacMuzeum Youtube

<rss version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
  <channel>
    <title>Planet Money</title>
    <itunes:author>NPR</itunes:author>
    <itunes:image href="https://media.npr.org/assets/img/podcast-cover.jpg"/>
    <itunes:category text="Business">
      <itunes:category text="Investing"/>
    </itunes:category>
    <itunes:explicit>false</itunes:explicit>
  </channel>
</rss>

常見 itunes: 標籤如下：

4.2 其他重要命名空間

播客 RSS 不只依賴 itunes:，還大量使用其他歷史遺產：

• content:encoded：提供完整 HTML show notes。
• atom:link rel="self"：宣告 Feed 的權威 URL。
• dc:creator：更標準的作者中繼資料。
• media:：媒體描述、縮圖與附加欄位。

<content:encoded><![CDATA[
  <h2>本期內容</h2>
  <p>在這一期節目中，我們邀請到了...</p>
  <h3>時間線</h3>
  <ul>
    <li><strong>00:00</strong> - 開場介紹</li>
    <li><strong>05:30</strong> - 來賓訪談</li>
  </ul>
]]></content:encoded>

4.3 Google Reader 的黃金時代與 RSS 衰落

Google Reader 曾把 RSS 推向更大的使用者規模，但 2013 年的關閉也被視為開放訂閱文化式微的象徵。不過對播客來說，影響沒那麼致命，因為播客客戶端通常直接解析 Feed，而不是依賴 Reader。

第五章 三種典型播客 RSS Feed 流派

不同播客 Feed 之所以長得不同，往往不是因為誰寫錯了，而是因為背後代表不同的托管與相容策略。

5.1 傳統媒體流派：NPR / Planet Money

特徵：

• 命名空間少，結構乾淨
• 嚴格遵守 itunes: 規範
• 使用 content:encoded 提供完整 show notes
• 幾乎不碰自定義欄位

5.2 現代托管平台流派：Simplecast / The Daily

特徵：

• 常見 itunes + atom + content
• 強調 atom:link rel="self"
• 更完整的季集資訊
• 面向大平台兼容性最佳化

5.3 極客與獨立創作者流派：Syntax.fm / Transistor

特徵：

• 常見 itunes + content + dc
• 更豐富的 HTML 節目介紹
• 願意提早採用新標準
• 對 Podcasting 2.0 支援更積極

第六章 封閉與開放的較量：Spotify 與 Podcasting 2.0（2019—至今）

6.1 Spotify 的圈地運動

2019 年後，Spotify 大舉收購 Gimlet、Anchor，並以天價簽下 Joe Rogan 獨家。其目標非常明確：把開放 RSS 生態中的聽眾與創作者，拉回自家封閉 App。

對開放播客社群來說，這是一次非常直接的威脅。因為一旦節目不再透過開放 RSS 分發，而改成平台內部的 DRM 串流，播客就不再是播客，而只是另一種封閉音訊內容。

6.2 Podcasting 2.0 的逆襲

2020 年，Adam Curry 與 Dave Jones 發起 Podcasting 2.0，並建立去中心化目錄 Podcast Index。他們希望在不破壞現有 RSS 2.0 相容性的前提下，讓播客重新恢復創新能力。

核心是新的 podcast: 命名空間：

<podcast:transcript url="https://example.com/ep1.srt" type="application/srt"/>
<podcast:chapters url="https://example.com/ep1-chapters.json" type="application/json+chapters"/>
<podcast:person role="host">John Doe</podcast:person>
<podcast:soundbite startTime="73.0" duration="60.0">
  The most interesting part of the interview
</podcast:soundbite>

其中幾個最有代表性的功能包括：

1. 逐字稿：<podcast:transcript>
2. 章節：<podcast:chapters>
3. 人物資訊：<podcast:person>
4. 精彩片段：<podcast:soundbite>
5. Value4Value 打賞：<podcast:value>

<podcast:value type="lightning" method="keysend" suggested="0.00000015000">
  <podcast:valueRecipient name="Host" type="node" address="02d5c1..." split="90"/>
  <podcast:valueRecipient name="Editor" type="node" address="03a8b7..." split="10"/>
</podcast:value>

這不只是技術更新，也是一種政治宣言：播客不該只依附於某一家公司。

第七章 中國播客生態的特殊面貌

中國播客的發展路徑與歐美很不一樣。早期由喜馬拉雅、蜻蜓 FM、荔枝等封閉平台主導，很多內容更像「網路電台」，而不是基於 RSS 的原生播客。

2020 年，小宇宙上線後，才真正把中國語境中的「播客」與「封閉音訊平台」區分開來。小宇宙一方面支援 RSS 訂閱，另一方面又加入本地化社群互動，例如時間戳評論、收聽狀態標記與創作者資料分析。

正如中文播客《Loud Murmurs》的創辦人 Afra Wang 所說：

「當我的節目在喜馬拉雅上被刪除時，我失去了數千名訂閱者和所有互動紀錄。但因為我們有 RSS feed，節目的內容仍然可以透過其他客戶端被存取。」

English original: "When my show was deleted on Ximalaya, I lost thousands of subscribers and all interaction records. But because we had an RSS feed, the show's content could still be accessed through other clients."

這種「開放分發 + 本地社群」的平衡，構成了中國播客非常特殊的產品形態。

第八章 JSON Feed 與未來標準

XML 曾是資料交換之王，但現代 Web 開發者顯然更偏好 JSON。2017 年，Manton Reece 與 Brent Simmons 推出 JSON Feed，希望以 JSON 重寫 RSS / Atom 的核心能力。

{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "My Example Podcast",
  "feed_url": "https://example.com/feed.json",
  "items": [
    {
      "id": "https://example.com/episode1",
      "title": "Episode 1: Getting Started",
      "content_html": "<p>Full HTML content here.</p>",
      "attachments": [
        {
          "url": "https://example.com/ep1.mp3",
          "mime_type": "audio/mpeg"
        }
      ]
    }
  ]
}

它更容易被 JavaScript 處理，也更符合現代 API 設計習慣，但由於整個播客產業鏈都建立在 RSS 2.0 上，JSON Feed 至今仍未成為播客主流。

第九章 給播客創作者的實用指南

9.1 選擇托管平台時看什麼

9.2 必填欄位

頻道層至少應正確配置：

• <title>
• <description> / <itunes:summary>
• <itunes:image>
• <itunes:category>
• <itunes:author>
• <itunes:explicit>
• <language>

單集層至少應正確配置：

• <title>
• <enclosure>
• <pubDate>
• <guid>
• <itunes:duration>
• <itunes:episodeType>

9.3 常見錯誤

1. 封面圖尺寸不符合 Apple 要求。
2. <enclosure> 的 length 不準確。
3. 多集使用重複的 <guid>。
4. <pubDate> 未遵守 RFC 2822。
5. Feed 遷移後忘記設定 <itunes:new-feed-url>。

第十章 結語：為什麼我們仍然需要關心 RSS？

播客之所以能成為今天這麼大的產業，關鍵不只是內容本身，而是它在技術底層仍保留了開放網路的特性。任何人都可以建立 Feed，任何人都可以開發客戶端，任何人都可以建立目錄。這種開放性，讓創作者不必完全依附單一平台生存。

從 Dave Winer 寫下 <enclosure>，到 Adam Curry 推動 Podcasting 2.0，再到 Aaron Swartz 代表的資訊自由精神，這段歷史提醒我們：真正偉大的基礎設施，最好不要由單一公司獨佔。

下次當你在播客 App 裡點下訂閱時，不妨想想那些安靜運轉在背後的 XML 標籤。正是它們，把世界各地的聲音，一次又一次地送到你的耳邊。

附錄：播客 RSS 發展大事記

參考資料

1. Two-Bit History: The Rise and Demise of RSS. https://twobithistory.org/2018/12/18/rss.html
2. Wikipedia: Dave Winer. https://en.wikipedia.org/wiki/Dave_Winer
3. RSS Advisory Board: RSS History. https://www.rssboard.org/rss-history
4. Wikipedia: Aaron Swartz. https://en.wikipedia.org/wiki/Aaron_Swartz
5. Berkman Klein Center: RSS 2.0 Specification. https://cyber.harvard.edu/rss/rss.html
6. Wikipedia: History of podcasting. https://en.wikipedia.org/wiki/History_of_podcasting
7. Podcasting 2.0 Namespace Docs. https://podcasting2.org/docs/podcast-namespace/
8. JSON Feed Version 1.1. https://www.jsonfeed.org/version/1.1