RSS-лента

Происхождение и история термина

RSS Advisory Board относит выпуск RSS 0.90 компанией Netscape к 15 марта 1999 года и указывает автором Раманатана Гуху. В июле того же года Netscape опубликовала RSS 0.91 Дэна Либби. Дальнейшая линия UserLand связана с Дейвом Вайнером; её RSS 2.0 датирован 19 августа 2002 года. Это история конкретной ветви формата: сама передача веб-содержимого между системами существовала и раньше. ^[2]

В RSS 2.0 название раскрывается как Really Simple Syndication — буквально «очень простая синдикация», то есть распространение содержимого для дальнейшего использования другими программами. На 23 октября 2026 года RSS Advisory Board обозначает текущей редакцию спецификации 2.0.11 от 30 марта 2009 года. В самом XML при этом остаётся version="2.0": номер редакции документа со спецификацией и номер формата различаются. ^{[1, 2]}

Atom 1.0 описан в RFC 4287, опубликованном в декабре 2005 года. RFC — серия технических документов; в данном случае документ задаёт формат веб-синдикации и метаданных, то есть сведений о записях. Atom решает сходную задачу, но не является новой версией RSS. ^[4]

Суть и механизм

Представим учебную городскую редакцию. Она выпускает новости о транспорте, культуре и благоустройстве. Читателю нужна подборка обновлений из нескольких изданий. Программа чтения, или агрегатор, получает их ленты и показывает записи в своём интерфейсе; такое периодическое получение и представление пользователю описано в RSS Profile. Сам документ передаёт сведения, а внешний вид списка определяет программа. ^[3]

В нашей учебной схеме редакция публикует статью, генератор собирает ленту, а получатель запрашивает её и сравнивает записи с уже сохранёнными. Это три разных события. Если статья вышла в десять утра, а в программе появилась позже, одно время ещё не объясняет задержку: необходимо установить, когда обновилась выгрузка и когда её получил клиент.

У канала обязательны title, link и description: название, адрес соответствующего сайта и описание. Запись должна содержать хотя бы title или description; оба поля тоже допустимы. Поэтому базовый RSS не требует полного текста каждой новости. ^[1]

Как программа узнаёт прежнюю новость

guid — глобально уникальный идентификатор записи, строка для распознавания материала. RSS Profile рекомендует указывать его у каждой записи. Если стоит isPermaLink="false", строка может быть придуманным издателем идентификатором, а не адресом страницы. ^[3]

В учебном примере новость о выставке имеет идентификатор example.com:article:42. Редактор исправляет заголовок, затем переносит статью на другой адрес. Для проверки мы сохраняем идентификатор, но меняем ссылку. Получатель, который сравнивает guid, сможет связать две выгрузки с одной записью. Если генератор каждый раз выдаёт новый идентификатор, эта связь теряется: изменение текста может выглядеть как новый материал. Это следствие выбранного способа сравнения, а не обещание одинакового поведения всех клиентов. Спецификация допускает использование guid агрегатором, но не навязывает единственный алгоритм. ^[1]

pubDate записи означает время её публикации. lastBuildDate канала относится к последнему обновлению содержимого ленты. ^[3] В нашем примере повторное создание файла в полдень не превращает утреннюю новость в новую публикацию. При диагностике эти события стоит записывать отдельно: тогда видно, что именно изменилось после редакторской правки.

Виды и классификации

RSS и Atom

Пространство имён — указание, к какому словарю разметки относятся элементы. У Atom это http://www.w3.org/2005/Atom; оно помогает отличать его элементы от одноимённых элементов других форматов. ^[4] Переименование учебного файла из news.rss в news.atom не перестраивает содержимое. Чтобы преобразовать ленту, нужно сопоставить поля и выполнить требования другого формата.

Полный набор, страницы и архив

