Заинтересовал меня формат файлов журнала регистрации, но поиск в интернете не дал никаких результатов. Пришлось изучать его самому. Так родилась обработка //infostart.ru/public/181455/ - Анализ и редактирование файлов журнала регистрации 8.1/8.2 - ELF/LOG/LGF/LGP. Как и обещал, постарался написать полноценную статью о формате файлов журнала регистрации 1С 8.
В 1С 8 журнал регистрации хранится в текстовых файлах, которые находятся в подкаталоге 1Cv8Log. Для клиент-серверной ищем где-то в "C:\Program Files\1cv82\srvinfo\reg_1541\\1Cv8Log\".
Обычно журнал регистрации 1С 8 состоит из одного файла описаний (ELF в 8.1 / LGF в 8.2) и одного или нескольких файлов данных (LOG в 8.1 / LGP в 8.2). Существуют еще так называемые архивы журнала регистрации – в этом случае описания и данные находятся в одном файле последовательно, сначала описания, затем данные, при этом расширение как у файла данных.
В первой строке файла журнала регистрации пишется маркер
"1CV8LOG_" для 8.1 и "1CV8LOG(ver 2.0)" для 8.2.
Во второй строке пишется GUID.
Для файла данных журнала регистрации пишется еще дополнительно третья пустая строка.
Дальше идут непосредственно данные, которые заключены в фигурные скобки "{}" и отделяются друг от друга запятой.
При парсинге журнала регистрации сталкиваемся с проблемой отделения друг от друга записей – ведь они имеют переменную длину и могут быть разбиты на разное число строк, которое получается из-за следующих правил, добавляющих дополнительные символы новой строки (Символы.ПС):
1) Открывающей фигурной скобке "{ "в файле всегда предшествует символ новой строки;
2) Закрывающие фигурные скобки "}" не могут идти подряд – они всегда разделены символом новой строки;
3) Символ новой строки может встретиться внутри кавычек.
Таким образом отделить запись можно по следующим критериям
1) Первый символ – открывающая фигурная скобка "{";
2) Число открывающих фигурных скобок "{" равно числу закрывающих фигурных скобок "}";
3) Последний символ – закрывающая фигурная скобка "}";
4) Так же у правильной записи всегда будет четное число кавычек.
Структура записей файла описаний 8.1 сильно отличаются от 8.2.
При анализе файла описаний 8.1 по приведенным выше правилам получим всего одну запись, которая будет состоять из элемента "Legend" и вложенных записей. Структура вложенных записей одинакова – это заголовок и вложенная запись. Заголовок может принимать следующие значения "Users" – GUIDы пользователей, "UserNames" – имена пользователей, "Hosts" – компьютеры, "Apps" – приложения, "Events" – события, "MDID" - GUIDы метаданных, "MDCodes" – имена метаданных, "SrvHosts" – серверы, "MainPorts" – основные порты, "SyncPorts" – вспомогательные порты. Вложенные записи состоят по сути из массивов. Первый элемент – размер массива, дальше идут непосредственно значения. Разделитель – запятая.
При анализе файла описаний 8.2 увидим другую картину. Файл содержит много записей размером от обычно трех элементов до четырех, в случае если надо указать GUID – для пользователей и метаданных.
Формат записи прост – первый элемент код массива, второй – значение, третий – номер в массиве. В случае четырех записей, между первым и вторым элементом появляется GUID.
Коды массивов были обнаружены следующие:
1 – пользователи;
2 – компьютеры;
3 – приложения;
4 – события;
5 – метаданные;
6 – серверы;
7 – основные порты;
8 – вспомогательные порты.
Так же встречаются пока неопознанные коды 11, 12 и 13
Таким образом, из файлов описаний получаем необходимые справочники, которые будут использованы в файлах данных.
Структура записей файлов данных 8.1 отличается от 8.2 по сути только количеством элементов. В 8.1 запись состоит жестко из 16 элементов, а в 8.2 число элементов переменно и может быть от 19 штук и до в принципе любого количества.
Далее приведу значения элементов в записи:
1) Дата и время в формате "yyyyMMddHHmmss", легко превращается в дату функцией Дата();
2) Статус транзакции – может принимать четыре значения "N" – "Отсутствует", "U" – "Зафиксирована", "R" – "Не завершена" и "C" – "Отменена";
3) Транзакция в формате записи из двух элементов преобразованных в шестнадцатеричное число – первый – число секунд с 01.01.0001 00:00:00 умноженное на 10000, второй – номер транзакции;
4) Пользователь – указывается номер в массиве пользователей;
5) Компьютер – указывается номер в массиве компьютеров;
6) Приложение – указывается номер в массиве приложений;
7) Соединение – номер соединения;
8) Событие – указывается номер в массиве событий;
9) Важность – может принимать четыре значения – "I" – "Информация", "E" – "Ошибки",
"W" – "Предупреждения" и "N" – "Примечания";
10) Комментарий – любой текст в кавычках;
11) Метаданные – указывается номер в массиве метаданных;
12) Данные – самый хитрый элемент, содержащий вложенную запись;
13) Представление данных – текст в кавычках;
14) Сервер – указывается номер в массиве серверов;
15) Основной порт – указывается номер в массиве основных портов;
16) Вспомогательный порт – указывается номер в массиве вспомогательных портов;
17) Сеанс – номер сеанса;
18) Количество дополнительных метаданных, номера которых будут перечислены в следующих элементах записи. Именно 18-й элемент определяет длину записи, т.к. дальше будут следовать столько элементов сколько указано здесь + один последний, назначение которого пока не определено и обычно там "{0}". Возможно это просто маркер окончания записи. Так же есть идея что {0} похоже на пустой массив.
Теперь рассмотрим вложенную запись элемента 12 (Данные), который может принимать следующие значения:
1) {"U"} – Неопределено – можно преобразовать через ЗначениеИзСтрокиВнутр();
2) {"S","Строка"} – Строка – можно преобразовать через ЗначениеИзСтрокиВнутр();
3) {"R",id:GUID} – Ссылка c GUID, где метаданные с id. Для получения id метаданных пока нашел только немного извращенный способ – ЗначениеИзСтрокиВнутр(ТипМетаданных.ИмяМетаданных.ПустаяСсылка()) и парсить полученную строку.
4) {"P",{6,{"S","Строка1"},{"S","Строка2"}}}– что-то вроде массива но пока не понятно что значит 6 – на ее месте пока встречал только 1, 2 и 6. Возможно это разные типы - массив, структура и т. п.
Таким образов, в целом формат журнала регистрации как 1С 8.1, так и 1С 8.2 разобран. Есть некоторые недопонимания, которые надеюсь со временем прояснятся, но даже они не мешают парсить файлы обработке - //infostart.ru/public/181455/ - Анализ и редактирование файлов журнала регистрации 8.1/8.2 - ELF/LOG/LGF/LGP
Позже появилась довольно интересная публикация - Периодическая загрузка событий из журналов регистрации в базу MS SQL Server, где автор парсит файлы журнала регистрации напрямую, причем он пишет, что разбирал формат журнала регистрации сам, задолго до текущей публикации, но к сожалению пока дополнительно найденной информацией по формату с сообществом не поделился.