Заказчик

Есть некий файл лога в формате UTF-8 с BOM.
Проблема в том, что некоторые события в файле занимают несколько строк. а должны занимать одну строку для удобного поиска по рег. выражению.
Необходимо сначала удалить все переносы строк в этом файле, а потом вставить переносы только в тех местах где начинается новое событие лога. Эти места известны, они подходят под маску рег. выражения.
Переносы могут быть как LF так и CRLF.
Раньше пользовался утилитой Ned, но стали встречаться файлы в которых есть символы не кодирующиеся UTF-8 и Ned такое проживать не смог. Наличие таких символов тоже надо учесть, файлы для теста я дам.
Очень важный момент, программа должна работать очень быстро, т.к. файлы для обработки могут занимать несколько Гб. Разбор файла на 1Гб не должен занимать больше минуты.
Желательно написать на C++ или чем-то подобном скоростном.

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

Структура логов известна.
1. Парсер должен быть реализован в обработке 1С, где загрузка логов происходит с помощью внешней компоненты.
2. Парсер должен читать логи ТЖ с указанной периодичностью.
3. Должна быть настройка которая определяет сколько памяти может задействовать парсер, что бы можно было регулировать нагрузку на систему при чтении очень больших логов в десятки Гб, т.к. это не должно приводить к сбоям в работе компьютера или парсера.
4. Данные логов будутзагружаться и храниться в регистре сведений, где свойства событий из ТЖ это отдельные колонки регистра сведений.
5. В парсере должны быть настройки соответствия, где указано какая информация из лога в какую колонку таблицы будет загружаться. Так же должна быть возможность изменять, добавлять и удалять эту информацию. Например, если появились новые свойства в логах ТЖ, это потребует добавления колонок в регистр сведений и указание нового соответствия в парсере для этих колонок.
6. Основной упор нужно сделать именно на производительность и быструю загрузку данных в базу. Возможно для этого нужно будет сделать обработку загрузки многопоточной.
7. В таблице будут содержаться не только логи, но некоторые вычисляемые колонки. Значения в них будут зависеть от значений других колонок парсера. Надо предусмотреть в парсере возможность вычисления этих колонок.
8. Данные в логах разделяются в основном запятой, но запятая так может быть в значениях параметров логов. Это надо учитывать. Например, p:processname=Base,Usr=Смирнов,Fld5422=По документам 01,04 и 12,Fld6765=ООО Рога и копыта это должно быть корректно распарсено на 4 поля с 4 значениями, несмотря на запятые и кавычки внутри самих значений.
9. Так же возможна ситуация когда некоторые значения не помещаются в одну строку лога и переносятся на другую строку, несмотря на это данные должны обрабатываться и загружаться корректно. Такие ситуации относительно легко отследить т.к. новая строка лога всегда начинается с цифр в формате ММ.СС. Где ММ это минуты, а СС секунды.

Это основная часть ТЗ, детали будем обсуждать с исполнителем.