Лента новостей

Newsfeed

Лента новостей — обновляемый список записей о новостных материалах, который человек просматривает на сайте или в приложении, а программа может получать в специальном формате. Записи содержат новости целиком либо сведения о них, например заголовки и ссылки.

Это рабочее определение объединяет два описания: в стандарте Atom лента состоит из связанных записей со сведениями о каждой, а в JSON Feed список и сами записи могут изменяться со временем. Здесь определение относится к новостным материалам; оба формата подходят и для другого содержания. [2, 3]

Кратко

  • Лента помогает следить за поступлением материалов, но её последняя порция может не содержать всего архива. [4]
  • Страница для читателя и файл для программы — разные представления новостного потока.
  • RSS — один из форматов передачи записей, а не название любого списка новостей. [1]
  • Новая публикация и исправление уже опубликованной новости требуют разных действий; JSON Feed различает их через постоянный идентификатор записи. [3]
  • Возможность получить чужой текст технически не решает вопрос о праве его перепубликовать. [7]

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

Историю интернет-ленты удобно проследить по документам об обмене публикациями. RSS Advisory Board перечисляет этапы своей линии спецификаций: RSS 0.91 — июнь 2000 года, RSS 0.92 — декабрь 2000 года, RSS 2.0 — август 2002 года. Действующая страница спецификации обозначена как версия 2.0.11 от 30 марта 2009 года. [1] Это даты технических документов, а не дата изобретения новостного потока.

В декабре 2005 года вышел RFC 4287 — документ серии интернет-спецификаций, описывающий Atom. Его редакторы — Марк Ноттингем и Роберт Сейр. Среди задач формата названа передача веб-публикаций, включая новостные заголовки, другим сайтам и программам читателя. [2] В сентябре 2007 года Ноттингем в RFC 5005 описал, как разделять ленту между несколькими документами и обозначать полноту набора. [4]

Развитие продолжилось другими способами записи данных. JSON Feed Брента Симмонса и Мантона Риса использует JSON вместо XML — двух разных способов представить данные в текстовом файле. [3] Для понимания ленты важен общий принцип этих решений: издатель передаёт материалы в структуре, которую получатель способен разобрать автоматически. [1, 2, 3]

Эти этапы объясняют появление совместимых способов обмена. Они не устанавливают первого автора выражения «лента новостей». Понятие здесь шире одного формата: читателю нужен понятный поток сообщений, а программе — точное описание того, какие записи поступили и что в них изменилось.

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

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

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

У записи есть идентификатор — значение, по которому программа отличает её от других. В RSS для этого предусмотрен необязательный элемент guid; отдельная запись обозначается item, а сведения о канале помещаются в channel. RSS позволяет передать как краткое описание со ссылкой, так и самостоятельный текст записи. [1] Поэтому наличие ленты ещё не отвечает на вопрос, получает ли подписчик весь материал.

В JSON Feed идентификатор id обязателен. Спецификация рекомендует сохранять его при изменении записи и не использовать старое значение для новой. Дата публикации date_published и дата изменения date_modified — отдельные необязательные поля. [3] Человеку различие понятно по смыслу: «мы исправили время открытия» и «мы сообщили о новом событии». Программе нужны данные, позволяющие провести такое же различие.

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

Порядок показа — ещё одно решение. Activity Streams 2.0, модель для описания действий и объектов в интернете, различает обычную коллекцию и OrderedCollection, то есть коллекцию с заданным порядком. Для её элементов используется поле orderedItems. [5] Само наличие порядка не объясняет его причину. В учебной редакции можно поставить важное предупреждение первым, даже если после него вышла менее значимая новость. Это редакционный выбор, который следует отличать от сортировки по времени.

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

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

По составу удобно различать общую, рубричную и тематическую ленты. В учебном издании общая содержит все выбранные для неё новости, рубричная — материалы раздела «Город», тематическая — публикации о транспорте из разных разделов. Если читатель открыл транспортную подборку, отсутствие новости о школьном конкурсе само по себе не означает неполноту.

