При переходе на операционную систему Linux системные администраторы и разработчики 1С часто сталкиваются с проблемой: старый код, использующий COMОбъект("Word.Application"), перестает работать. Технология COM (Component Object Model) является проприетарной разработкой Microsoft и нативно не поддерживается в Linux. Ситуация осложняется, когда необходимо обрабатывать именно старые бинарные форматы документов .doc, с которыми LibreOffice справляется не всегда корректно, особенно если в документах присутствуют сложные колонтитулы, макросы или специфическая верстка. В этой статье мы подробно разберем несколько стратегий решения этой задачи, от простых костылей до профессиональных архитектурных подходов.
Когда мы вызываем Новый COMОбъект на сервере под управлением Linux, платформа 1С выдает ошибку, так как в системе отсутствует соответствующая подсистема и зарегистрированные библиотеки. Рассмотрим ситуацию, когда нам нужно вставить штрихкод в колонтитулы бинарного файла .doc. Простое сохранение в .docx средствами 1С или сторонних конвертеров часто портит форматирование. Разберем варианты обхода этого ограничения.
Проанализируем самый простой с точки зрения реализации подход. Мы можем использовать одну Windows-машину (виртуальную или физическую), на которой будет запущен сеанс 1С под управлением Windows. Этот сеанс будет выступать в роли "обработчика задач".
ОчередьЗадачНаОбработкуФайлов.ОбработкаОжидания, который раз в несколько секунд проверяет регистр.COMОбъект("Word.Application") (по аналогии с выполнение алгоритмов через COM-подключение), обрабатывает файл и записывает результат обратно в регистр или справочник.Важный момент: Чтобы не занимать лицензию интерактивным пользователем, можно использовать регламентное задание, если на этой Windows-машине поднять еще один сервер 1С (хотя бы в файловом варианте), который будет подключен к той же базе.
Если мы хотим построить более надежную и масштабируемую систему, нам следует вынести работу с Word в отдельный микросервис, работающий на Windows. Рассмотрим архитектуру такого решения:
На Windows-хосте разворачивается легкий HTTP-сервер (например, на Python с использованием библиотеки Flask и pywin32). Сервер 1С на Linux отправляет POST-запрос с файлом на этот сервис. Проанализируем пример кода на стороне 1С для взаимодействия с таким сервисом:
// Пример отправки файла на обработку в Windows-микросервис
Функция ОбработатьДокументНаWindows(ДвоичныеДанныеФайла)
АдресСервиса = "http://windows-proxy-host:5000/process-word";
HTTPСоединение = Новый HTTPСоединение("windows-proxy-host", 5000);
HTTPЗапрос = Новый HTTPЗапрос("/process-word");
HTTPЗапрос.УстановитьТелоИзДвоичныхДанных(ДвоичныеДанныеФайла);
Ответ = HTTPСоединение.ОтправитьДляОбъекта(HTTPЗапрос);
Если Ответ.КодСостояния = 200 Тогда
Возврат Ответ.ПолучитьТелоИзДвоичныхДанных();
КонецЕсли;
Возврат Неопределено;
КонецФункции
На стороне Windows скрипт принимает байты, сохраняет во временный файл, открывает его через Word.Application, выполняет нужные манипуляции и возвращает файл обратно в ответе (подобным образом работает конструктор API для обмена). Это позволяет серверу 1С на Linux оставаться "чистым" и не зависеть от Windows-компонент напрямую.
Рассмотрим более экзотический, но жизнеспособный вариант, когда мы не хотим заводить отдельную Windows-машину. Мы можем создать Docker-контейнер на базе Linux, внутри которого через Wine будет установлен Microsoft Office.
Для реализации этого метода нам потребуется:
Wine и настроенным Xvfb (виртуальный видеобуфер), так как Word требует графическую оболочку даже при работе через COM.Выясним причину, почему это может быть сложно: лицензирование Microsoft Office в среде Docker/Linux является юридически "серой" зоной, а настройка стабильной работы COM-объектов через Wine требует глубоких знаний системного администрирования.
Если задача стоит остро и бюджет позволяет, лучшим решением будет отказ от COMОбъект в пользу кроссплатформенных библиотек. Проанализируем работу с Aspose.Words. Эта библиотека существует для Java и .NET Core и позволяет работать с файлами .doc напрямую в Linux без установленного Word.
Посмотрим на алгоритм интеграции:
ЗапуститьПриложение().Пример вызова внешней утилиты из 1С:
КомандаЗапуска = "java -jar WordProcessor.jar /tmp/doc1.doc 'Штрихкод123'";
ЗапуститьПриложение(КомандаЗапуска, , Истина);
// После завершения считываем результат из временного каталога
Разберем ситуацию, когда нам критически важно сохранить форматирование, но мы готовы работать с форматом .docx. Вместо LibreOffice можно использовать утилиту от Microsoft — WordConv.exe. Она входит в состав пакета совместимости Office.
Проанализируем её преимущества: она работает в Wine гораздо стабильнее, чем полноценный Word, и выполняет конвертацию бинарного .doc в .docx максимально корректно, используя родные алгоритмы Microsoft. После конвертации мы можем манипулировать .docx как обычным ZIP архивом с XML внутри, что легко реализуется средствами 1С на Linux.
Проанализируем основную причину, по которой документы "едут" при обработке на Linux. Это отсутствие стандартных шрифтов Windows (Arial, Times New Roman, Calibri). При любом способе обработки (через Wine или библиотеки) обязательно установите пакет шрифтов ttf-mscorefonts-installer. Без них корректное вычисление границ колонтитулов и позиционирование штрихкодов в документе будет невозможным.
Подведем итог: Работа с COMОбъект("Word.Application") на Linux напрямую невозможна. В качестве альтернативного способа вывода данных можно использовать экспорт печатных форм в изображения. Выбор решения зависит от ваших ресурсов: используйте Windows-микросервис для надежности, Aspose.Words для максимальной производительности или обработчик на клиенте 1С как самый быстрый и бюджетный способ реализации.