Конвейер распознавания штрихкодов из картинок в PDF-файле: 1С + PowerShell + ZXing

13.07.26

Интеграция - Распознавание документов и образов

Как распознать штрихкоды на одиночных и многостраничных PDF, когда некоторые из штрихкодов выглядят размыто? Пошаговый разбор создания конвейера обработки изображений на базе 1С, PowerShell, библиотеки ZXing и MuPDF. Внутри — готовый скрипт с алгоритмом попиксельной бинаризации и замерами производительности.

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
Конвейер распознавания штрихкодов из картинок в PDF-файле: 1С + PowerShell + ZXing
.zip 31,45Mb
0 2 500 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

Постановка задачи

На одной из планёрок перед нами встала задача: разработать инструмент в 1С, который мог бы получать на входе многостраничный PDF-файл, разбивать его постранично на отдельные изображения, а затем распознавать штрихкод с каждой страницы. По считанному коду система должна автоматически найти документ в базе 1С и прикрепить к нему соответствующий скан-лист.

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

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

 

Решение "в лоб"

Для начала я посмотрел доступные внешние компоненты DLL и типовые механизмы. Первой мыслью было подсмотреть логику в «1С:Документооборот», но мы быстро упёрлись в ограничения платформы. В типовом решении (на тот момент) была работа преимущественно с кодами формата EAN-13, в то время как наши документы маркировались штрихкодами логистического формата EAN-128 (GS1-128). Дальше по списку были уже коммерческие решения, в нашем случае не вариант. 

Попробовали "ветерана" ZBar. Выяснилось, что ZBar хорошо читал чистые векторные PDF, где штрихкод был зашит текстовыми шрифтами. Но в нашем случае на вход поступали сканы актов за целый день работы — то есть тяжёлые, неконтрастные картинки, просто упакованные в PDF. Я честно пытался завести связку ZBar + ImageMagick, чтобы предварительно подготавливать эти сканы, но добиться от неё хоть какого-нибудь результат мне так и не удалось.

Я протестировал ещё несколько утилит, но детально останавливаться на них нет смысла — результат везде крутился около нуля. Методом последовательного перебора я дошёл до библиотеки ZXing

 

 

И вот тут появилась надежда... 

PowerShell и общая архитектура решения

Почему PowerShell?

Когда библиотека ZXing была выбрана, возник закономерный вопрос: как красиво подружить её с 1С? Платформа «1С:Предприятие» не умеет напрямую (без создания сложных COM-обёрток) загружать управляемый .NET-код. Поскольку PowerShell является родной частью экосистемы Windows и базируется на той же CLR (Common Language Runtime), для него загрузка сторонней DLL — это базовая операция Add-Type. Часть корабля, часть команды — всё работает бесшовно. 

При таком подходе мы получаем:

  • Доступ к классам .NET по которым в сети есть достаточно документации и готовых примеров
  • Windows PowerShell ISE 5.1  встроенная среда разработки, чем-то напоминает конфигуратор

В итоге PowerShell выступил в роли (условно) бесплатного моста между 1С и .NET. Сама 1С в этой схеме просто формирует параметры и вызывает скрипт через стандартную команду ЗапуститьПриложение(), а PowerShell берёт на себя всю работу с графикой и консольной утилитой MuPDF (на неё я, кстати, наткнулся на StackOverflow).

 

Рисунок 1 — Принципиальная схема обработки PDF-файла.

 

Алгоритм работы системы по этапам

1. Инициация процесса: Оператор в 1С открывает обработку и указывает путь к PDF-файлу 

2. Работа PowerShell: Платформа запускает PowerShell-скрипт, передавая ему параметры. Скрипт последовательно выполняет следующую цепочку действий:

  • Вызывает утилиту mutool.exe которая разбивает исходный PDF на отдельные PNG-картинки.

  • Пробегается по каждому полученному PNG-файлу, находит штрихкод и распознает его с помощью библиотеки ZXing.

  • Складывает итоговые результаты распознавания (имя файла и считанный код) в CSV-файл, а картинки во временные файлы.

 

Рисунок 2 — Вид CSV-файла

 

3. Разбор результата 1С: после завершения работы скрипта 1С считывает созданный CSV-файл. Пробегаясь по строкам, система находит в базе нужные документы по распознанным штрихкодам и автоматически привязывает к ним файлы страниц по путям, указанным в этом же файле.

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

ZXing не распознаёт

Это, конечно, крутая библиотека, которую можно просто скачать бесплатно, но первые тесты показали, что ШК не всегда надлежащего качества и для распознавания ШК изображение нужно готовить. 
Тут собственно и пригодятся встроенные .NET классы для работы с изображениями. 

