При обработке текстовых файлов (например, логов технологического журнала 1С) разработчики часто сталкиваются с ситуацией, когда запись логически должна быть единой строкой, но содержит внутри одиночные символы перевода строки LF (в терминологии 1С — Символы.ПС). Это происходит из-за того, что в лог записываются многострочные структуры: тексты SQL-запросов, стек вызовов или подробные описания ошибок.
В этом материале мы разберем причину такого поведения платформы, рассмотрим решение с помощью правильно настроенного объекта ЧтениеТекста, а также проанализируем альтернативные и более надежные архитектурные подходы к обработке технологического журнала.
По умолчанию объекты платформы 1С (такие как ТекстовыйДокумент и ЧтениеТекста) при загрузке файлов выполняют автоматическую нормализацию разделителей строк. В Windows стандартным разделителем является комбинация CR+LF (Символы.ВК + Символы.ПС), а в Linux — одиночный символ LF (Символы.ПС).
Если платформа встречает одиночный символ LF внутри текста, она по умолчанию принимает его за конец строки. В результате единое событие журнала распадается на множество фрагментов, что ломает структуру данных при дальнейшем анализе.
Для корректной работы с файлом необходимо явно указать платформе, какие именно символы должны считаться основным разделителем строк, а какие должны игнорироваться или обрабатываться иначе.
Рассмотрим конструктор объекта ЧтениеТекста. Чтобы задать разделителем исключительно комбинацию CR+LF, передадим соответствующие параметры:
ИмяФайла = Файл.ПолноеИмя;
ЧтениеТекста = Новый ЧтениеТекста(
ИмяФайла,
КодировкаТекста.UTF8,
Символы.ВК + Символы.ПС,
Символы.ПС
);
СтрокаТекста = ЧтениеТекста.ПрочитатьСтроку();
Пока СтрокаТекста <> Неопределено Цикл
// Обработка прочитанной строки
СтрокаТекста = ЧтениеТекста.ПрочитатьСтроку();
КонецЦикла;
ЧтениеТекста.Закрыть();
Передавая комбинацию Символы.ВК + Символы.ПС в качестве третьего параметра (разделитель строк), мы явно указываем платформе, что разрыв логической строки происходит только при встрече полной последовательности CR+LF. Одиночные символы LF перестанут приводить к ошибочному разбиению.
Если файл содержит сложное бинарное или текстовое содержимое, где встроенная логика нормализации строк платформы все равно искажает данные, разберем более гибкий вариант с использованием низкоуровневых объектов ЧтениеДанных и ПотокЧтения.
Этот подход позволяет самостоятельно анализировать поток байтов и определять точные границы строк по байтовым последовательностям 0x0D 0x0A (CRLF), полностью исключая влияние неявных преобразований платформы 1С:
ДвоичныеФайла = Новый ДвоичныеДанные(ИмяФайла);
Поток = ДвоичныеФайла.ОткрытьПотокДляЧтения();
ЧтениеДД = Новый ЧтениеДанных(Поток);
// Чтение данных и поиск последовательности байтов 0x0D 0x0A
// Позволяет вручную контролировать разделение записей
Проанализируем другие популярные техники, применяемые при анализе логов 1С:
12:34.567000-0,). Мы можем читать файл построчно и проверять начало каждой полученной подстроки. Если строка не начинается с даты/времени, значит, она является продолжением предыдущего события.РегулярноеВыражение (доступен с версии 8.3.23) или VBScript.RegExp можно выполнять поиск по шаблону ^\d{2}:\d{2}\.\d{6}-\d в многострочном режиме.ЧтениеJSON.Запись гигабайтных файлов технологического журнала напрямую в регистр сведений 1С является неудачной практикой. Посмотрим на основные риски такого подхода:
Для эффективной работы с логами большого объема рекомендуется сохранять исходные файлы в архивном файловом хранилище или загружать их в специализированные внешние базы данных (например, ClickHouse или Elasticsearch), используя 1С только для получения готовых агрегированных отчетов.