RFC 5005 различает три способа организации записей. Полная лента представляет весь логический набор в одном документе. Постраничная распределяет его между связанными временными документами: пока клиент переходит со страницы на страницу, их содержимое может измениться. Архивная связывает свежие записи с постоянными архивными документами, позволяя восстановить набор без потери записей. Документ описывает эти механизмы на основе Atom, а информативное приложение B показывает их применение к RSS 2.0. ^[5]

Логический набор — все записи, которые относятся к выбранной ленте; это не обязательно весь сайт. Учебная лента отдела культуры может содержать все его публикации и не включать транспортные новости. Полноту оценивают относительно назначенной области, иначе любой тематический отбор будет ошибочно выглядеть потерей данных.

Длина статьи — другой вопрос. Вообразим два учебных файла: первый содержит анонсы всех ста публикаций выставочного проекта, второй — полные тексты только десяти последних. Первый полон по выбранному набору, второй нет. Из слов «полнотекстовая лента» нельзя узнать, доступна ли через неё история проекта. Различие следует из определения логической ленты в RFC 5005. ^[5]

Как применяется на практике

Одна запись в XML

Собственный учебный пример показывает выставочную новость. Это не выгрузка действующего издания:

```xml

https://example.com/ Сообщения учебного проекта https://example.com/news/exhibition Экспозиция посвящена истории города. example.com:article:42 Fri, 23 Oct 2026 10:00:00 GMT ```

Вложенность читается как папки: название редакции находится в канале, а заголовок выставочной новости — внутри записи. Если переместить заголовок новости на уровень канала, XML может остаться синтаксически правильным, но программа получит другое сообщение об источнике. Так учебный пример показывает, почему проверки скобок и кавычек недостаточно.

Передача поисковым системам

Google разрешает передавать RSS 2.0 и Atom 1.0 как Sitemap — файл, сообщающий поисковой системе об адресах сайта. Его документация предупреждает, что автоматически создаваемая лента обычно содержит сведения лишь о недавних адресах. Передача такой ленты поэтому не равнозначна передаче полного архива сайта. <sup>[7]</sup>

Российский пример — раздел «Свежее и актуальное» Яндекс Вебмастера. Его справка требует передавать у сообщения заголовок, адрес, время публикации и полный текст. Для текста предусмотрен yandex:full-text; подробная таблица допускает вместо него content:encoded, который тогда становится обязательным. Это профиль конкретной интеграции, а не общие требования RSS. <sup>[6]</sup>

Сравниваются две конкретные задачи. Например, учебная лента с коротким анонсом может соответствовать базовому RSS, но не передать полный текст, нужный указанному профилю Яндекса. Исправление в таком случае касается подготовки данных для получателя. Для интеграции с Дзеном нужна отдельная проверка его правил; данный образец её не выполняет.

Как измерить или проверить

Начать удобно с учебной публикации, содержание которой известно редактору. Сохраните две выгрузки: до исправления заголовка и после него. Проверьте, где находится запись, изменился ли её текст и сохранился ли идентификатор. Затем сравните эти файлы с тем, что показывает получатель. Это предложенный редакцией способ локализовать проблему, а не нормативная процедура для всех агрегаторов.

Первый уровень проверки — XML: правильно ли вложены элементы и допустимы ли символы. В обычном текстовом содержимом символы & и < нужно экранировать, например записывать как & и <. <sup>[8]</sup> Затем проверяют структуру RSS, требования получателя и ожидаемый состав записей. Каждый уровень может дать собственную ошибку, поэтому общего сообщения «лента работает» для диагностики мало.

Сколько записей можно пропустить

В учебной модели получатель успешно забирает ленту в 10:00 и 10:30. Издатель хранит только последние двадцать записей по порядку добавления. Между запросами выходят тридцать пять новых записей; промежуточных запросов, архивных страниц и других способов восстановления нет. К 10:30 первые пятнадцать новинок уже вытеснены. Такая задача возникает из-за ограниченного окна истории, описанного в RFC 5005. <sup>[5]</sup>