При дальнейшем изучении ZXing.net, стало понятно, что её встроенные полезные фичи (адаптивная блочная бинаризация, многоуровневое сканирование строк и т.д.) труднодоступны. Чтобы их активировать, нужно настраивать параметры декодирования через дженерик-словари. Что-то типа этого... 

$hints = New-Object 'System.Collections.Generic.Dictionary[ZXing.DecodeHintType,System.Object]'

Скажу честно: я сходу не осилил. Разбираться в документации библиотеки и выяснять, как правильно конструировать эти .NET-конструкции внутри PowerShell, мне не хотелось да и задача подгорала. Решил оставить это всё на потом. 

Поэтому я решил пойти по пути, который мне был понятен: использовать ZXing как есть. А всю работу по подготовке, очистке и масштабированию изображения реализовать на уровне скрипта с помощью стандартных .NET-классов для работы с графикой. В итоге результат выглядит так, что я не ошибся. 

 

Методы улучшения изображения 

Этап 1

Применяем два простых решения:

  • Ограничение области поиска (Crop): как видно на примере ниже, штрихкод на наших документах всегда расположен в определенном месте — в правом верхнем углу листа. С помощью встроенных средств .NET мы отрезаем (кропаем) лишние ~80% изображения, оставляя для анализа только целевой прямоугольник. 


Рисунок 3 — Вид ШК на сканированном листе.

 

  • Явное указание типа ШК: По умолчанию ZXing пытается применить к картинке все известные ему форматы (QR, DataMatrix, EAN13, Code39 и т.д.). Мы сразу указали, что ищем EAN-128

Ограничение области поиска и явное указание типа штрихкода дали ощутимый прирост в распознавании ШК но не достаточный для прода.

Первое же промежуточное тестирование на реальных пачках документов (от 20 листов и более) показало статистику: процент успешных распознаваний плавал в районе 55-65%

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

 

Рисунок 4 — Вид обрезанного сканированного листа. 

 

 
 Что нужно, чтобы ZXing прочитал EAN-128 (теория)


Этап 2

При низком разрешении сканирования штрихам не хватает пикселей. И мы внедрили второй шаг — принудительное масштабирование. Мы просто растягиваем поля картинки в 2.5 раза (это число было определено экспериментально). При чём, GoogleAI подкинул идею использовать HighQualityBicubic который встроен в .NET На тот момент это казалось хорошим решением: при «умном» растягивании по идее часть мелких артефактов и рваных краев со штрихкода должна уйти (хотя, как выяснилось позже, решение оказалось весьма спорным)


Рисунок 5 — Сравнение размеров изображений (сверху увеличенное)

 

 
Краткое описание High Quality Bicubic (теория)

 

Этап 3 + тесты

Как показала практика, для большинства документов первых двух шагов хватает за глаза. Но периодически в пачке попадается по-настоящему «сложный пациент» (грязный скан, блёклый картридж или следы дырокола), на котором происходит затык. На этот случай у нас припасён третий этап конвейера — бинаризация изображения.

 

Рисунок 6 — Пример с нераспознанным ШК (без бинаризации)

 

На текущий момент наш конвейер обработки выглядит следующим образом (в процессе эксплуатации мы его ещё доработаем и улучшим, но на старте схема была такой):

Этап 1 (Кроп): Ограничиваем область поиска (ROI), пытаемся прочитать штрихкод «в лоб». Если успешно — отдаем результат. Если код не определён — передаем картинку на следующий этап.

Этап 2 (Увеличение): Растягиваем вырезанную область в 2.5 раза с помощью режима интерполяции HighQualityBicubic. Пытаемся распознать. Если мимо — идём дальше.

Этап 3 (Бинаризация): Применяем к увеличенной картинке жесткий фильтр перевода в чёрно-белый спектр и делаем финальную попытку распознавания.

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

  • Страницы 1, 4, 5, 6, 7, 8 и 9 — это нормальные, качественные сканы. Они мгновенно распознались на первом же этапе ("Кроп") всего за 2 мс каждый.
  • Страницы 3 и 10 — оказались проблемными. Первый этап их пропустил, но на втором этапе ("Увеличение") алгоритм их успешно разобрал. Времени на них ушло ощутимо больше — 144 мс и 147 мс соответственно, но для пользователя это всё равно доли секунды.
  • Страница 2 — выдала "NOT_FOUND". И тут самое время попробовать бинаризацию
 
 Бинаризация (теория)

 

Рисунок 7 — сложный для распознавания ШК до бинаризации

 

Рисунок 8 — Результат распознавания ШК с бинаризацией

 

