Зачем нужен реквизит ТекстФайла в справочнике ХранилищеДополнительнойИнформации?

В типовых конфигурациях на базе обычных форм, таких как Управление торговлей 10.3, часто встречается справочник ХранилищеДополнительнойИнформации. Одной из его загадочных особенностей является наличие реквизита ТекстФайла с типом ХранилищеЗначения. На первый взгляд может показаться, что система просто дублирует данные, создавая лишнюю нагрузку на базу. В этой статье мы подробно разберем, какую критически важную роль играет этот реквизит, как работает код по его заполнению и почему это техническое решение актуально до сих пор.

Анализ механизма извлечения текста

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

ДанныеХранилища = Хранилище.Получить();
ТекстФайлаЗаписан = Ложь;
Если ТипЗнч(ДанныеХранилища) = Тип("ДвоичныеДанные") Тогда
    ВременныйФайл = ПолучитьИмяВременногоФайла(РаботаСФайлами.ПолучитьРасширениеФайла(ИмяФайла));
    Попытка
        ДанныеХранилища.Записать(ВременныйФайл);
        Извлечение = Новый ИзвлечениеТекста(ВременныйФайл);
        ТекстФайла = Новый ХранилищеЗначения(Извлечение.ПолучитьТекст());
        ТекстФайлаЗаписан = Истина;
    Исключение
        ТекстФайлаЗаписан = Ложь;
    КонецПопытки;
    УдалитьФайлы(ВременныйФайл);
КонецЕсли;

Разберем по шагам, что здесь происходит:

1. Программа получает бинарные данные из основного хранилища (где лежит сам файл, например, картинка, PDF или документ Word).
2. Создается временный файл на диске с правильным расширением. Это необходимо, так как объект ИзвлечениеТекста работает именно с файлами на физическом носителе.
3. С помощью системного объекта ИзвлечениеТекста платформа пытается «прочитать» содержимое файла и вычленить из него только текстовую информацию, отсекая форматирование и бинарные маркеры.
4. Полученная строка упаковывается в ХранилищеЗначения и помещается в реквизит ТекстФайла.

Главная цель: Полнотекстовый поиск (ПП)

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

Многие пользователи хотят находить документы не только по названию, но и по словам внутри них. Например, найти договор по ИНН контрагента или счет по названию номенклатуры, хотя эти данные есть только внутри прикрепленного PDF-файла. Механизм полнотекстового поиска 1С индексирует текстовые данные реквизитов. Если мы просто положим файл в базу как ДвоичныеДанные, поисковый индекс не сможет «заглянуть» внутрь набора байтов без предварительной обработки.

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

Почему используется тип ХранилищеЗначения, а не длинная строка?

Выясним причину выбора типа данных ХранилищеЗначения вместо стандартной неограниченной строки. Здесь играют роль два важных фактора:

• Сжатие данных: Объект ХранилищеЗначения в 1С автоматически сжимает данные (используется алгоритм zlib). Текстовое содержимое документов может занимать мегабайты, а после сжатия объем уменьшается в несколько раз, что экономит место в базе данных.
• Работа с LOB-объектами: В архитектуре СУБД (MS SQL Server, PostgreSQL) работа с большими двоичными объектами через механизмы ХранилищаЗначения часто оказывается более эффективной и стабильной, чем манипуляции с очень длинными текстовыми полями.

Технологическая основа: Интерфейс IFilter

Объект ИзвлечениеТекста не является всесильным сам по себе. Его работа базируется на технологии Microsoft IFilter. Это стандартный интерфейс Windows, который позволяет индексировать содержимое различных форматов файлов.

Проанализируем важный нюанс: если на сервере или компьютере пользователя не установлены соответствующие фильтры (например, Microsoft Office Filter Pack или Adobe PDF iFilter), то вызов Извлечение.ПолучитьТекст() вернет пустую строку для файлов .docx или .pdf. Именно поэтому в коде используется блок Попытка ... Исключение — если система не знает, как прочитать файл, программа просто проигнорирует извлечение текста, сохранив сам файл в целости.

Производительность и разделение ресурсов

Рассмотрим ситуацию: почему бы не извлекать текст прямо в момент работы полнотекстового поиска? Ответ кроется в производительности:

1. Извлечение текста — тяжелая операция. Она требует записи во временный файл, обращения к системным библиотекам и парсинга структуры документа. Если бы полнотекстовый поиск делал это для тысяч файлов «на лету» во время индексации, это бы полностью парализовало работу сервера.
2. Стабильность индекса. Сохранив текст один раз при записи карточки файла, мы гарантируем, что поисковый индекс всегда будет иметь доступ к данным, даже если оригинальный файл по каким-то причинам станет недоступен (например, если файлы хранятся в томах на диске, и доступ к ним временно ограничен).

Развитие идеи в современных конфигурациях (БСП)

В современных решениях на управляемых формах (УТ 11, ERP, БСП) этот механизм был модернизирован. Вместо извлечения текста в обработчике ПередЗаписью (что заставляет пользователя ждать окончания процесса), часто используется отложенное извлечение текста с помощью фоновых заданий.

Тем не менее, суть остается прежней: реквизит ТекстФайла (или его аналоги в БСП) — это специализированный технический буфер, предназначенный для того, чтобы сделать «невидимые» бинарные данные доступными для мощного механизма полнотекстового поиска платформы 1С. Это не дублирование данных, а необходимая подготовка информации для удобной работы пользователя.