RSS 提要 XML 文件有多大？答案

【问题标题】：How big is too big for an RSS feed XML file?RSS 提要 XML 文件有多大？
【发布时间】：2011-07-16 04:30:14
【问题描述】：

我正在为网站实现 RSS 提要，但我不了解提要的 XML 文件的格式/大小/内容。

我正在用过去的数据初始化网站，这些数据可以追溯到 1999 年（之前的任何时候都没有提要），每年只会添加几百个项目。

是否有一些存档协议，或者我可以只保留一个文件并继续附加到它吗？我认为这将是低效的，因为聚合器必须下载整个东西（我假设）。

那么，这通常的习惯是什么？限制在上个月？当前包含 900 多个项目的文件为 1.5MB，我预计 1 年的价值约为该大小的 1/10 或更小。

关于使用什么原则以及如何实现它的任何指针？我正在使用 PHP，但是我的数据足够复杂，我滚动了自己的脚本来编写文件（并且它验证得很好），所以我不能使用罐装解决方案——我需要了解自己要实现什么脚本。

【问题讨论】：

你用了什么魔法来得到答案？ 3 个月前它对我的帮助会大得多！
我曾经是一个联合极客，这个问题本质上是架构性的，而不是技术性的。我唯一没有提到的是确保通过validator.w3.org/feed 运行您的最终提要，这将为您和您的消费者节省很多心痛！
@david 我稍微编辑了你的语法，以免冒犯用户，当你编辑问题时，问题的排名更高，知名度更高
好吧，我不同意您的标签编辑——我的问题与 PHP 或脚本无关。我的问题完全是关于 RSS 输出格式的。但我不会管它，因为我得到了我需要的答案（比我需要的晚了 90 天）。
@Oppositional：是的，我反复验证了我的提要。如果我不是，我会完全一无所知——我实际上使用了feedvalidator.org 而不是 w3 验证器，因为它对所有出现的事情都有很多非常具体的帮助。它实际上是关于如何正确使用它的教程！

【解决方案1】：

大多数联合提要的消费者都期望提要包含相对较新的内容，而以前发布的内容会从提要中“脱落”。您在 Feed 中维护的内容量通常取决于您发布的内容类型，但随着 Feed 大小的增加，它可能会影响 Feed 客户端检索和解析您的信息的能力。

如果您确实想要发布不断添加但从未删除内容项的历史提要，您可能需要考虑以下选项（根据您的消费者的需求）：

实现Feed Paging and Archiving、per RFC 5005 Section 3，因为当条目数非常大、无限或不确定时，分页提要很有用。客户可以“翻页”浏览提要，只在必要时访问提要条目的子集。
将您的内容逻辑分割成多个提要，并为您网站上的提要提供auto-discovery。
实现基于 REST 的服务接口，允许消费者检索和过滤您的内容作为 Atom 或 RSS 格式的提要，默认表示使用一些合理的默认值。

选项 1 仅当您知道将使用您的提要的提要客户端的类型时才是合理的方法，因为并非所有提要客户端都支持分页。

选项 2 是面向公众的网站上最常见的选项，因为大多数浏览器和客户端都支持自动发现，您可以提供完整的历史提要和较小的更新内容提要（或以对您的内容有意义的方式进行细分）。

选项 3 可能让您提供前两个选项的好处，此外，您还可以提供多种供稿格式和丰富的内容过滤。这是一种非常有效的公开提要内容的方法，但通常只有在您的消费者表示希望定制他们希望使用的提要内容时才值得付出努力。

虽然大多数富 Feed 客户端会异步检索 Feed 内容，但随着 Feed 大小的增加，对您的 Feed 发出同步（并且可能是频繁）请求的客户端可能会遇到超时问题。

无论您采取什么方向，都可以考虑在您的供稿上实施Conditional GET；并了解您的联合内容的潜在消费者，以便选择最适合的策略。当您考虑要提供哪种联合供稿格式时，请参阅 this answer。

【讨论】：

我实际上最终将提要实现为脚本，因此我可以提供多个子提要。我还在检索数据的 SQL 上设置了一个 LIMIT。我最终意识到，提供整个提要只在一开始对我很重要，但对任何订阅它的人来说可能都无关紧要。感谢您的出色回答。我已经归档了您的一些引用以供进一步调查，特别是在提供最后更新的标题的问题上。

【解决方案2】：

聚合器会重复下载文件，因此限制大小很重要。我会让提要包含 10 个项目，或者拥有一周内最旧的项目，以提供更多条目为准，除非被 GET 参数覆盖。当然，这会因您从客户那里看到的实际使用情况以及供稿本身的活动而异。

【讨论】：