Рисунок 9 — Наглядное сравнение ШК после/до бинаризации

 

На рисунке 7 хорошо виден тот самый "сложный пациент" до обработки: штрихкод блёклый, границы размыты, алгоритм растягивания (апскейл) превратил края в серую кашу, и движок ZXing его не читает.

Чтобы заставить систему увидеть эти полосы, в коде была выделена переменная порога яркости "threshold" (в скрипте она задаётся вручную). Экспериментальным путём для наших документов был выбран порог 190-200.

Посмотрите на рисунок 9 — верхняя половина показывает результат работы бинаризации с правильным порогом. Вся серая грязь и промежуточные полутона исчезли. Остались только идеально контрастные, рубленые чёрные линии на чистом белом фоне. Такую картинку виртуальная линия сканирования ZXing распознаёт.

 

Промежуточные выводы

Посмотрим на обновлённые логи консоли на рисунке 8:

Страница 2, которая раньше выдавала "NOT_FOUND", теперь успешно распознана. Но  время обработки: 4672 мс, можно сказать 5 сек на штрихкод (это без учёта работы прошлых методов).

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

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

 

Внезапный инсайт

И можно было бы закончить на этом, но в процессе написания этого материала у меня появилась мысль, которая заставила меня по-новому взглянуть на реализованный подход: а что если запустить бинаризацию не на увеличенной картинке, а сразу на том изображении, которое после кропа?

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

Вспомним параметры разрешений наших картинок из предыдущего шага:

Исходный фрагмент: 1487 * 631 = 0.93 млн пикселей.

Увеличенный фрагмент: 3818 *1638 = 6.25 млн пикселей.

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

В первом случае нашему PowerShell-скрипту нужно перелопатить меньше миллиона пикселей, а во втором — более 6 млн. Разница в объёме данных ~6.6 раз Поэтому бинаризация на раздутом изображении заняла 4.6 секунды. Если обрабатывать "маленький" оригинал, мы должны получить прирост к скорости.

 

Рисунок 10 -- Результат изменения конвейера обработки изображения.

 

Гипотеза подтвердилась: время обработки проблемной страницы 2 упало с  4672 мс до 833 мс. Только за счет оптимизации логики. Но, я ожидал результата лучше. Да, и забыл упомянуть, что от бикубика (HighQualityBicubic) тоже можно отказаться, без него работает не хуже. Просто растянуть методом по умолчанию.

Финальный аккорд: Помощь AI и C#

Захотелось ещё улучшить производительность, но я не знал как. Поэтому пошел за помощью к AI. AI тут же выдал код на C# внутри PowerShell, с чем я не разобрался ранее самостоятельно. 

Результаты работы этого тандема смотрите сами на рисунке ниже:

 

Рисунок 11 — Результат доработки алгоритма бинаризации AI.

 

Результаты получились хорошими и не в пользу человека:

  • Страница 2 (сложный пациент) Время обработки сократилось с исходных 4672 мс и промежуточных 833 мс до 50 мс! Ускорение относительно первоначального варианта — почти в 100 раз... (!!!)
  • Страницы 3 и 10 Которые раньше на чистом увеличении требовали по 145 мс, теперь пролетели через связку "Кроп + C#-бинаризация" всего за 54 мс и 49 мс

При этом все штрихкоды распознались. В итоге на выходе получился достойный инструмент: лёгкие страницы мгновенно распознаются за 2-3 мс на первом этапе, а на сложных страницах включается бинаризация на C#, написанная AI, которая быстро проворачивает сложные случаи всего за 50 мс. И эта пачка документов распознается за секунду.

 
 Отладочный скрипит PowerShell с выводом в консоль


Ниже проверенный временем скрипт, который пашет уже ~4 месяца.
Жаль, что я так и не нашел фото заваленного стола бумагами, чтобы показать, какие кучи бумаги удалось разгрести с помощью этой разработки.

Важное примечание: Описанный выше вариант с быстрой бинаризацией на C# от AI прямо сейчас находится на стадии тестирования. Как только он докажет свою пригодность, мы накатим этот апгрейд. Но, если вам нужно внедрить решение "здесь и сейчас" можете брать этот проверенный вариант. В отладочном скрипте есть все алгоритмы, если что их можно просто скопировать в скрипт для обработки ниже. 

 
 Скрипт, который вызывается из обработки 1С

 

 
 Код обработки 1С

 

Вместо заключения

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

 

Правильный путь

Если развивать эту систему по всем канонам ИТ-архитектуры, то двигаться нужно в сторону интеграции DLL и 1С.

