Почему PDF — один из самых сложных форматов для извлечения данных

Николай Ланец
Николай Ланец
Apr 17, 2026

PDF воспринимается как “документ”. Но с точки зрения разработчика это вводит в заблуждение. PDF — не документ в привычном смысле, а формат описания рендеринга страницы. Именно это и делает его настолько сложным для парсинга.

1. Что такое PDF на самом деле

PDF (Portable Document Format) — это по сути программа для отрисовки страницы:

  • “нарисуй текст в координате (x, y)”
  • “используй этот шрифт”
  • “вставь изображение в этот прямоугольник”

В нём нет понятий:

  • абзаца
  • заголовка
  • таблицы
  • списка

Есть только графические примитивы.

Отсюда ключевое следствие:

Любое извлечение данных из PDF — это реконструкция, а не чтение.

2. Почему нельзя просто “вытащить текст”

Типичная ошибка — ожидать, что текст в PDF хранится как поток. На практике:

  • слова могут быть разбиты на символы
  • порядок символов может не совпадать с порядком чтения
  • многоколоночный текст часто “перемешан”

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

Библиотеки уровня pdfminer.six или PyMuPDF дают доступ к координатам, но не дают смысла.

3. Абсолютное позиционирование ломает всё

В PDF каждый элемент имеет bounding box:

  • текст: координаты каждого блока (иногда каждого символа)
  • изображения: прямоугольники
  • линии и фигуры: отдельные примитивы

Чтобы восстановить документ, нужно:

  1. собрать символы в слова
  2. слова в строки
  3. строки в абзацы
  4. абзацы в логическую структуру

На каждом шаге — догадки.

4. Таблицы: структур нет вообще

Таблица в PDF — это:

  • текст, выровненный по сетке
  • иногда линии (но не всегда)

Нет:

  • строк
  • колонок
  • ячеек

Поэтому даже специализированные инструменты вроде Camelot или Tabula работают через геометрию:

  • поиск выравнивания по X
  • анализ расстояний
  • попытки угадать сетку

Ошибки неизбежны:

  • merged cells
  • переносы внутри ячеек
  • сложные таблицы

5. Шрифты и кодировки

Отдельная категория проблем — текст может быть:

  • закодирован нестандартно
  • представлен через глифы
  • частично встроен

Результат:

  • “кракозябры” вместо текста
  • невозможность редактирования
  • потеря Unicode

Это не баг инструмента — это особенность PDF.

6. OCR: когда текста нет вообще

Многие PDF — это сканы:

  • внутри только изображения
  • текст отсутствует

Тогда используется OCR:

  • Tesseract
  • Google Vision OCR

Проблемы:

  • ошибки распознавания
  • потеря структуры
  • формулы почти не восстанавливаются

OCR — это уже другая задача: компьютерное зрение.

7. Многоколоночные документы

Классический кейс — научные статьи:

  • 2–3 колонки
  • вставки
  • сноски

При извлечении:

  • текст может идти “змейкой”
  • или сначала вся левая колонка, потом правая

Чтобы исправить, нужно:

  • кластеризовать блоки по X
  • восстанавливать порядок чтения

Это уже задача spatial analysis.

8. Формулы и сложная верстка

Математика в PDF может быть:

  • текстом
  • набором отдельных символов
  • векторной графикой
  • изображением

Результат:

  • обычный парсер её ломает
  • OCR даёт шум
  • восстановление LaTeX — отдельная задача

9. Почему Markdown — плохой промежуточный формат

Частая ошибка — сразу конвертировать PDF в Markdown.

Проблема:

  • Markdown не хранит координаты
  • не умеет сложные layout’ы
  • плохо описывает таблицы

В итоге теряется информация, которую уже невозможно восстановить.

Более корректный подход:

PDF → layout (координаты) → структура → Markdown/HTML

10. ML-подходы: не серебряная пуля

Инструменты вроде marker-pdf используют модели для “понимания” структуры.

Плюсы:

  • лучше определяют таблицы
  • восстанавливают заголовки
  • работают с формулами

Минусы:

  • медленно
  • дорого
  • нестабильно
  • ошибки OCR

В реальности ML используют как fallback, а не как основной слой.

11. Почему нет “идеального парсера PDF”

Потому что в PDF:

  • нет семантики
  • нет структуры
  • нет потока текста

Есть только геометрия.

Поэтому любая система:

  • либо использует эвристики
  • либо ML
  • либо комбинацию

И всегда ошибается.

12. Практическая архитектура

Рабочий подход обычно выглядит так:

  1. Низкий уровень извлечение блоков (например через PyMuPDF)
  2. Layout слой
    • группировка блоков
    • определение колонок
    • нормализация текста
  3. Семантический слой
    • заголовки
    • таблицы
    • списки
  4. Fallback через ML только для сложных страниц
  5. Экспорт
    • JSON (для систем)
    • Markdown / HTML (для людей)

13. Почему PDF до сих пор жив

Несмотря на все проблемы:

  • фиксированный layout
  • одинаковое отображение везде
  • юридическая значимость
  • оффлайн

PDF решает одну задачу идеально:

гарантировать, что документ выглядит одинаково у всех

Именно поэтому он не исчезает, несмотря на HTML, Markdown и другие форматы.

Итог

PDF — это не формат данных. Это формат представления.

Поэтому:

  • извлечение = реконструкция
  • структура = догадка
  • точность = компромисс

Если воспринимать PDF как “рисунок страницы”, а не как “документ”, все сложности становятся логичными.

И именно с этого момента начинают работать адекватные архитектуры парсинга.