Для этой модели обозначим число новых записей между запросами через N, вместимость окна через K, число недоступных в следующей копии новинок через M. Все три величины измеряются в записях, а не в минутах или процентах:

В нашем случае из тридцати пяти вычитаем двадцать и получаем пятнадцать. Если новых записей ровно двадцать, все помещаются; если новых записей нет, потерь тоже нет. Отрицательный результат заменяется нулём: «минус пять пропущенных новостей» не имеет смысла. Это детерминированный расчёт при заданных условиях, не вероятность пропуска.

Условие о порядке добавления существенно. Если редакция поднимает старые записи наверх, исключает часть рубрик или получатель использует архив, формула уже не описывает всю ситуацию. Частота выхода новостей также может меняться: среднее число публикаций за сутки не доказывает, что короткое окно выдержит любой получасовой всплеск. Для такой проверки нужны фактические последовательности публикаций и запросов.

Учебный генератор

Приложение «Учебный генератор RSS 2.0» создаёт один канал и одну запись. Заполните сведения об источнике, заголовок, адрес, описание, время публикации и отдельный guid. Идентификатор выводится с isPermaLink="false": его можно сохранить при изменении адреса материала. Уникальность среди других публикаций остаётся задачей издателя — генератор не хранит базу записей.

Форма принимает время только в UTC, всемирном координированном времени, в записи 2026-10-23T10:00:00Z. В XML оно превращается в дату RSS с обозначением GMT; это форматирование одного момента, а не перевод местного времени. Несуществующие даты отклоняются. Ограничения формы — годы от 1900 до 9999, только HTTP(S)-адреса и заполненные восемь полей — выбраны для учебного инструмента, а не объявлены минимумом стандарта.

Описание записи вводится как обычный текст. Инструмент сначала подготавливает его для HTML-представления, затем экранирует для XML: RSS Profile рассматривает item/description как содержимое, пригодное для показа в HTML. <sup>[3, 8]</sup> Поэтому введённое <b>афиша</b> должно остаться текстом с угловыми скобками, а не стать командой выделения. По этому же правилу сохраняются буквальные последовательности вроде &.

Кнопка сброса возвращает учебные значения и очищает результат. Генератор не получает чужие ленты, не проверяет сайт и не отправляет XML наружу. Результат предназначен для разбора структуры и ручного копирования; для постоянно обновляемого издания потребуется собственный процесс формирования ленты.

Ошибки, ограничения и спорные вопросы

Смена guid при каждой правке способна создавать повторы у клиента, который определяет новизну по этому полю. Обратная ошибка — присвоить один идентификатор разным материалам: тогда такой клиент может принять новую статью за уже известную. Это две стороны одной учебной модели сравнения строк. В Atom требование сохранять идентификатор при пересмотре записи закреплено прямо. <sup>[3, 4]</sup>

Работающий XML-парсер не проверяет достоверность заголовка, полноту архива или соответствие записи статье на сайте. Так, в учебном примере ссылка может вести на другую выставку, хотя все элементы будут закрыты правильно. Содержательную проверку выполняют сопоставлением с публикацией, а техническую — средствами разбора формата.

Чужое содержимое требует отдельной обработки. RFC 4287 предупреждает об опасных возможностях HTML/XHTML внутри Atom, включая исполняемое содержимое; корректность внешнего XML не делает такую разметку безопасной для вставки в интерфейс. <sup>[4]</sup> Документация W3C Feed Validation Service отдельно отмечает риск внешних SYSTEM-сущностей и рекомендует самодостаточную ленту. <sup>[9]</sup>

RSS Profile опубликован в 2007 году и содержит результаты испытаний тогдашних программ. Его рекомендации помогают понять совместимость, но перечень протестированных клиентов нельзя превращать в описание современного рынка. <sup>[3]</sup> Для конкретного получателя полезно повторять проверку после изменения генератора или правил интеграции и сохранять дату вместе с результатом.

Частые вопросы

Связанные термины

• SEO для СМИ