В идеале нужно полностью избавиться от лишних промежуточных звеньев:

  • Исключить вызовы командной строки PowerShell.

  • Уйти от рендеринга временных картинок на диск через MuPDF.

  • Написать полноценную внешнюю компоненту (Native API) для 1С или подключить .NET DLL напрямую, чтобы весь конвейер (чтение PDF, улучшение изображения, распознавание ZXing) крутился исключительно в оперативной памяти самого сервера «1С:Предприятие».Но у этого «костыля» есть один жирный плюс: он работает. И работает исправно.


Рисунок 12 — Бывает и такое.

 

Рисунок 13 — Вид обработки из 1С.

 

Системные требования и окружение:

  • ОС: Решение стабильно работает на Windows Server (2016, 2019, 2022) и обычных десктопных Windows 10/11.
  • PowerShell:стандартной версии Windows PowerShell 5.1, которая встроена в систему "из коробки" (ничего дополнительно скачивать и обновлять не нужно)
  • Регистрации DLL: Не требуется. 
  • Использовалась платформа 1С: 8.3.25.1546

Вступайте в нашу телеграмм-группу Инфостарт

Интеграция PowerShell скрипт штрихкод распознавание

См. также

Учет документов Распознавание документов и образов Бухгалтер Пользователь 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Одна из наиболее удобных обработок автоматического прикрепления большого количества документов-оригиналов к документам 1С. Для файлов поточного сканирования автоматически определяются начало и конец каждого документа. Поддерживаются штрихкоды, QR-коды, отсканированные PDF документы без штрихкодов, сформированные в ЭДО текстовые PDF документы. Поддерживаются входящие и исходящие документы-оригиналы.

87108 руб.

23.12.2021    16845    33    25    

14

SALE! 35%

Учет документов Распознавание документов и образов Системный администратор Программист Руководитель проекта 1С:Документооборот Платные (руб)

Обработка многостраничных файлов PDF с разбиением на отдельные документы по штрих-коду и сохранение документов в отдельные файлы для. Не требуется интернет, внешние утилиты командной строки и т.д. Плюсы: скорость работы, независимость от внешних библиотек или утилит, достаточно большой перечень поддерживаемых типов ШК, возможность фильтрации по формату и данным ШК. Не требует установки (portable), может работать несколько экземпляров ПО на одном хосте с разными настройками.

12200 руб.

07.07.2026    170    0    0    

0

Распознавание документов и образов Программист Россия Бесплатно (free)

История о том, как запустить локальное распознавание аудио на Whisper и не сойти с ума, разрываясь между клиентами, техзаданиями и внезапным потопом в квартире. Практический MVP для расшифровки чувствительных записей без облака: от обхода проблем с CUDA под Windows до превращения хаотичного разговора о маркировке в четкую основу для задачи в 1С.

22.06.2026    408    otcheskiy    8    

5

Интеграция Нейросети DevOps и автоматизация разработки Распознавание документов и образов 1C:ERP 1С:КА 1С:УНФ Химическая промышленность Горнодобывающая промышленность Металлургическая промышленность Россия Платные (руб)

От чертежа до себестоимости — за минуты, а не дни. ИИ-Технолог автоматически распознаёт чертежи и техническую документацию (включая фото, сканы, PDF, Excel), рассчитывает нормы времени, формирует технологические маршруты, оценивает возможность изготовления и точную себестоимость. Интеграция с 1С (ERP, MES, КА, УНФ) и отраслевыми нормативами (ГОСТы).

366000 руб.

18.06.2026    713    0    2    

0

Распознавание документов и образов WEB-интеграция Программист 1С 8.3 1С:ERP Управление предприятием 2 Россия Абонемент ($m)

Представлен модуль интеграции с сервисом SberScan.

1 стартмани

16.06.2026    292    0    tori131313    0    

1

Распознавание документов и образов Обмен с ГосИС Программист 1С 8.3 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1C:ERP Бесплатно (free)

HTTP-сервис на python для распознавания DataMatrix штрихкодов "Честный Знак" из изображений. Принимает изображение в формате base64, выполняет распознавание и возвращает результат в JSON.

09.06.2026    978    rozer    2    

9

Сканер штрих-кода Терминал сбора данных WEB-интеграция Распознавание документов и образов Программист 1С 8.3 1С:Библиотека стандартных подсистем Бесплатно (free)

Коротко о новых возможностях 1Scan: WebSocket-обмен с Android-устройством, передача штрихкодов, фото, файлов и координат в 1С, а также OCR-распознавание текста камерой.

03.06.2026    556    OneScan    3    

4
Для отправки сообщения требуется регистрация/авторизация