RSS 分裂、苹果垄断、Spotify 圈地:播客背后那从未结束的标准战争

从 RSS 的起源、标准分裂、苹果命名空间统治,到 Podcasting 2.0 的复兴,这篇长文系统梳理了播客 RSS 如何成为开放音频世界的底层基础设施。
整理者/作者:Gavin Chen
一个 14 岁少年、一个 MTV 主持人和一个脾气暴躁的程序员,如何发明了播客
从网景的门户战争到比特币打赏,串起播客 RSS 格式的前世今生
一个随手造出的词、一行随手写下的代码,撑起了今天价值百亿的播客产业
让我们追本溯源:播客 RSS 的前世今生、分裂战争与格式大赏
在当下这个流媒体与算法推荐大行其道的时代,播客(Podcast)依然坚守着一种古老而开放的技术内核——RSS(Really Simple Syndication)。当你通过 Apple Podcasts、小宇宙或是 Spotify 订阅一档节目时,背后默默工作的,正是一串串包含着节目信息的 XML 代码。
但你是否好奇过,为什么同样是播客,不同平台输出的 RSS 格式却大相径庭?有的充满了 itunes: 标签,有的夹杂着 content:encoded,还有的甚至用上了 podcast:transcript?这背后,隐藏着长达二十多年的极客恩怨、商业巨头的博弈,以及一场场为了"开放网络"而战的技术运动。
今天,我们就来一场极客视角的考古旅途,追本溯源,看看播客 RSS 是如何从上世纪末的极客玩具,演变成今天支撑起庞大音频产业的基础设施。
这不仅是一部技术史,更是一部关于理想主义与商业现实、开放与封闭、个人英雄主义与集体协作的人性史诗。
毕竟,在这个大厂筑起高墙、将用户圈禁在自家生态里的时代,播客是少数几个依然坚持"开放网络(Open Web)"精神的媒介。
本文同时发布于作者个人微信公众号与个人X账号,欢迎关注。
微信公众号:小陈的科技日常
X个人账号:GavinC
如有转载、引用或合作需求,欢迎通过本站、公众号消息、X账号消息联系作者。
第一章 混沌初开:RSS 的起源与网景的门户之争(1997—1999)
要理解播客 RSS 的底层基因,我们必须先回到 1998 年的硅谷。
那时的互联网还处于早期的"门户网站"时代。网景(Netscape)这家曾经的浏览器霸主,正面临着微软 Internet Explorer 的残酷绞杀。在 1995 年 Netscape 上市时,它的浏览器占据了 80% 以上的市场份额;但到了 1998 年,这个数字已经被微软的 IE 蚕食得所剩无几。
图源:wired
为了寻找新的出路,网景决定打造自己的门户平台 My.Netscape.Com,与雅虎、MSN 等巨头展开竞争。这场被业界称为"门户战争"的竞争,意外地催生了互联网历史上最重要的技术标准之一。
1.1 苹果的遗产:Guha 与 Meta Content Framework
在理解 RSS 的诞生之前,我们需要先认识一个关键人物——Ramanathan V. Guha(R.V. 古哈)。
Guha 是一位出生于印度的计算机科学家,曾在苹果公司的高级技术研究组(ATG)工作。在那里,他开发了一个名为 Meta Content Framework(MCF,元内容框架) 的系统,这是一种用于描述网页和文件之间关系的元数据格式。他甚至为 MCF 开发了一个名为 HotSauce 的可视化工具,能够将文件之间的关系以三维节点网络的形式呈现出来——在 1996 年,这简直是科幻电影里的场景。
图源:w3.org - An MCF Tutorial
然而,苹果在 1997 年砍掉了这个研究项目。Guha 随即跳槽到了网景,并带着他对 MCF 和元数据的执念,开始了一段新的旅程。
在网景,Guha 与 XML 标准的联合创始人 Tim Bray 合作,将 MCF 改造成了一个基于 XML 的版本,并提交给 W3C 作为 RDF(资源描述框架) 标准的基础。RDF 的野心极大——它试图构建一个"语义网",让机器能够理解网页内容的含义,而不仅仅是显示文字。
1.2 网景的"Project 60"与 RSS 0.90 的诞生
1998 年,AOL 宣布收购网景。在这场收购尘埃落定之前,网景内部的工程师们正在紧锣密鼓地推进一个名为"Project 60"的门户项目。
参与这个项目的工程师 Guha 和 Dan Libby 提出了一个构想:如果能有一种标准格式,让其他网站把最新的文章标题和链接打包发过来,用户就可以在 My.Netscape 页面上定制自己的"新闻频道"了。这个想法,就是 RSS 的雏形。
1999 年 3 月,网景正式发布了这个功能,并推出了第一版 RSS 规范——RSS 0.90。当时,RSS 的全称是 RDF Site Summary(RDF 站点摘要) [1]。
然而,这个"RDF"的名头有些名不副实。由于时间紧迫,Guha 和 Libby 实际上并没有在 RSS 0.90 中使用任何真正的 RDF 语法。Dan Libby 后来坦承,他们之所以将其命名为"RDF 站点摘要",更多是出于政治考量——让 RSS 看起来与 W3C 的标准化进程保持一致,而非真正的技术需求。
RSS 0.90 的结构极为简单,一个典型的 RSS 文件看起来是这样的:
<?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.3 Dave Winer 入局:极客与巨头的第一次碰撞
就在网景发布 RSS 0.90 的同时,另一位硅谷传奇人物正在推动着另一场革命:博客(Weblog)。
Dave Winer(戴夫·温纳),1955 年生于纽约皇后区,父亲是哥伦比亚大学的商学教授,母亲是学校心理学家。他毕业于杜兰大学数学系,后在威斯康星大学麦迪逊分校获得计算机科学硕士学位。1979 年,他加入了 Personal Software 公司(后来的 VisiCalc 母公司),开始了他的软件开发生涯 [2]。
Winer 是一个充满争议的天才。他脾气火爆,喜欢在自己的博客 Scripting News 上抨击苹果和微软,但同时也是大纲软件(Outliner)和内容管理系统的先驱。他创办的 Living Videotext 公司开发的 ThinkTank 和 MORE 等大纲软件,在 1980 年代的 Mac 平台上风靡一时,最终以一笔可观的价格卖给了 Symantec,让 Winer 实现了财务自由。
1988 年,Winer 创办了 UserLand Software,专注于 Mac 平台的脚本语言开发。在 1994 年旧金山报业罢工期间,他帮助工人创办了一份网络报纸,由此迷上了网络出版。1997 年 2 月,他创办了 Scripting News 博客,这是互联网上持续运营时间最长的博客之一,至今仍在更新。
早在 1997 年 12 月,Winer 就为自己的博客设计了一种 XML 格式(Scripting News 格式),让其他程序可以读取他的文章。这比网景的 RSS 0.90 早了整整一年多。
当网景发布 RSS 0.90 时,Dave Winer 敏锐地察觉到了它的潜力,但也对其局限性感到不满:RSS 0.90 只能包含标题和链接,而 Winer 认为,博客需要能够传递完整的段落内容。他公开称网景的格式“严重不足”,并说它“缺少网络写作者与读者真正需要的关键部分”。
英文原文:"woefully inadequate";"missing the key thing web writers and readers need"。
Winer 试图游说网景改进 RSS,但并未得到重视。于是,他在 1999 年 6 月推出了自己设计的 ScriptingNews 2.0b1 格式(他称之为"胖"聚合格式,因为它能包含完整的段落,而不仅仅是链接)。
面对 Winer 的挑战,网景在仅仅一个月后就做出了让步,发布了 RSS 0.91。这个版本发生了一百八十度的大转弯:网景彻底抛弃了复杂的 RDF,吸收了 Winer 格式中的大量元素,并将 RSS 的全称改为了 Rich Site Summary(丰富站点摘要) [3]。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."
Dave Winer 对此非常满意,称它“甚至比我原本想象的还要更好”。
英文原文:"even better than I thought it would be."
1.4 网景的退出与权力的真空
然而,好景不长。随着 AOL 完成对网景的收购并进行大规模重组,My.Netscape 门户在 2001 年 4 月的改版中彻底移除了对 RSS 的支持。网景甚至从服务器上删除了 RSS 0.91 的 DTD(文档类型定义)文件,导致许多依赖这个文件进行 XML 验证的 RSS 解析器突然失效 [4]。
网景撒手不管了,但 RSS 已经在博客圈里火了起来。谁来接管这个标准?一场长达数年的"RSS 分裂战争"就此拉开帷幕。
第二章 诸神之战:RSS 的分裂与 Atom 的诞生(2000—2005)
网景的退出,在 RSS 社区里留下了一个巨大的权力真空。两股力量迅速填补进来,并开始了一场旷日持久的标准之争。
2.1 RSS-DEV 工作组的成立
一方是由一群热衷于"语义网"的开发者组成的 RSS-DEV 工作组。这个工作组由 Rael Dornfest(奥莱利网络的技术总监)牵头,成员包括 Ian Davis、Guha 等人。
他们认为,RSS 0.91 过于简陋,必须重新引入 RDF 才能让 RSS 具备描述复杂元数据的能力。他们的目标,是将 RSS 打造成一个真正的语义网工具,而不仅仅是一个简单的新闻聚合格式。
在这个工作组中,有一个年仅 14 岁的少年,他的名字叫 Aaron Swartz(亚伦·斯沃茨)。
Aaron Swartz 于 1986 年 11 月 8 日出生于伊利诺伊州的高地公园市,父亲是一家软件公司的创始人。他从小就对计算机和互联网表现出惊人的天赋:12 岁时,他创建了一个用户生成内容的百科全书网站(比维基百科早了两年),并因此获得了 ArsDigita 奖 [5]。
14 岁时,Aaron Swartz 加入了 RSS-DEV 工作组,并成为 RSS 1.0 规范的核心作者之一。这个年纪,大多数人还在为高中数学题发愁,而他已经在参与制定互联网的基础标准了。
2000 年 12 月,RSS-DEV 工作组发布了 RSS 1.0。这个版本完全基于 RDF,引入了模块化和命名空间(Namespace)的概念,允许通过外部词汇表(如 Dublin Core、Content 模块)来扩展功能。
RSS 1.0 的结构比 RSS 0.91 复杂得多:
<?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>
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://www.example.com/article1"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://www.example.com/article1">
<title>Article One</title>
<link>http://www.example.com/article1</link>
<description>A short description.</description>
<content:encoded><![CDATA[<p>Full HTML content here.</p>]]></content:encoded>
</item>
</rdf:RDF>可以看到,RSS 1.0 已经引入了 dc:creator(Dublin Core 作者)和 content:encoded(完整 HTML 内容)等命名空间扩展——这两个标签,至今仍在播客 RSS Feed 中广泛使用。
2.2 Dave Winer 的反击:真正简单的聚合
另一方则是 Dave Winer。他坚决反对引入复杂的 RDF,认为 RSS 的核心价值就在于"简单"。在 RSS 1.0 发布的仅仅 19 天后,Winer 就在 UserLand 网站上发布了 RSS 0.92。
在接下来的两年里,Winer 凭借着其博客软件的市场占有率,不断迭代自己的 RSS 版本:0.92、0.93、0.94……每一个版本都在做小幅改进,但始终坚守着"简单"的核心原则。
2002 年 9 月,Winer 发布了具有里程碑意义的 RSS 2.0,并赋予了它今天最广为人知的名字——Really Simple Syndication(真正简单的聚合) [6]。
RSS 2.0 的结构清晰简洁,一个典型的 RSS 2.0 文件看起来是这样的:
<?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>
<language>en-us</language>
<pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate>
<item>
<title>Episode 1: Getting Started</title>
<link>http://www.example.com/episode1</link>
<description>In this episode, we discuss...</description>
<pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate>
<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 最大的贡献,是保留了简单的 XML 结构,同时引入了**命名空间(Namespace)**机制。这就像是给 RSS 开了一个"外挂接口",允许任何人通过自定义的标签来扩展 RSS 的功能,而不需要修改核心规范。
2003 年 7 月,Winer 将 RSS 2.0 的版权捐赠给了哈佛大学伯克曼互联网与社会中心(他当时在那里做研究员),并宣布"冻结"该规范,不再进行重大修改 [7]。
这个决定,在当时引发了巨大的争议。支持者认为,"冻结"规范可以保证稳定性,避免无休止的版本迭代;反对者则认为,这是 Winer 在用哈佛的权威来阻止社区对 RSS 进行改进,是一种"技术霸权主义"。
2.3 邮件列表大战:一场旷日持久的口水战
在 RSS 1.0 和 RSS 2.0 并行发展的这几年里,两个阵营之间的争论从未停止。
争论的主战场,是一个名为 Syndication 邮件列表的公开讨论组。在这里,来自全球各地的开发者、博主和技术爱好者,就 RSS 的未来展开了激烈的辩论。
Dave Winer 是这个邮件列表上最活跃的参与者之一,也是最具争议的人物。他的风格直接、强硬,有时甚至粗鲁。他曾多次在邮件列表上公开批评 RSS 1.0 阵营的成员,认为他们的方案"过于复杂"、"脱离实际"。他甚至直接写道:
“我仍在思考如何推动 RSS 向前发展。我当然希望把类似 ICE 的东西放进 RSS2,发布与订阅位列我的优先事项之首,但我会为了简单性据理力争。我喜欢可选元素。我不想走向命名空间和 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."
而 RSS 1.0 阵营的成员则反唇相讥,认为 Winer 的 RSS 2.0 是一个"糟糕的技术决策",缺乏严格的规范,导致不同实现之间存在大量的不兼容问题。
这场争论,不仅仅是技术上的分歧,更是两种截然不同的互联网哲学的碰撞:
一方是 实用主义:RSS 应该简单到任何人都能理解和实现,哪怕牺牲一些技术上的严谨性。 另一方是 学术主义:RSS 应该建立在严格的标准之上,哪怕这意味着更高的学习成本。
这场争论最终没有赢家,但它的副产品,却是互联网历史上最重要的技术标准之一。
2.4 另起炉灶:Atom 的崛起
由于 RSS 2.0 被"冻结",且 Dave Winer 的强势作风得罪了不少开发者,社区里的一群人决定彻底抛弃 RSS 的历史包袱,从头设计一个更严谨、更现代的聚合格式。
2003 年 6 月,IBM 的工程师 Sam Ruby 在自己的博客上发了一篇文章,讨论"一个格式良好的博客条目应该包含哪些元素"。这篇文章意外地成为了一个集结号,吸引了大批开发者的响应 [8]。
这个新格式最初被称为 Echo,后来又叫 Pie、Necho,最终定名为 Atom。参与这个项目的,包括 Mena Trott(Six Apart 的联合创始人,TypePad 的母公司)、Brad Fitzpatrick(LiveJournal 的创始人)、Jason Shellen(Blogger 的工程师)、Jeremy Zawodny(雅虎工程师)等一大批互联网精英。
值得一提的是,连 Dave Winer 本人也对 Atom 项目给予了"有条件的支持"——尽管他后来撤回了这个立场。
Atom 的设计目标非常明确:
"100% 厂商中立、所有人都能实现、任何人都能自由扩展、干净彻底地规范化。"
2005 年,IETF 正式将 Atom 发布为 RFC 4287 标准 [9]。与 RSS 2.0 相比,Atom 有几个显著的改进:
- 强制性的
<id>元素:每个条目都必须有一个全局唯一的标识符,解决了 RSS 中<guid>可选导致的混乱问题。 - 明确的时间戳语义:区分了内容的创建时间(
<published>)和更新时间(<updated>),而 RSS 只有一个模糊的<pubDate>。 - 内置的内容类型声明:可以明确声明内容是纯文本、HTML 还是 XHTML,不再需要
<content:encoded>这样的命名空间扩展。
至此,RSS/Atom 领域形成了"三分天下"的局面:学术派的 RSS 1.0(基于 RDF)、实用派的 RSS 2.0(Dave Winer 的遗产)、现代派的 Atom(IETF 标准)。
虽然 Atom 在技术上更加完善,但由于 RSS 2.0 已经占据了先发优势,最终在播客领域,RSS 2.0 成为了绝对的主流。Atom 并没有消失,而是以一种独特的方式融入了现代播客 RSS Feed——你会在几乎所有现代播客的 RSS 文件头部看到 xmlns:atom="http://www.w3.org/2005/Atom" 这行声明,但它通常只用于一个用途:声明 Feed 自身的永久地址(<atom:link rel="self">)。
2.5 Aaron Swartz 的悲剧结局
在这场 RSS 战争中,Aaron Swartz 是一个特殊的存在。他参与制定了 RSS 1.0,但后来也为 RSS 2.0 的发展做出了贡献。他还参与了 Creative Commons 许可证的技术架构设计,以及 Markdown 标记语言的语法定义。
2004 年,他进入斯坦福大学,但一年后便辍学,加入了 Y Combinator 的第一届孵化项目。他的公司 Infogami 后来与 Reddit 合并,使他成为 Reddit 的联合创始人之一。
然而,Aaron Swartz 最广为人知的,是他对"信息自由"的执着追求。2011 年,他被指控从 MIT 网络下载了大量 JSTOR 学术论文,意图免费分享给公众。联邦检察官对他提出了多项指控,最高可判处 35 年有期徒刑。
2013 年 1 月 11 日,年仅 26 岁的 Aaron Swartz 在布鲁克林的公寓里自杀身亡。他的离去,震惊了整个互联网世界。
人们在哀悼他的同时,也在追问:如果没有这场不成比例的司法追诉,这位在 14 岁就参与制定互联网标准的天才,还能为这个世界创造多少价值?
第三章 播客的诞生:那个神奇的 <enclosure> 标签(2000—2004)
播客的诞生,并非某一家科技巨头的宏大规划,而是一群极客在博客时代的边缘疯狂试探的结果。
3.1 附件的灵感:一首 Grateful Dead 的歌
2000 年 10 月,互联网先驱 Tristan Louis 在自己的博客上发表了一篇文章,提出了一个设想:能不能在 RSS 里附上音频或视频文件,就像电子邮件的附件一样?
这个想法传到了 Dave Winer 那里。Winer 和 Adam Curry 此前就讨论过"音频博客"(Audioblogging)的概念,他立刻意识到这个想法的价值。
2000 年底,Winer 在 RSS 0.92 版本中引入了一个看似不起眼的标签:<enclosure>(附件) [10]。它的结构非常简单,只包含三个属性:
<enclosure url="http://www.scripting.com/mp3s/weatherReportSuite.mp3"
length="12216320"
type="audio/mpeg" />url:音频文件的下载地址length:文件大小(字节)type:文件的 MIME 类型(如audio/mpeg代表 MP3)
2001 年 1 月 11 日,Winer 在自己的博客中首次演示了这个功能,附带了一首 Grateful Dead 乐队的歌曲《Weather Report Suite》。他在博客里写道:"这是我们在 RSS 中添加的第一个音频附件,希望这能成为一种新的传播方式。"
英文原文:"This is the first audio enclosure we've added to RSS, hopefully this will become a new way of syndicating."
然而,在最初的两年里,几乎没有人知道拿这个 <enclosure> 标签来干什么。它就像一粒种子,静静地等待着合适的土壤。
3.2 播客教父 Adam Curry 的传奇故事
如果说 Dave Winer 是播客的"技术之父",那么 Adam Curry 就是播客的"传播之父"。
Adam Curry,1964 年出生于弗吉尼亚州的阿灵顿,父亲是一位外交官,这让他在欧洲度过了大部分童年。1987 年,他加入了 MTV,凭借帅气的外形和活泼的主持风格,迅速成为了 MTV 最受欢迎的 VJ(视频节目主持人)之一。在 MTV 的黄金年代,他的脸出现在全球数亿年轻人的电视屏幕上。
1994 年,Curry 离开了 MTV,开始探索互联网的可能性。他在荷兰创办了一家互联网公司,并成为了 Dave Winer 博客软件的早期用户。两人通过网络结识,并开始讨论音频在互联网上的传播可能性。
2003 年 10 月,在哈佛大学举办的第一届 BloggerCon 大会上,开发者 Kevin Marks 演示了一个脚本,可以自动下载 RSS 中的 <enclosure> 音频文件,并将其传送到 iTunes 里,进而同步到 iPod 上。
受到启发的 Adam Curry,在大会结束后立刻行动起来。他在自己的博客上提供了一个名为 iPodder 的脚本,供读者下载使用。这个工具解决了音频分发最大的痛点:用户不再需要守在电脑前点击网页播放,音频文件可以在后台自动下载,并同步到 iPod 上。
"iPod + Broadcast"的组合,催生了一种全新的媒介。
3.3 "Podcast"这个词是怎么来的?
2004 年 2 月 12 日,英国记者、技术作家 Ben Hammersley 在《卫报》发表了一篇名为《听觉革命》(Audible Revolution)的文章,探讨网络音频的兴起。在这篇文章中,他随手列举了几个可能的名称来描述这种新媒介,其中包括:audioblogging、podcasting、GuerillaMedia……
Hammersley 后来承认,"podcast"这个词完全是他在凑字数时随手想到的,当时他自己都没觉得这个词有多特别 [11]。
图源:benhammersley.com
然而,历史选择了这个词。2004 年 9 月,科技博主 Doc Searls 在一篇文章中使用了"podcast"这个词,随后这个词迅速在博客圈里传播开来。
2004 年 8 月,Adam Curry 推出了自己的播客节目《Daily Source Code》(每日源代码)。这档节目不仅聊技术、放音乐,还大力推广播客这种新形式。节目的开场白至今让人印象深刻:"……带着价值 1600 万美元的飞机绑在我的屁股上,耳朵里放着下一代广播内容,我想我正在飞向未来。"
英文原文:"...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."
《Daily Source Code》在巅峰时期拥有超过 50 万订阅者,Curry 因此被业界尊称为"播客教父"(The Podfather) [12]。
2005 年底,"podcast"被《新牛津美国词典》评选为年度词汇。一个新的媒介时代正式宣告开始。
图源:Oxford University Press
3.4 播客的技术基础:RSS 2.0 + <enclosure> 的完美组合
理解了 RSS 的历史,我们就能明白为什么播客选择了 RSS 2.0 而不是 RSS 1.0 或 Atom 作为技术基础。
原因很简单:<enclosure> 标签是 Dave Winer 在 RSS 0.92 中引入的,而 RSS 0.92 是 RSS 2.0 的直接前身。 RSS 1.0 从未支持 <enclosure> 标签,而 Atom 在 2005 年才发布,那时播客已经在 RSS 2.0 的基础上蓬勃发展了。
这就是历史的偶然性:一个在 2001 年几乎无人问津的 XML 标签,在三年后成为了一个全新媒介的技术基础。
第四章 苹果的入局与命名空间的混战(2005—2010)
随着播客的爆发,基础的 RSS 2.0 规范很快就显得捉襟见肘了。
RSS 2.0 只能提供标题、描述和音频下载地址,但对于一档专业的音频节目来说,这远远不够:如何定义播客的精美封面?如何区分每一季和每一集?如何提供详细的节目说明?如何标记节目是否包含成人内容(Explicit)?
这时,Dave Winer 当年引入的"命名空间(Namespace)"机制发挥了巨大作用。各大平台纷纷利用这个"外挂接口",推出了自己的扩展标签。
4.1 苹果的统治:itunes: 命名空间的诞生
2005 年 6 月,在苹果的 WWDC 大会上,史蒂夫·乔布斯(Steve Jobs)亲自在台上演示了 iTunes 4.9 版本。苹果正式将播客功能整合进 iTunes,并推出了一个庞大的播客目录 [13]。
图源:@MacMuzeum Youtube
"我们认为它是广播界最热门的东西,比广播里的任何东西都要热。"乔布斯当时这样说道。"播客就是下一代广播,用户现在可以订阅超过 3000 个免费播客,每个新节目都会通过互联网自动送到你的电脑和 iPod 上。"
英文原文:"We think it's the hottest thing in radio, way hotter than anything on radio. Podcasting is the next generation of radio, and users can now subscribe to over 3,000 free podcasts, and each new episode is automatically delivered over the Internet to your computer and iPod."
iTunes 4.9 发布后,仅仅两天内,iTunes 播客目录就收到了超过 100 万次订阅。苹果的入局,不仅让播客真正走向了大众,也让苹果顺势成为了播客标准的制定者。
为了让 iTunes 能够完美地展示播客信息,苹果推出了 http://www.itunes.com/dtds/podcast-1.0.dtd 命名空间。它定义了一系列前缀为 itunes: 的标签:
<rss version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
<channel>
<title>Planet Money</title>
<link>https://www.npr.org/podcasts/510289/planet-money</link>
<description>The economy explained.</description>
<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>
<item>
<title>Episode 1000: The Final Episode</title>
<itunes:duration>3600</itunes:duration>
<itunes:episodeType>full</itunes:episodeType>
<itunes:season>1</itunes:season>
<itunes:episode>1000</itunes:episode>
<enclosure url="https://feeds.npr.org/ep1000.mp3" length="57600000" type="audio/mpeg"/>
</item>
</channel>
</rss>itunes: 命名空间定义的核心标签包括:
| 标签 | 说明 | 适用层级 |
|---|---|---|
<itunes:author> | 节目作者/主播姓名 | 频道、单集 |
<itunes:image> | 封面图片 URL | 频道、单集 |
<itunes:category> | 节目分类(支持嵌套子分类) | 频道 |
<itunes:explicit> | 是否包含成人内容(true/false) | 频道、单集 |
<itunes:duration> | 音频时长(秒数或 HH:MM:SS) | 单集 |
<itunes:episodeType> | 节目类型(full/trailer/bonus) | 单集 |
<itunes:season> | 季数 | 单集 |
<itunes:episode> | 集数 | 单集 |
<itunes:title> | 节目标题(覆盖 <title>) | 单集 |
<itunes:summary> | 节目摘要(已被 <description> 取代) | 频道、单集 |
<itunes:keywords> | 关键词(已废弃) | 频道、单集 |
<itunes:new-feed-url> | RSS Feed 迁移时的新地址 | 频道 |
<itunes:block> | 阻止节目出现在 Apple Podcasts 目录 | 频道、单集 |
<itunes:complete> | 标记节目已完结 | 频道 |
由于苹果在播客领域的绝对统治力(在相当长的时间里,Apple Podcasts 占据了全球播客收听量的 50% 以上),itunes: 标签成为了事实上的行业标准。今天,任何一个播客托管平台,如果不支持 itunes: 标签,其节目就无法在绝大多数播客客户端中正常显示。
4.2 content:encoded:HTML 内容的救星
在 itunes: 命名空间之外,另一个在播客 RSS 中极为常见的标签是 <content:encoded>。
这个标签来自 RSS 1.0 时代的 Content 模块(http://purl.org/rss/1.0/modules/content/),由 RSS-DEV 工作组定义。它的作用,是为 RSS 条目提供完整的 HTML 内容,弥补了基础 <description> 标签只能包含纯文本(或经过转义的 HTML)的不足。
在播客中,<content:encoded> 通常用于提供详细的节目简介(Show Notes),包含带有超链接的文字、嵌入的图片、时间戳列表等富文本内容:
<content:encoded><![CDATA[
<h2>本期内容</h2>
<p>在这一期节目中,我们邀请到了...</p>
<h3>时间线</h3>
<ul>
<li><strong>00:00</strong> - 开场介绍</li>
<li><strong>05:30</strong> - 嘉宾访谈</li>
<li><strong>45:00</strong> - 听众问答</li>
</ul>
<p>相关链接:<a href="https://example.com">点击这里</a></p>
]]></content:encoded>CDATA 标记的作用,是告诉 XML 解析器:这段内容里的 < 和 > 符号是 HTML 标签,而不是 XML 标签,不要对它们进行解析。
4.3 atom:link:Feed 的自我声明
现代播客 RSS Feed 中,几乎都会看到这样一行:
<atom:link href="https://feeds.example.com/podcast.xml" rel="self" type="application/rss+xml"/>这个 <atom:link rel="self"> 标签来自 Atom 命名空间,它的作用是让 RSS Feed 声明自己的"权威 URL"(Canonical URL)。
这个标签的实际用途非常重要:当播客托管平台迁移服务器、更换域名时,订阅者的客户端可以通过这个标签自动更新 Feed 地址,而不需要手动重新订阅。
4.4 dc:(Dublin Core):图书馆学的遗产
Dublin Core(都柏林核心集)是一套由 DCMI(都柏林核心元数据倡议)维护的元数据标准,最初于 1995 年在美国俄亥俄州都柏林市的一次会议上提出,因此得名。它的设计目标,是为数字资源提供一套简单、通用的元数据描述词汇。
在播客 RSS 中,Dublin Core 命名空间(http://purl.org/dc/elements/1.1/)主要用于提供更标准化的作者和版权信息:
<dc:creator>John Doe</dc:creator>
<dc:publisher>Example Media</dc:publisher>
<dc:rights>Copyright 2024 Example Media. All rights reserved.</dc:rights>
<dc:language>zh-CN</dc:language>虽然 itunes:author 已经可以提供作者信息,但一些老旧的 RSS 阅读器和播客客户端仍然依赖 dc:creator 来识别作者。因此,一些注重兼容性的播客托管平台会同时输出这两个标签。
4.5 media:(Media RSS):雅虎的多媒体扩展
Media RSS(媒体 RSS)是雅虎在 2004 年提出的一个 RSS 扩展命名空间,专门用于描述多媒体内容(图片、音频、视频)。它的命名空间前缀通常是 media:,对应的 URI 是 http://search.yahoo.com/mrss/。
在播客 RSS 中,media: 命名空间主要用于提供备用的封面图和媒体描述:
<media:content url="https://example.com/ep1.mp3" type="audio/mpeg" medium="audio" duration="3600">
<media:title>Episode 1: Getting Started</media:title>
<media:description>In this episode, we discuss...</media:description>
<media:thumbnail url="https://example.com/ep1-cover.jpg" width="1400" height="1400"/>
</media:content>虽然 media: 命名空间在视频播客领域更为常见,但一些现代播客托管平台(如 Simplecast)也会在 RSS Feed 中包含 media: 标签,以提高在各种聚合器中的兼容性。
4.6 Google Reader 的黄金时代与 RSS 的衰落
2005 年,谷歌推出了 Google Reader,一个基于 Web 的 RSS 阅读器。Google Reader 的出现,将 RSS 的使用从极客圈推向了更广泛的用户群体。
在 Google Reader 的鼎盛时期,它拥有数千万活跃用户,成为了全球最重要的 RSS 聚合平台。许多人每天早上打开 Google Reader,就像打开报纸一样,浏览来自全球各地的博客和新闻。
然而,2013 年 3 月,谷歌突然宣布将于同年 7 月 1 日关闭 Google Reader。这个决定震惊了整个互联网世界。
谷歌关闭 Google Reader 的原因,官方说法是"用户数量下降",但更多人认为,真正的原因是谷歌希望将用户引导到 Google+ 这个社交网络上,而 RSS 的开放性与谷歌的封闭生态战略相冲突。
Google Reader 的关闭,被许多人视为 RSS 衰落的标志性事件。然而,对于播客来说,这个影响相对有限——因为播客客户端(如 Pocket Casts、Overcast)并不依赖 Google Reader,而是直接解析 RSS Feed。
第五章 三种典型 RSS Feed 的深度解析
在了解了 RSS 的历史和各命名空间的来龙去脉之后,让我们回到最初的问题:为什么不同播客的 RSS Feed 格式差异如此之大?
通过对 NPR(Planet Money)、Simplecast(The Daily)和独立站点(Syntax.fm)三个真实 RSS Feed 的深度分析,我们可以清晰地看到三种不同的"流派"。
5.1 传统媒体托管流派(NPR / Planet Money 风格)
命名空间组合:rss + itunes + content
NPR(美国国家公共广播电台)是美国最具影响力的公共媒体机构之一,其旗下的 Planet Money 是全球最受欢迎的经济类播客之一。
NPR 的 RSS Feed 代表了传统媒体机构的典型做法:极简主义,严格遵循标准。
这类 Feed 的特点是:
- 命名空间数量少(通常只有
itunes和content),结构清晰,易于解析。 - 严格遵循苹果的
itunes:命名空间规范,确保节目在 Apple Podcasts 中的完美展示。 - 使用
<content:encoded>提供详细的 HTML 格式节目简介。 - 不使用任何非标准的自定义标签。
NPR 这种极简风格的背后,是其强大的技术团队和严格的质量控制体系。他们不需要用各种命名空间来"打补丁",因为他们有能力直接维护自己的播客基础设施。
<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
version="2.0">
<channel>
<title>Planet Money</title>
<link>https://www.npr.org/podcasts/510289/planet-money</link>
<description>The economy explained. Imagine you could call up a friend...</description>
<language>en</language>
<copyright>Copyright 2024 NPR</copyright>
<itunes:author>NPR</itunes:author>
<itunes:image href="https://media.npr.org/assets/img/2022/09/23/pm_podcasttile_sq-...jpg"/>
<itunes:category text="Business">
<itunes:category text="Investing"/>
</itunes:category>
<itunes:explicit>false</itunes:explicit>
<item>
<title>Episode 1000: The Final Episode</title>
<description>Short plain-text description here.</description>
<content:encoded><![CDATA[<p>Full HTML content with links...</p>]]></content:encoded>
<pubDate>Mon, 01 Jan 2024 05:00:00 +0000</pubDate>
<enclosure url="https://feeds.npr.org/510289/ep1000.mp3" length="57600000" type="audio/mpeg"/>
<guid isPermaLink="false">https://www.npr.org/2024/01/01/episode-1000</guid>
<itunes:duration>3600</itunes:duration>
<itunes:episodeType>full</itunes:episodeType>
</item>
</channel>
</rss>5.2 现代托管平台流派(Simplecast / The Daily 风格)
命名空间组合:rss + itunes + atom + content
Simplecast 是一家面向专业播客创作者的托管平台,《纽约时报》的旗舰播客《The Daily》就托管在这里。
Simplecast 的 RSS Feed 代表了现代专业播客托管平台的典型做法:兼容并包,集大成者。
与 NPR 相比,Simplecast 的 Feed 多了两个命名空间:
atom:link rel="self":声明 Feed 的权威 URL,方便客户端在 Feed 地址变更时自动更新。- 更丰富的
itunes:标签使用,包括<itunes:season>、<itunes:episode>等用于区分季集的标签。
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
<title>The Daily</title>
<atom:link href="https://feeds.simplecast.com/54nAGcIl" rel="self" type="application/rss+xml"/>
<link>https://www.nytimes.com/column/the-daily</link>
<description>This is what the news should sound like.</description>
<itunes:author>The New York Times</itunes:author>
<itunes:image href="https://image.simplecastcdn.com/...jpg"/>
<itunes:category text="News">
<itunes:category text="Daily News"/>
</itunes:category>
<item>
<title>The Biggest Story of the Year</title>
<description>Plain text description.</description>
<content:encoded><![CDATA[<p>Full HTML show notes...</p>]]></content:encoded>
<pubDate>Mon, 01 Jan 2024 10:00:00 +0000</pubDate>
<enclosure url="https://cdn.simplecast.com/audio/...mp3" length="34560000" type="audio/mpeg"/>
<guid isPermaLink="false">https://www.nytimes.com/2024/01/01/podcasts/the-daily/...</guid>
<itunes:duration>2160</itunes:duration>
<itunes:episodeType>full</itunes:episodeType>
</item>
</channel>
</rss>5.3 独立极客流派(Syntax.fm / Transistor 风格)
命名空间组合:rss + itunes + content + dc
Syntax.fm 是一档由 Wes Bos 和 Scott Tolinski 主持的技术播客,专注于 Web 开发话题。它使用 Transistor 平台托管,代表了独立创作者和技术极客的典型做法:灵活定制,拥抱前沿。
与前两者相比,Syntax.fm 的 Feed 有几个独特之处:
- 使用
dc:creator:除了itunes:author,还额外提供了 Dublin Core 的作者标签,以兼容更多解析器。 - 更丰富的节目简介:
<content:encoded>中包含了详细的章节时间戳和相关链接,充分利用了 HTML 格式的表现力。 - 积极采用新标准:Transistor 平台对 Podcasting 2.0 的新标签有较好的支持。
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
<title>Syntax - Tasty Web Development Treats</title>
<link>https://syntax.fm</link>
<description>Full Stack Developers Wes Bos and Scott Tolinski...</description>
<dc:creator>Wes Bos & Scott Tolinski</dc:creator>
<itunes:author>Wes Bos & Scott Tolinski</itunes:author>
<itunes:image href="https://syntax.fm/static/logo.png"/>
<itunes:category text="Technology">
<itunes:category text="Software How-To"/>
</itunes:category>
<item>
<title>Supper Club × Building a Podcast App with Expo</title>
<content:encoded><![CDATA[
<h2>Show Notes</h2>
<p>In this episode...</p>
<h3>Timestamps</h3>
<ul>
<li>00:00 - Welcome</li>
<li>05:00 - Guest Introduction</li>
</ul>
<h3>Links</h3>
<ul>
<li><a href="https://expo.dev">Expo</a></li>
</ul>
]]></content:encoded>
<enclosure url="https://traffic.libsyn.com/syntax/...mp3" length="45000000" type="audio/mpeg"/>
<itunes:duration>2800</itunes:duration>
</item>
</channel>
</rss>5.4 三种流派的对比总结
| 特征 | NPR 风格 | Simplecast 风格 | Syntax.fm 风格 |
|---|---|---|---|
| 命名空间数量 | 2(itunes + content) | 3(itunes + atom + content) | 3(itunes + content + dc) |
| atom:link | 无 | 有 | 无/可选 |
| dc:creator | 无 | 无 | 有 |
| Show Notes 格式 | HTML | HTML | 详细 HTML + 时间戳 |
| 适用场景 | 传统媒体机构 | 专业托管平台 | 独立创作者/极客 |
| 对新标准的态度 | 保守 | 中立 | 积极 |
第六章 封闭与开放的较量:Spotify 的野心与 Podcasting 2.0 的复兴(2019—至今)
进入 2010 年代后,播客逐渐从极客的爱好变成了一门大生意。资本的涌入,开始对播客赖以生存的开放 RSS 生态构成了威胁。
6.1 Spotify 的"圈地运动"
2019 年 2 月,流媒体巨头 Spotify 斥资约 4 亿美元,同时收购了播客制作公司 Gimlet Media 和托管平台 Anchor [14]。Gimlet Media 是《Reply All》《StartUp》等知名播客的制作公司,Anchor 则是一个让任何人都能免费创建播客的工具平台。
随后,Spotify 更是以 1 亿美元的天价,签下了顶流播客 Joe Rogan(乔·罗根)的独家播客权 [15]。Joe Rogan 的节目《The Joe Rogan Experience》此前一直是开放的 RSS Feed,任何播客客户端都可以订阅。但从 2020 年 9 月起,完整版节目只能在 Spotify 上收听。
Spotify 的策略很明确:通过独家内容,将听众从开放的 RSS 客户端(如 Apple Podcasts、Pocket Casts)吸引到自己的封闭 App 中。在 Spotify 平台上,播客不再是一个可以自由下载的 MP3 文件,而是被锁在 DRM(数字版权管理)保护下的流媒体。
这种"圈地运动",让许多坚守开放网络的播客老炮感到担忧。博客 Beard.fm 的作者甚至发表了一篇题为《Spotify 正在扼杀播客》的文章,指出 Spotify 的封闭策略正在侵蚀播客的开放性基础。
然而,故事并没有朝着最坏的方向发展。2024 年,Spotify 宣布结束与 Joe Rogan 的独家协议,Rogan 的节目重新回到了开放的 RSS Feed。Spotify 的"独家播客"战略,在花费了数亿美元之后,最终以失败告终。
6.2 苹果的垄断与标准的停滞
与 Spotify 的激进扩张不同,苹果对播客生态的影响更加隐性,但也更加深远。
苹果通过 itunes: 命名空间,实际上掌控了播客标准的制定权。任何新的功能需求,都需要等待苹果更新其规范才能得到广泛支持。而苹果对播客的态度,长期以来都是"不温不火"——它不像 Spotify 那样大规模投资,但也不放弃对标准的控制权。
这种垄断带来的最大问题,是标准的停滞。许多播客创作者和开发者迫切需要的功能——如标准化的逐字稿、详细的章节信息、直接打赏功能——迟迟得不到苹果的支持。
6.3 祖师爷的逆袭:Podcasting 2.0 的诞生
2020 年夏天,播客的两位祖师爷 Adam Curry 和 Dave Jones 决定再次出手。
他们发起了 Podcasting 2.0 运动,并建立了一个完全开源、去中心化的播客目录——Podcast Index [16]。Podcast Index 的目标,是提供一个不受任何单一公司控制的播客数据库,任何开发者都可以免费使用。
更重要的是,他们推出了全新的 podcast: 命名空间(https://podcastindex.org/namespace/1.0)。这个命名空间的设计原则是:100% 向后兼容现有的 RSS Feed,任何播客都可以在不破坏现有订阅的情况下,逐步添加新的 podcast: 标签。
6.4 podcast: 命名空间的核心标签详解
podcast: 命名空间目前包含数十个标签,涵盖了播客创作的方方面面。以下是最重要的几个:
<podcast:transcript>:逐字稿
<podcast:transcript url="https://example.com/ep1.srt" type="application/srt"/>
<podcast:transcript url="https://example.com/ep1.json" type="application/json" language="zh-CN"/>这个标签允许播客提供标准化的逐字稿链接,支持 SRT、VTT、JSON 等多种格式。对于听障人士来说,这个功能极大地提升了播客的可访问性;对于搜索引擎来说,逐字稿使得播客内容可以被索引和搜索。
<podcast:chapters>:章节
<podcast:chapters url="https://example.com/ep1-chapters.json" type="application/json+chapters"/>这个标签指向一个 JSON 文件,其中包含了节目的章节信息,包括每个章节的标题、开始时间、封面图和链接。支持 Podcasting 2.0 的客户端(如 Fountain、Pocket Casts)可以在播放界面上显示章节列表,让听众可以直接跳转到感兴趣的部分。
<podcast:person>:人员信息
<podcast:person role="host" img="https://example.com/host.jpg" href="https://example.com/host">
John Doe
</podcast:person>
<podcast:person role="guest" img="https://example.com/guest.jpg">
Jane Smith
</podcast:person>这个标签详细标注了参与节目的所有人员(主播、嘉宾、剪辑师、制作人等),并可以附上他们的头像和个人主页链接。
<podcast:soundbite>:精彩片段
<podcast:soundbite startTime="73.0" duration="60.0">
The most interesting part of the interview
</podcast:soundbite>这个标签标记了节目中的精彩片段,方便平台和客户端生成预告内容。
<podcast:value>:Value4Value 打赏
这是 Podcasting 2.0 中最具革命性的一个标签。它支持基于闪电网络(Lightning Network)的比特币微支付,听众可以按收听时长实时向主播"流式打赏"(Value4Value) [17]。
<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>这种模式试图打破传统的广告变现路径,让创作者直接从听众那里获得收益。听众可以在支持 Podcasting 2.0 的客户端(如 Fountain)上,按每分钟几个聪(Satoshi,比特币的最小单位)的速率,在收听过程中实时向主播打赏。
<podcast:location>:地理位置
<podcast:location geo="geo:37.786971,-122.399677" osm="R7444">San Francisco, CA</podcast:location>这个标签标记了节目的地理位置信息,方便地理位置相关的播客(如城市旅游播客、本地新闻播客)被发现。
<podcast:guid>:全局唯一标识符
<podcast:guid>917393e3-1b1e-5cef-ace4-edaa54e1f810</podcast:guid>这个标签为播客提供了一个全局唯一的 UUID,确保即使 Feed URL 发生变化,播客的身份也不会丢失。这对于播客迁移托管平台时保持订阅数据的连续性至关重要。
6.5 Podcasting 2.0 的采纳现状
截至 2024 年,Podcasting 2.0 的各项标签已经得到了越来越广泛的支持:
| 类别 | 支持情况 |
|---|---|
| 播客客户端 | Fountain、Pocket Casts、Overcast(部分)、Podverse、Castamatic |
| 托管平台 | Buzzsprout、Captivate、Podbean(部分)、Transistor(部分) |
| 目录 | Podcast Index、Apple Podcasts(部分,如 transcript) |
| 不支持 | Spotify(完全不支持)、Apple Podcasts(仅支持极少数标签) |
值得注意的是,苹果在 2023 年开始支持 <podcast:transcript> 标签,这是 Podcasting 2.0 标准被主流平台采纳的重要里程碑。
第七章 中国播客生态的独特景观
在全球播客生态的大背景下,中国播客的发展走出了一条独特的道路。
7.1 封闭生态的早期主导
由于苹果播客在中国的访问受限,以及 Spotify 的缺席,中国本土涌现出了喜马拉雅、荔枝、蜻蜓 FM 等音频平台。
这些平台早期主要采用封闭的中心化分发模式,创作者需要手动上传音频,用户也只能在特定的 App 内收听。它们更接近于"网络电台"而非真正意义上的"播客"——因为它们不提供 RSS Feed,听众无法通过泛用型播客客户端订阅。
喜马拉雅是这个时期最成功的平台之一。它不仅提供免费内容,还推出了付费专栏功能,让知识付费的概念在中国音频领域得到了充分的验证。
7.2 小宇宙的崛起:开放与封闭的平衡
2020 年 3 月,小宇宙 App 正式上线,这是中国第一个真正意义上的播客客户端 [18]。
小宇宙的出现,将"播客"与"网络电台"区分开来:它全面支持 RSS 订阅,用户可以通过 RSS Feed 订阅任何播客;同时,它也提供了一个内容托管平台,让创作者可以直接在小宇宙上发布节目。
小宇宙的创新之处,在于它将开放的 RSS 生态与本土化的社区运营相结合:
- 基于时间戳的评论:听众可以在节目的任意时间点留下评论,主播和其他听众可以看到这些评论。这种互动方式,在西方播客平台上几乎是不存在的。
- 节目内互动:听众可以对节目进行"想听"、"在听"、"听过"等状态标记,形成一个类似豆瓣的播客评分和推荐系统。
- 创作者工具:小宇宙为创作者提供了详细的数据分析工具,帮助他们了解听众的收听行为。
7.3 RSS 在中国的特殊处境
然而,RSS 在中国面临着一些特殊的挑战。
2020 年,苹果从中国区 App Store 下架了多款 RSS 阅读器,理由是这些应用可能被用于访问"未经审查的内容"。这一事件,让中国的 RSS 用户感受到了开放网络的脆弱性。
对于播客创作者来说,RSS Feed 的重要性在于它提供了一种"抗审查"的内容分发机制。正如中国播客《Loud Murmurs》的创始人 Afra Wang 所说:"当我的节目在喜马拉雅上被删除时,我失去了数千名订阅者和所有的互动记录。但因为我们有 RSS Feed,节目的内容依然可以通过其他客户端访问。"
英文原文:"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."
这个故事,生动地说明了 RSS 的开放性对于内容创作者的重要意义:它是一种不依赖任何单一平台的内容分发机制,是创作者对抗平台风险的最后防线。
第八章 JSON Feed 与播客的未来
在 XML 命名空间不断扩展的同时,另一股技术潮流也在涌动。
8.1 JSON Feed:现代开发者的选择
虽然 XML 曾经是数据交换的王者,但在现代 Web 开发中,JSON 才是绝对的主流。JSON 的语法更简洁,更容易被 JavaScript 处理,也更符合现代 API 的设计风格。
2017 年,Manton Reece 和 Brent Simmons 发布了 JSON Feed 规范,旨在用 JSON 格式重写 RSS/Atom [19]。
一个简单的 JSON Feed 看起来是这样的:
{
"version": "https://jsonfeed.org/version/1.1",
"title": "My Example Podcast",
"home_page_url": "https://example.com",
"feed_url": "https://example.com/feed.json",
"description": "An example podcast feed in JSON format",
"items": [
{
"id": "https://example.com/episode1",
"url": "https://example.com/episode1",
"title": "Episode 1: Getting Started",
"content_html": "<p>Full HTML content here.</p>",
"date_published": "2024-01-01T00:00:00Z",
"attachments": [
{
"url": "https://example.com/ep1.mp3",
"mime_type": "audio/mpeg",
"size_in_bytes": 12345678,
"duration_in_seconds": 3600
}
]
}
]
}与 XML 相比,JSON Feed 的优势显而易见:
- 无需处理 XML 命名空间的复杂性
- 无需 CDATA 包裹 HTML 内容
- 对 JavaScript 开发者更加友好
- 文件体积通常更小
然而,JSON Feed 在播客领域的采纳率依然很低。主要原因是:现有的播客生态系统(客户端、托管平台、目录)都是围绕 RSS 2.0 构建的,迁移成本极高。
8.2 PSP-1:播客标准项目的统一尝试
2022 年,一个名为 Podcast Standards Project(播客标准项目) 的组织发布了 PSP-1 规范,试图在 RSS 2.0 的基础上,整合 itunes: 命名空间和 podcast: 命名空间,形成一个统一的播客 RSS 标准 [20]。
PSP-1 规范明确规定,一个合规的播客 RSS Feed 必须同时包含以下三个命名空间:
<rss version="2.0"
xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:podcast="https://podcastindex.org/namespace/1.0"
xmlns:atom="http://www.w3.org/2005/Atom">这个规范的意义在于,它试图在苹果的 itunes: 命名空间(代表现有标准)和 Podcasting 2.0 的 podcast: 命名空间(代表未来方向)之间架起一座桥梁,推动整个行业向更统一、更开放的方向发展。
8.3 视频播客的崛起与 RSS 的新挑战
近年来,随着 YouTube 和 Spotify 对视频播客的大力推广,视频播客(Video Podcast)正在成为一种重要的内容形式。
然而,视频播客对 RSS 生态带来了新的挑战:
- 文件大小:视频文件比音频文件大得多,
<enclosure>标签中的length属性可能会变得非常大。 - 多格式支持:同一期节目可能同时有音频版和视频版,如何在 RSS Feed 中优雅地表示这两种格式?
- 平台差异:YouTube 和 Spotify 的视频播客并不依赖 RSS Feed,而是使用各自的专有格式,这进一步加剧了播客生态的碎片化。
Podcasting 2.0 的 podcast: 命名空间中,<podcast:alternateEnclosure> 标签试图解决多格式支持的问题:
<podcast:alternateEnclosure type="video/mp4" length="500000000" bitrate="2000000">
<podcast:source uri="https://example.com/ep1.mp4"/>
</podcast:alternateEnclosure>
<podcast:alternateEnclosure type="audio/mpeg" length="50000000" bitrate="128000">
<podcast:source uri="https://example.com/ep1.mp3"/>
</podcast:alternateEnclosure>第九章 对播客创作者的实用指南
了解了播客 RSS 的历史和技术细节之后,让我们回到实际操作层面,为播客创作者提供一些具体的建议。
9.1 选择合适的托管平台
播客托管平台的选择,直接决定了你的 RSS Feed 的质量和功能。以下是几个主要平台的对比:
| 平台 | 命名空间支持 | Podcasting 2.0 支持 | 适用场景 |
|---|---|---|---|
| Buzzsprout | itunes + atom + podcast | 较好 | 入门级创作者 |
| Simplecast | itunes + atom + content | 一般 | 专业媒体机构 |
| Transistor | itunes + content + dc | 较好 | 独立创作者 |
| Captivate | itunes + atom + podcast | 好 | 注重新功能的创作者 |
| Libsyn | itunes + atom | 一般 | 老牌平台,稳定可靠 |
| 小宇宙 | itunes + content | 无 | 中文播客创作者 |
9.2 必须配置的 RSS 标签
无论你使用哪个托管平台,以下标签都是必须正确配置的:
频道级别(Channel Level)
<title>:节目名称,简洁明了,不超过 255 个字符。<description>或<itunes:summary>:节目简介,清楚描述节目内容和目标听众。<itunes:image>:节目封面,必须是 JPEG 或 PNG 格式,推荐尺寸为 3000×3000 像素(苹果要求最小 1400×1400,最大 3000×3000)。<itunes:category>:节目分类,直接影响节目在各大目录中的可发现性。<itunes:author>:主播姓名或机构名称。<itunes:explicit>:是否包含成人内容,必须如实填写。<language>:节目语言,中文播客应填写zh-CN。
单集级别(Item Level)
<title>:单集标题,建议包含集数编号(如"第 42 期:…")。<enclosure>:音频文件的 URL、大小和类型,这是播客的核心标签。<pubDate>:发布时间,格式为 RFC 2822(如Mon, 01 Jan 2024 00:00:00 +0800)。<guid>:全局唯一标识符,通常使用节目的永久链接,必须在所有单集中保持唯一。<itunes:duration>:音频时长,格式为秒数(如3600)或HH:MM:SS(如01:00:00)。<itunes:episodeType>:节目类型,full(完整集)、trailer(预告)或bonus(奖励集)。
9.3 进阶配置:拥抱 Podcasting 2.0
如果你希望为听众提供更好的收听体验,并在支持 Podcasting 2.0 的客户端上获得更多曝光,可以考虑添加以下标签:
- 添加逐字稿:使用
<podcast:transcript>提供节目的文字稿,不仅方便听障人士,也有助于 SEO。 - 添加章节:使用
<podcast:chapters>提供章节信息,让听众可以快速跳转到感兴趣的部分。 - 添加
<podcast:guid>:为你的播客添加全局唯一标识符,方便未来迁移托管平台时保持订阅数据的连续性。 - 添加人员信息:使用
<podcast:person>标注主播和嘉宾信息,提升节目的专业度。
9.4 常见的 RSS 配置错误
以下是播客创作者最常犯的 RSS 配置错误:
- 封面图尺寸不符合要求:苹果要求封面图必须在 1400×1400 到 3000×3000 像素之间,且必须是正方形。许多创作者使用了非正方形的封面图,导致在某些客户端中显示异常。
<enclosure>的length属性不准确:length属性应该是音频文件的实际字节大小。如果这个值不准确,一些客户端可能无法正确显示下载进度。<guid>重复:每个单集的<guid>必须是唯一的。如果多个单集使用了相同的<guid>,客户端可能会将它们识别为同一集,导致更新无法被检测到。<pubDate>格式错误:<pubDate>必须严格遵循 RFC 2822 格式。常见的错误包括使用了 ISO 8601 格式(如2024-01-01T00:00:00Z),这在某些客户端中可能无法被正确解析。- Feed URL 变更后未使用
<itunes:new-feed-url>:当你迁移托管平台时,必须在旧的 Feed 中添加<itunes:new-feed-url>标签,指向新的 Feed 地址。否则,已有的订阅者将无法自动更新到新的 Feed。
第十章 结语:为什么我们需要关心 RSS?
在这个大厂纷纷筑起高墙、试图将用户圈禁在自家 App 里的时代,播客是少数几个依然坚持"开放网络(Open Web)"精神的媒介。
理解播客 RSS 的不同格式和命名空间,不仅仅是技术上的考古,更是对这种开放精神的致敬。
10.1 一部关于人的历史
回顾这段历史,我们看到的不仅仅是技术的演进,更是一群有血有肉的人的故事:
Dave Winer,这个脾气火爆、固执己见的极客,凭借着对"简单"的执着,创造了 RSS 2.0 和 <enclosure> 标签,为播客的诞生奠定了技术基础。他的 Scripting News 博客至今仍在更新,他依然是互联网上最活跃的技术评论者之一。

Adam Curry,这个从 MTV 走出来的媒体人,凭借着对音频传播的热情,将 <enclosure> 标签变成了一种全新的媒介。他后来发起的 Podcasting 2.0 运动,再次展现了他对开放播客生态的执着。

Aaron Swartz,这个在 14 岁就参与制定 RSS 1.0 的天才少年,用短暂的 26 年生命,践行了他对"信息自由"的信仰。他的故事,是互联网历史上最令人心碎的篇章之一。

Ben Hammersley,这个在写文章时随手造了一个词的英国记者,无意间为一个全新的媒介命了名。

10.2 开放的价值
播客之所以能够发展成为今天价值数百亿美元的产业,很大程度上得益于其开放的 RSS 生态。
在 Spotify 和 Apple Podcasts 的"围墙花园"之外,依然存在着一个开放的播客生态系统:任何人都可以创建 RSS Feed,任何人都可以开发播客客户端,任何人都可以建立播客目录。这种开放性,降低了内容创作的门槛,也保护了创作者不被单一平台所绑架。
正如中国播客创作者 Afra Wang 的故事所展示的:RSS Feed 是创作者对抗平台风险的最后防线。当你的节目在某个平台上被删除时,只要你有 RSS Feed,你的内容就依然可以被听众访问。
10.3 技术的背后是哲学
从 1999 年网景的门户之争,到 Dave Winer 执拗地守护 RSS 2.0 的简单性;从 Adam Curry 写下第一行 iPodder 脚本,到今天 Podcasting 2.0 试图用比特币打赏重塑商业模式……这背后,是一代代极客为了让信息自由流动而付出的努力。
无论是 20 年前 Dave Winer 写下的 <enclosure>,还是今天 Adam Curry 推动的 <podcast:value>,它们都在证明一件事:真正伟大的技术,不应该属于某一家公司,而应该属于每一个愿意发声、愿意倾听的人。
下次当你打开播客客户端时,不妨在心里默默感谢一下那些在背后运转的 XML 标签。正是它们,跨越了二十多年的时光,将世界各地的声音,精准地送到了你的耳边。
附录:播客 RSS 发展大事记
| 年份 | 事件 |
|---|---|
| 1997 | Dave Winer 为 Scripting News 设计 XML 格式;Guha 在苹果开发 MCF |
| 1998 | AOL 收购网景;Guha 加入网景开始开发 RSS |
| 1999 | 网景发布 RSS 0.90(RDF Site Summary);Dave Winer 发布 ScriptingNews 2.0b1;网景发布 RSS 0.91(Rich Site Summary) |
| 2000 | RSS-DEV 工作组成立;14 岁的 Aaron Swartz 参与 RSS 1.0 开发;RSS 1.0 发布;Dave Winer 在 RSS 0.92 中引入 <enclosure> 标签 |
| 2001 | Dave Winer 首次演示 RSS 音频附件;AOL 重组网景,RSS 失去官方维护者 |
| 2002 | Dave Winer 发布 RSS 2.0(Really Simple Syndication) |
| 2003 | Dave Winer 将 RSS 2.0 捐赠给哈佛大学并"冻结";Sam Ruby 发起 Atom 项目;Dave Winer 为 Christopher Lydon 创建第一个播客 RSS Feed |
| 2004 | Ben Hammersley 在《卫报》创造"podcast"一词;Adam Curry 推出 iPodder;Adam Curry 创办《Daily Source Code》;"podcast"被评为年度词汇 |
| 2005 | 苹果在 iTunes 4.9 中整合播客,推出 itunes: 命名空间;IETF 发布 Atom 1.0(RFC 4287);Google 推出 Google Reader |
| 2006 | 苹果 iTunes 播客目录突破 10 万个节目 |
| 2013 | Google 关闭 Google Reader;Aaron Swartz 去世 |
| 2017 | JSON Feed 规范发布 |
| 2019 | Spotify 收购 Gimlet Media 和 Anchor |
| 2020 | Spotify 签下 Joe Rogan 独家协议;Adam Curry 和 Dave Jones 发起 Podcasting 2.0,推出 podcast: 命名空间;小宇宙 App 上线 |
| 2022 | Podcast Standards Project 发布 PSP-1 规范 |
| 2023 | 苹果开始支持 <podcast:transcript> 标签 |
| 2024 | Spotify 结束 Joe Rogan 独家协议;Podcasting 2.0 标签被越来越多平台采纳 |
参考资料
[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] Gizmodo: Why Dave Winer Invented the Blog. https://gizmodo.com/why-dave-winer-invented-the-blog-5926282
[4] RSS Advisory Board: RSS History. https://www.rssboard.org/rss-history
[5] Wikipedia: History of web syndication technology. https://en.wikipedia.org/wiki/History_of_web_syndication_technology
[6] Wikipedia: Aaron Swartz. https://en.wikipedia.org/wiki/Aaron_Swartz
[7] Berkman Klein Center: RSS 2.0 Specification. https://cyber.harvard.edu/rss/rss.html
[8] RSS 2.0 Specification moves to Berkman. https://cyber.harvard.edu/rss/announceRss2.html
[9] Wikipedia: Atom (web standard). https://en.wikipedia.org/wiki/Atom_(web_standard)
[10] Wikipedia: History of podcasting. https://en.wikipedia.org/wiki/History_of_podcasting
[11] Ben Hammersley About Page. https://benhammersley.com/about
[12] Wikipedia: Daily Source Code. https://en.wikipedia.org/wiki/Daily_Source_Code
[13] 512 Pixels: Ten years ago, Apple brought podcasting to iTunes. https://512pixels.net/2015/06/ten-years-ago-apple-brought-podcasting-to-itunes/
[14] The Guardian: Spotify buys podcast firms Gimlet and Anchor. https://www.theguardian.com/technology/2019/feb/06/spotify-buys-podcast-firms-gimlet-and-anchor-streaming-profits-music
[15] BBC: Why Joe Rogan's exclusive Spotify deal matters. https://www.bbc.com/news/entertainment-arts-52736364
[16] Libsyn Blog: The Podcast Index & Podcast 2.0 Namespace. https://libsyn.com/blog/the-podcast-index-podcast-2-0-namespace/
[17] Podcasting 2.0 Namespace: Value. https://podcasting2.org/docs/podcast-namespace/tags/value
[18] Rest of World: What Spotify and Apple can learn from Chinese podcasting apps. https://restofworld.org/2021/what-spotify-and-apple-can-learn-from-chinese-podcasting-apps/
[19] JSON Feed Version 1. https://www.jsonfeed.org/version/1/
[20] Podcast Standards Project: PSP-1 Specification. https://github.com/Podcast-Standards-Project/PSP-1-Podcast-RSS-Specification