По расположению можно выделить порядок публикации, редакционную подборку и автоматический отбор. В первом случае важна дата, во втором — решение редактора, в третьем — правила, по которым программа выбирает и располагает записи. Сочетание возможно: учебная лента показывает новые материалы сверху, но сохраняет закреплённое предупреждение перед ними. Поэтому описание «сначала новое, кроме закреплённого» точнее одного слова «хронологическая».

По полноте передачи есть отдельная классификация RFC 5005. Complete feed содержит весь набор записей в одном документе; paged feed распределяет записи по временным документам; archived feed — по постоянным архивным частям. [4] Здесь «весь набор» означает набор именно этой ленты, а не обязательно всё, что когда-либо выпустило издание.

Представим учебный экспорт последних двадцати публикаций. После выхода двадцать первой самая ранняя выпадает из файла, хотя её страница продолжает существовать. Это ограничение размера текущей порции. Назвать такой файл полным архивом означало бы обещать получателю то, чего в нём нет. И наоборот, если заявлена полная лента по правилам RFC 5005, отсутствие записи имеет значение для её принадлежности этому набору. [4]

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

Один из вариантов международного обмена — объединение записей разных издателей. В Atom предусмотрен элемент atom:source, позволяющий сохранить сведения об исходной ленте при переносе записи в другую. [2] Такие сведения называют метаданными: они описывают материал или его источник, а не заменяют содержание новости.

Для учебной региональной подборки это различие существенно. Две газеты могут написать о том же мосте: одна сообщает о начале ремонта, другая публикует комментарий перевозчика. Совпадение темы не делает тексты дублями. Редактору нужны источник, адрес и содержание каждого сообщения. Иная ситуация — повторное получение одной и той же записи: здесь задача состоит в том, чтобы не показывать её как новое сообщение только потому, что файл загрузили ещё раз.

В России конкретный пример технического обмена описан в справке Яндекс Вебмастера «Свежее и актуальное». Она предусматривает передачу новых материалов в RSS 2.0. Адрес материала, или URL, должен вести на отдельную страницу с полным текстом; он служит уникальным идентификатором материала. Среди рекомендаций — свободный бесплатный доступ, причём требование регистрации считается ограничением доступа. [6]

Это условия определённого получателя. Для редакции из примера они означают, что ссылка на общую страницу «Город» не заменит адрес заметки о мосте. Нельзя проверить такую передачу, лишь убедившись, что заголовок виден в собственной ленте сайта. Нужно открыть именно передаваемую ссылку и сравнить содержание страницы с записью. При этом сама передача файла не означает гарантированного показа материала: справка отдельно оговаривает условия участия. [6]

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

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

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

Для проверки составим список из десяти ожидаемых материалов с разными идентификаторами. До оговорённого времени приложение показало девять из них. Простая полнота доставки — доля ожидаемых материалов, которые действительно появились:

C=UN×100%.C = \frac{U}{N}\times100\%.

Здесь (N) — число ожидаемых уникальных материалов, (U) — число найденных среди них, (C) — результат в процентах. В учебном примере девять делим на десять и умножаем на сто: получаем 90%. Знаменатель — исходный контрольный список, а не количество карточек, которое удалось увидеть.

Допустим, приложение дополнительно показало одну из этих девяти новостей повторно. На экране уже десять карточек, но ожидаемый десятый материал всё ещё отсутствует. Полнота остаётся 90%, потому что повтор не увеличивает число найденных уникальных материалов. Такой пример объясняет, почему считать карточки недостаточно. Если исходный список пуст, долю не рассчитывают: делить на ноль нельзя, а отсутствие ожидаемых материалов не доказывает успешную доставку.

