Продукт12 мая 2026 г.8 мин чтения

Как мы парсим расписание любого вуза за 1–2 недели без выгрузок

Когда мы говорим, что подключим бота к существующему сайту расписания, в учебной части обычно не верят. Объясняем технически — почему это правда.

CampusHub · Журнал
Поделиться
Как мы парсим расписание любого вуза за 1–2 недели без выгрузок

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

Зачем вообще парсинг, а не интеграция

Стандартный подход к работе с расписанием выглядит так: «Давайте мы получим доступ к вашей системе планирования, выгрузим оттуда XML/JSON, импортируем к себе, синхронизируем при изменениях». Звучит правильно — но в реальности упирается в три проблемы.

Проблема 1: систем расписания у вузов десятки. Кто‑то на 1С:Колледж, кто‑то на самописной системе, кто‑то на Excel, кто‑то на бесплатных продуктах региональных министерств. Делать интеграцию под каждую — это месяцы работы перед запуском.

Проблема 2: получить доступ к системе непросто. Это IT‑отдел, согласования, договор о работе с базой, инструктаж, тестовые контуры. Реальные сроки на одно учреждение — от 2 до 6 месяцев.

Проблема 3: даже после интеграции вы дублируете данные. Учебная часть продолжает работать с исходной системой, у вас лежит копия, которая может «отставать». Конфликт версий обеспечен.

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

Что мы реально делаем технически

Шаг 1: понимание структуры

Мы открываем ваш сайт расписания и смотрим, как он устроен. Это ручная работа — на типичное учреждение уходит 2–4 часа аналитика. Цель — понять:

Если сайт нестандартный или с защитой от парсинга — обсуждаем с IT‑отделом учреждения, как корректно получать данные (whitelist нашего IP, выделенный read‑only эндпоинт и т. д.).

Шаг 2: написание адаптера

Под каждый тип сайта мы пишем небольшой адаптер — TypeScript‑модуль на 200–500 строк. Он отвечает за извлечение структурированных данных. Логика обычно простая:

  1. Достать HTML/JSON со страницы расписания.
  2. Раскрыть его по правилам конкретного сайта (Cheerio для HTML, стандартные парсеры для JSON, специальные библиотеки для PDF).
  3. Привести к единому формату — список занятий с полями: группа, день, время, предмет, тип (лекция/семинар), преподаватель, аудитория.
  4. Отловить аномалии: пропущенные поля, неизвестные сокращения, несовпадение типов.

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

Шаг 3: автоматическая синхронизация

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

Если кто‑то в учебной части в 23:50 утвердил замену и обновил сайт — через час максимум это окажется в боте. Если нужно быстрее — есть webhook‑вариант, при котором ваша система оповещает нас явно после обновления.

Шаг 4: мониторинг и алерты

Структура сайта может измениться. Учебная часть переименовала раздел, IT‑отдел поменял шаблоны страниц, кто‑то добавил CAPTCHA. Чтобы не оказаться в ситуации «бот молча отвечает старыми данными», мы мониторим работу адаптеров и алертим себя при ошибках:

В каждом случае мы оперативно дорабатываем адаптер. В типичном учреждении — 1–3 правки в год, обычно после серьёзных изменений на сайте или в начале учебного года.

8 типов сайтов, которые мы видели

За полгода работы мы прошли через несколько архетипов сайтов расписания:

  1. HTML‑таблица, отрендеренная сервером. Самый простой случай: парсер на Cheerio, чистый CSS‑селектор → DOM → структура.
  2. JavaScript SPA, рендерится на клиенте. Нужен headless‑браузер (Playwright). Дольше, но решаемо.
  3. API endpoint, который отдаёт JSON. Идеально — парсер тривиальный. Только нужно понять, как его правильно вызывать.
  4. PDF, обновляемый раз в неделю. Парсим через pdf‑lib + распознавание таблиц. Сложно, но реально.
  5. Excel‑файл на FTP. Открываем через библиотеки, извлекаем по координатам ячеек.
  6. iframe со сторонним сервисом. Идём в сторонний сервис напрямую, иногда там есть открытый API.
  7. Раздел «Студенту» с несколькими URL на курс. Просто больше работы по составлению маппингов. Парсер тот же.
  8. Полностью кастомное. Бывает. Тогда — обсуждение с IT‑отделом и решение под конкретный кейс.

А что если сайт изменится

Самый частый страх: «Вы подключитесь, а наш IT‑отдел через полгода переделает сайт расписания». Реальность:

Что в итоге

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

Если у вашего вуза или колледжа сайт расписания «странный» — это не блокер. У нас уже есть опыт с PDF, SPA, FTP, iframe и кастомными системами. Любая страница, которую можно открыть в браузере, — это страница, которую может прочитать наш парсер.

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

#парсинг расписания вуза#парсинг расписания#парсер расписания#парсинг сайта вуза#парсинг PDF расписания#интеграция расписания#без миграции#расписание#вуз#колледж#интеграция#техническое#КампусХаб#CampusHub