Парсер: что это такое и как работает

Парсер — это программа или сервис, который берет данные из одного места, разбирает их по правилам и превращает в удобный вид: таблицу, файл, базу данных, отчет или уведомление. В случае HTML, API или файла важно думать не только о технической стороне, но и о правилах доступа к данным

Самая простая схема выглядит так:

источник -> получение данных -> разбор -> очистка -> сохранение -> проверка

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

Когда парсер действительно нужен

Парсер полезен, когда однотипные данные нужно получать регулярно. Если нужно один раз скопировать пять строк, проще сделать это руками. Если нужно каждый день проверять десятки страниц, сравнивать цены, обновлять каталог или собирать открытые публикации, автоматизация уже имеет смысл

Типичные задачи:

• разобрать страницу
• получить данные из API
• прочитать CSV
• собрать отчет

Перед созданием парсера сформулируйте результат. Не «собрать все», а «получить таблицу с названием, ссылкой, датой и статусом». Чем точнее результат, тем легче выбрать безопасный способ получения данных

По этой теме полезно отдельно посмотреть Составьте еженедельное расписание занятий, чтобы расширить контекст и сравнить подходы

По этой теме полезно отдельно посмотреть Аннотации типов для декораторов в Python, чтобы расширить контекст и сравнить подходы

Безопасный подход

Для HTML, API или файла сначала ищите официальные и разрешенные варианты:

• API
• файловая выгрузка
• открытые данные
• тестовая выборка

Это не формальность. Официальный API или экспорт обычно стабильнее, понятнее и безопаснее, чем попытка разбирать HTML-страницы. Если сервис дает API, лучше начать с него. Если есть выгрузка CSV или Excel, иногда она полностью закрывает задачу без сложной разработки

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

Какие данные можно собирать

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

Особенно осторожно относитесь к:

• персональным данным;
• телефонам и email;
• закрытым профилям;
• отзывам с именами людей;
• данным из личных кабинетов;
• контенту, защищенному авторским правом;
• данным, полученным после авторизации

Если задача связана с клиентскими данными, лучше получить явное разрешение и использовать официальный экспорт. Если задача коммерческая, стоит заранее уточнить правила источника

Из чего состоит парсер

Даже простой парсер состоит из нескольких частей:

1. Получение данных
2. Проверка ответа
3. Разбор структуры
4. Очистка значений
5. Сохранение результата
6. Обработка ошибок
7. Логи и повторный запуск

Новички часто пишут только третий пункт: «найти нужный элемент». Но без проверки ответа и обработки ошибок парсер ломается при первом изменении страницы, сетевой ошибке или пустом результате

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

Пример структуры результата

Перед кодом полезно представить таблицу:

Название | Ссылка | Дата | Категория | Статус проверки

Для HTML, API или файла набор полей зависит от задачи. Для каталога это может быть название, цена, наличие и ссылка. Для публикаций — заголовок, автор, дата, адрес. Для видео — название, дата, канал, длительность. Для справочника — организация, категория, сайт и город, если это разрешено правилами источника

Не собирайте лишние поля «на всякий случай». Лишние данные усложняют хранение, проверку и ответственность. Лучше начать с минимального набора, который нужен для решения задачи

Как проверять качество данных

Парсер может технически работать, но собирать мусор. Поэтому нужна проверка:

• сколько строк найдено;
• нет ли пустых обязательных полей;
• не появились ли дубли;
• корректны ли ссылки;
• не изменился ли формат даты;
• нет ли странных значений;
• совпадает ли выборочная проверка с источником

После первого запуска откройте 10-20 строк вручную и сравните с источником. Если ошибка повторяется, исправляйте правило разбора. Если ошибки разные, возможно, источник неоднородный и нужны дополнительные условия

Частые риски

Для HTML, API или файла особенно важно учитывать:

• сетевые ошибки
• кодировки
• изменение формата
• пустые ответы

Риск не всегда означает «нельзя». Он означает, что нужно заранее выбрать аккуратный способ. Например, если источник часто меняет разметку, лучше использовать API или экспорт. Если есть лимиты, нужно соблюдать частоту запросов. Если данные чувствительные, лучше отказаться от сбора или согласовать доступ

Ошибки новичков

Первая ошибка — сразу писать код без понимания результата. В итоге парсер что-то собирает, но таблица не отвечает на задачу

Вторая ошибка — не проверять правила источника. Техническая возможность не равна разрешению

Третья ошибка — делать слишком частые запросы. Это может нагружать сервис и привести к блокировке

Четвертая ошибка — не сохранять логи. Когда парсер перестает работать, непонятно, где проблема: сеть, источник, разбор или запись файла

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

Как сделать первую версию

План первой версии:

1. Определить источник и проверить правила доступа
2. Сформулировать поля результата
3. Найти официальный API, экспорт или разрешенный способ получения
4. Собрать 5-10 тестовых записей
5. Очистить значения и привести их к единому виду
6. Сохранить результат в CSV или таблицу
7. Сравнить несколько строк с источником вручную
8. Добавить обработку пустого результата и ошибок
9. Записать ограничения первой версии

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

Поддержка и обновления

Парсер — это не одноразовая магия. Источник может поменяться, поля могут исчезнуть, доступ может стать ограниченным, формат ответа может обновиться. Поэтому важно хранить не только код, но и описание: откуда берутся данные, какие поля ожидаются, какие ограничения учтены, как проверить результат

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

Чек-лист

• Есть понятная цель сбора
• Проверены правила источника
• Используется разрешенный способ доступа
• Поля результата заранее описаны
• Лишние персональные данные не собираются
• Есть проверка пустого результата
• Есть лог ошибок
• Есть ручная выборочная проверка
• Частота запросов не создает нагрузку
• Результат можно объяснить и повторить

Мини-парсер, который можно собрать за 15 минут

Чтобы парсер перестал быть абстракцией, разберите маленький каталог. Такой пример показывает не только поиск элементов, но и проверку пустых полей

Подготовка занимает пару минут. Удобнее работать в отдельной папке, чтобы не смешивать учебный файл с другими проектами

python3 -m venv .venv
source .venv/bin/activate
pip install beautifulsoup4

Если вы работаете на Windows, команда активации будет другой:

.venv\Scripts\activate

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

Создайте файл catalog.html рядом со скриптом. Внутри будет маленький фрагмент разметки, похожий на карточки сайта, файла или API. Это не копия конкретного сайта, а безопасный учебный макет

<div class="item">
  <a class="title" href="/item/coffee">Кофе арабика 1 кг</a>
  <span class="price">790 ₽</span>
  <span class="status">в наличии</span>
</div>
<div class="item">
  <a class="title" href="/item/tea">Чай сенча 200 г</a>
  <span class="price">420 ₽</span>
  <span class="status">под заказ</span>
</div>
<div class="item">
  <a class="title" href="/item/cocoa">Какао 500 г</a>
  <span class="price"></span>
  <span class="status">нет цены</span>
</div>

Теперь создайте файл parser.py:

import csv
from pathlib import Path
from bs4 import BeautifulSoup

HTML_FILE = Path("catalog.html")
CSV_FILE = Path("parsed_items.csv")

def clean_text(value: str | None) -> str:
    return " ".join((value or "").split())

def parse_items(html: str) -> list[dict[str, str]]:
    soup = BeautifulSoup(html, "html.parser")
    rows = []

    for card in soup.select(".item"):
        title = card.select_one(".title")
        price = card.select_one(".price")
        status = card.select_one(".status")

        rows.append({
            "title": clean_text(title.get_text() if title else ""),
            "link": title.get("href", "") if title else "",
            "price": clean_text(price.get_text() if price else ""),
            "status": clean_text(status.get_text() if status else ""),
        })

    return rows

def save_csv(rows: list[dict[str, str]]) -> None:
    with CSV_FILE.open("w", newline="", encoding="utf-8") as file:
        writer = csv.DictWriter(file, fieldnames=["title", "link", "price", "status"])
        writer.writeheader()
        writer.writerows(rows)

html = HTML_FILE.read_text(encoding="utf-8")
rows = parse_items(html)

if not rows:
    raise SystemExit("Не найдено ни одной карточки")

empty_prices = [row for row in rows if not row["price"]]
if empty_prices:
    print(f"Внимание: без цены найдено {len(empty_prices)} строки")

save_csv(rows)
print(f"Сохранено строк: {len(rows)}")
print(f"Файл результата: {CSV_FILE.resolve()}")

Запуск:

python parser.py

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

Как адаптировать пример под свою задачу

Главная польза этого примера не в BeautifulSoup как таковом, а в порядке действий. Сначала есть понятный источник, затем разбор, затем очистка текста, затем сохранение. Если завтра вместо тестового HTML появится разрешенная страница сайта, файла или API, общий ход останется таким же, но добавятся проверка ответа, пауза между запросами и чтение правил источника

Обратите внимание на функцию clean_text. У начинающих часто получается таблица с переносами строк, лишними пробелами и неочевидными пустыми значениями. Небольшая очистка сразу делает результат пригодным для просмотра и загрузки в таблицу

Еще один важный момент — проверка if not rows. Без нее скрипт может создать пустой CSV, а вы решите, что данных действительно нет. На практике пустой результат часто означает, что поменялась разметка, файл открыт не тот или селектор выбран неверно

Сначала меняйте только тестовый HTML. Добавьте еще одну карточку, уберите цену, поменяйте класс title на name и посмотрите, где скрипт перестанет находить данные. Так вы быстро поймете, что именно зависит от разметки

Когда структура понятна, выпишите поля результата:

• title — название;
• link — ссылка или идентификатор;
• price — цена, если она нужна;
• status — наличие, дата, категория или другой полезный признак

Не добавляйте поля «на всякий случай». Лишние данные делают таблицу тяжелее и создают больше ответственности. Лучше собрать четыре точных поля, чем десять случайных

Как сделать версию полезнее

После первого запуска добавьте улучшения по одному:

1. Проверку дублей по ссылке или названию
2. Отдельный список строк без цены
3. Сообщение, если найдено меньше карточек, чем ожидалось
4. Дату запуска в отдельной колонке
5. Сохранение сырого HTML для ручной проверки
6. Лог с количеством найденных и пропущенных строк

Например, простая проверка дублей выглядит так:

seen = set()
unique_rows = []

for row in rows:
    key = row["link"] or row["title"]
    if key in seen:
        continue
    seen.add(key)
    unique_rows.append(row)

print(f"После удаления дублей: {len(unique_rows)}")

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

Когда переходить к живому источнику

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

Если есть официальный API, экспорт CSV или личный кабинет с выгрузкой, начните с них. HTML-разбор оставьте для тех случаев, где это разрешено, стабильно и действительно нужно. Для коммерческой задачи лучше заранее записать, откуда берутся данные, как часто запускается сбор и кто проверяет результат

Как организовать рабочую папку

Чтобы пример по теме первого парсера не остался отдельным фрагментом, заведите маленькую рабочую папку. В ней должны быть входной файл source_sample.html, скрипт, CSV-результат и короткая заметка о запуске

parser-demo/
  parser.py
  catalog.html
  parsed_items.csv
  README.md

В README.md достаточно указать источник данных, разрешенный способ получения, ожидаемые поля и команду запуска. Для темы первого парсера это важнее длинного описания: через неделю вы быстро поймете, что именно проверяет скрипт

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

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

Для темы первого парсера успешный запуск означает не просто созданный файл. Откройте first_parser_result.csv рядом с исходником source_sample.html и вручную проверьте несколько строк: первую, последнюю и одну из середины

В каждой строке должно быть понятно, откуда взялись поля name и value. Если значение пустое, странное или повторяется, не прячьте его в общей таблице. Лучше вывести предупреждение или сохранить отдельный список строк для ручной проверки

Мини-валидатор под эту задачу

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

def validate_rows(rows, primary_field="name", secondary_field="value"):
    errors = []
    seen = set()

    for number, row in enumerate(rows, start=1):
        primary_value = str(row.get(primary_field, "")).strip()
        secondary_value = str(row.get(secondary_field, "")).strip()

        if not primary_value:
            errors.append(f"Строка {number}: пустое поле {primary_field}")

        if not secondary_value:
            errors.append(f"Строка {number}: пустое поле {secondary_field}")

        key = primary_value.lower()
        if key and key in seen:
            errors.append(f"Строка {number}: возможный дубль {primary_value}")
        seen.add(key)

    return errors

Для первого парсера эта проверка закрывает главный риск первой версии: попытка сделать универсальный инструмент раньше первой рабочей версии. Если ошибок много, не расширяйте сбор. Сначала разберитесь, почему базовые поля не держатся стабильно

Что добавить во вторую версию

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

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

Где граница безопасной работы

Главный фокус здесь — увидеть полный путь от входного файла до проверяемой таблицы. Перед переходом к живому источнику проверьте правила доступа, наличие API или выгрузки, ограничения по частоте и состав данных. Если появляются персональные данные, закрытые страницы, авторизация или техническая защита, задачу нужно пересобрать более аккуратно

Хорошая первая версия должна быть узкой: понятный источник, понятные поля, проверяемый CSV и честно записанные ограничения. Такой инструмент проще поддерживать и легче объяснить другому человеку

Критерии готовности

• входной файл source_sample.html описан рядом со скриптом
• результат сохраняется в first_parser_result.csv
• поле name не бывает пустым без предупреждения
• поле value проверяется отдельно
• дубли либо удаляются, либо помечаются
• несколько строк сверены вручную
• ограничения источника записаны обычным языком
• следующий шаг понятен и не требует переписывать все заново

Часто задаваемые вопросы

Что такое парсер простыми словами?

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

Можно ли парсить любой сайт?

Нет. Сначала нужно проверить правила источника, доступные выгрузки, API и ограничения. Техническая возможность не означает разрешение

С чего начать новичку?

Начните с сохраненной HTML-страницы или собственного тестового файла. Так можно понять механику без лишнего риска и без нагрузки на чужой сайт

Что лучше: API, CSV или HTML?

Если есть API или CSV-выгрузка, обычно лучше начать с них. Разбор HTML нужен тогда, когда это разрешено и другого стабильного способа нет

Почему парсер ломается?

Чаще всего меняется разметка, исчезает поле, источник начинает отдавать другой формат или в данных появляются пустые значения