Следующая величина — задержка. В учебном наблюдении материал опубликован в 10:00, появился в файле в 10:01, а в приложении — в 10:03. Все отметки относятся к одному дню и часовому поясу. Путь от публикации до файла занял одну минуту, от файла до приложения — две, весь путь — три. Если сообщить только «задержка — одна минута», читатель ошибочно примет время подготовки файла за время появления новости у себя.

Оговорим и точность наблюдения. Если проверяющий открывал приложение лишь в 10:00 и 10:03, он знает время обнаружения, но не точный момент появления карточки между проверками. Поэтому в протоколе нашего опыта нужно указать, откуда взяты отметки. Для сравнения двух попыток важны одинаковая точка наблюдения и одинаковый способ измерения.

Отдельно проверим исправления. В тестовом материале меняем заголовок, затем смотрим, обновилась ли существующая карточка и не возник ли повтор. После этого повторно получаем тот же файл без новых публикаций. Наконец, добавляем достаточно записей, чтобы старая вышла за пределы последней порции, и проверяем доступность её страницы. Это разные сценарии; успешная доставка новых материалов не заменяет проверку каждого из них.

Результат опыта нужно сохранить вместе с датой, контрольным списком, временем окончания и полученными записями. Такой протокол даёт возможность повторить расчёт и найти конкретный пропуск. Он характеризует проведённый тест, а не обещает, что лента всегда будет работать без ошибок.

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

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

Другая ошибка — принимать исчезновение из текущей порции за удаление публикации. RFC 5005 прямо различает логическую ленту, то есть весь связанный с ней набор, и документ, который может содержать лишь часть записей. [4] Поэтому прежде чем искать потерю, нужно выяснить, какой набор получатель обещает сохранять.

Есть и редакционный выбор между полнотой и отбором. Учебная подборка «Главное за день» намеренно пропускает второстепенные сообщения, тогда как поток всех новостей рубрики должен соответствовать своему заявленному составу. Оценивать их одним числом карточек бессмысленно: у них разные задачи. При этом объяснение отбора не должно скрывать случайные пропуски.

Наконец, соответствие формату и пригодность конкретному получателю проверяются отдельно. Например, общая спецификация RSS допускает самостоятельную запись без ссылки, а описанная интеграция Яндекса требует адрес отдельного материала. [1, 6] Файл может быть допустимым RSS и одновременно не выполнять условия этой интеграции.

Правовой аспект

При сборе чужих публикаций важно различать факт события и произведение, в котором о нём рассказано. Пункт 5 статьи 1259 ГК РФ исключает факты из авторско-правовой охраны; подпункт 4 пункта 6 отдельно указывает сообщения исключительно информационного характера. Вместе с тем литературные и фотографические произведения входят в число охраняемых объектов. [7]

Пункты 1 и 2 статьи 1270 связывают использование произведения с исключительным правом правообладателя. Среди способов использования названы воспроизведение и доведение до всеобщего сведения. Поэтому доступность текста в файле сама по себе не даёт основания считать любое копирование разрешённым. Для конкретной перепубликации требуется оценить содержание, условия использования и применимые исключения; это задача юридической проверки. [7]

На 22 октября 2026 года использована редакция части четвёртой ГК РФ от 23 июля 2025 года с изменениями, действующими с 4 января 2026 года. Эта дата относится к редакции кодекса, а не к первому появлению всех перечисленных правил. [7] Принятый закон № 296-ФЗ от 4 августа 2026 года вступает в силу 1 января 2027 года; его изменения касаются статей 1261, 1350–1352 и 1358, а не изложенных здесь положений статей 1259 и 1270. [8]

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

Лента новостей и RSS — одно и то же?

Нет. Лента в этой статье — обновляемый список новостных записей. RSS — конкретный формат их передачи. Чтобы поставить точную задачу, нужно уточнить, обсуждается ли список на экране или файл для другой программы. [1, 2]

Обязательно ли самое новое должно стоять первым?

Порядок нужно описывать для конкретной ленты. В учебной подборке редактор может закрепить предупреждение выше новых сообщений. Техническое обозначение упорядоченной коллекции само по себе не задаёт такое редакционное правило. [5]

Почему исправленная новость появилась дважды?

Стоит проверить, не получила ли она новый идентификатор и как получатель обработал повторную доставку. В JSON Feed рекомендуется сохранять прежний id при обновлении записи. [3] Это проверочная гипотеза, а не готовый диагноз для любого приложения.

Совпадает ли последняя выгрузка с архивом?

Только если заявлено соответствующее содержание. Документ может представлять часть логической ленты. [4] В учебном экспорте последних двадцати записей старая новость выйдет из файла, но это ещё ничего не говорит о её странице на сайте.

Решить с помощью сервиса

Медиатрон для редакций — программное обеспечение ООО «Лайк-Радио», работающее в изданиях холдинга altai.news и barnaul-altai.ru. Оно автоматизирует сбор и мониторинг источников, рабочее место редакции и контроль публикаций — редакционные задачи, связанные с подготовкой потока материалов.

Сервисы MEDIATRONE →

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

Источники

  1. RSS Advisory Board. (2009, March 30). RSS 2.0 specification (Version 2.0.11). https://www.rssboard.org/rss-specification (дата обращения: 22.10.2026). ↑ а б в г д е
  2. Nottingham, M., & Sayre, R. (Eds.). (2005, December). The Atom syndication format (RFC 4287). RFC Editor. https://doi.org/10.17487/RFC4287. Текст: https://www.rfc-editor.org/rfc/rfc4287.html (дата обращения: 22.10.2026). ↑ а б в г д
  3. Simmons, B., & Reece, M. (n.d.). JSON Feed version 1.1. https://www.jsonfeed.org/version/1.1/ (дата обращения: 22.10.2026). ↑ а б в г д е
  4. Nottingham, M. (2007, September). Feed paging and archiving (RFC 5005). RFC Editor. https://doi.org/10.17487/RFC5005. Текст: https://www.rfc-editor.org/rfc/rfc5005.html (дата обращения: 22.10.2026). ↑ а б в г д е
  5. World Wide Web Consortium. (2017, May 23). Activity Streams 2.0 (W3C Recommendation), § 4.6. https://www.w3.org/TR/activitystreams-core/ (дата обращения: 22.10.2026). ↑ а б
  6. Яндекс. Свежее и актуальное // Справка Яндекс Вебмастера. Б. г. URL: https://yandex.ru/support/webmaster/ru/search-appearance/fresh-content (дата обращения: 22.10.2026). ↑ а б в
  7. Гражданский кодекс Российской Федерации (часть четвёртая) : от 18.12.2006 № 230-ФЗ : в ред. от 23.07.2025, с изм. и доп., вступ. в силу с 04.01.2026. Ст. 1259, п. 1, 5, 6; ст. 1270, п. 1, 2 // КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_64629/be05678dc42ddc67aae5be9ba9beebd367fb9a3f/ ; https://www.consultant.ru/document/cons_doc_LAW_64629/dffcf0b87b80ff38f430dc822a0074e76ccd41a0/ (дата обращения: 22.10.2026). ↑ а б в г
  8. О внесении изменений в часть четвертую Гражданского кодекса Российской Федерации : Федеральный закон от 04.08.2026 № 296-ФЗ. Ст. 1–2 // Гарант. URL: https://www.garant.ru/products/ipo/prime/doc/414600605/ (дата обращения: 22.10.2026; вступает в силу 01.01.2027). ↑

Служебный блок

Версия
2.0
Факты проверены
Подготовка
Редакция Медиатрона
Публикация
утверждена владельцем издания 4 ноября 2026 г.

Редакция Медиатрона. Факты сверены с первоисточниками на дату проверки, публикация утверждена владельцем издания.

Нашли ошибку? info@mediatrone.ru