Есть много xml файлов различного объема, лежащих в подкаталогах одного каталога. Хотелось бы организовать поиск по подстроке в содержимом данных файлов и потом открывать их, если подстрока найдена.
В связи с этим возник вопрос: как считать сразу содержимое файла в строку с тем, чтоб сразу в ней искать содержимое(нашел примеры только последовательного чтения)?

1. Не надо читать файл сразу в строку, размер файла может быть большим
2. Читать построчно
3. Записывать в БД: имя файла, номер строки, текст строки
4. Поиск по БД
5. Для ускорения поиска в БД и нечеткого использовать индекс через метод N-грамм

(0) Может быть быстрее использовать findstr или grep?

(0) многопоточность

(2) зависимость от ОС и вызов внешних средств
еще предложи микросервис на Го

(0) Реши эту проблему топовым железом, главное поиск вести на SSD))

(0) О, придумал, используй облачные решения с их суперкомпьютерами для обработки твоих xml файлов. Ну при этом надо разработать взаимодействие 1С с API облачных решений))

(6) сразу уж ИИ припрячь...

(7) Кстати, разработать взаимодействие 1С с API сторонних программ уже вполне рядовая задача

(7) Так что если есть ИИ разрешенный в России с API, то можно привлечь и ИИ, только он в этой задаче (0) мало чем поможет

(8) а вы преподаватель, да? теоретика всмысле?

(7) В windows 12 есть встроенный ИИ, причем он в полную силу работает только с новыми процессорами поддерживающим этот ИИ, ну чтобы не ждать сентября-октября 2024, можно интеграцию и сейчас разработать

(10) Нет, уже дорабатывал такую интеграцию 1С со сторонним API. С нуля конечно в одно лицо не делал всю интеграцию, но систематически дорабатываю в 1С интеграцию со сторонним API, API же меняется у сторонних программ, появляется новый функционал.

(10) Сейчас перед мной стоит задача реализовать интеграцию 1С:ЗУП и Госключа (у него открытый API), причем "с нуля" и в одно лицо.

"с нуля"
на эту тему есть много романтических песен, удачи))

(14) Ну я подсмотрю как это сделано в той интеграции которая уже реализовано в нашей компании, не так уж там и много кода. А "с нуля" в одно лицо я уже разработал свою нетленку с переносом в нее части БСП и организации обмена с ЗУП. И эта нетленка очень и очень была оценена конечными заказчиками. А ЗУП - это моя территория))

(15) Ну все сажаются обычно только в детском доме и то мой отец был из интерната и не то что не сел, а стал инженером, потом начальником и прожил достойную жизнь

(16) Сорри, не туда написал))

findstr или grep

(18) Плагиат (2) я тоже умею копировать и вставлять))

(4) ну кстати некое регламентное задание - может, в виде 1Совского, может, в виде отдельной программы или скрипта, которое будет периодически запускаться и поддерживать индекс в актуальном состояни - пригодится. Так что "микросервис на Go" тут как раз не исключен.
Я в свое время решал подобную задачу, у меня была куча EDI-файлов RECADV и требовалось среди них быстро найти файл от нужной поставки. Сделал отдельные XML-файлы индексов - по одному на каждую дату месяца, где хранились ключевые данные для поиска (номер заказа, номер документа, контрагент, точка доставки) и собственно ссылка на файл. Софт сначала лазил в индекс, находил требуемое имя, затем уже отправлялся в нужный файл. Отдельный скрипт на пайтоне раз в некоторое время запускался и осуществлял доиндексацию вновь прилетевших файлов.
Кстати, не вполне понятно, зачем ТСу искать по всему подряд. Все же XML - это структурированная инфа, поэтому думается, что нужно искать по каким-то узлам и атрибутам.

(19) чем больше накопипастить правильный ответ, тем больше поможешь автору

(20) Может я совсем древний но для данной задачи мне хватает Sublime - Find in Files... в Visual Studio Code тоже есть.

Локалько по каждому файлу пользуюсь https://github.com/sikuda/bigxmlread.

(22) я так думаю, ему их внутри своего софта обрабатывать надо. Скорее всего, 1Сным кодом.

Поиск файлов по содержимому - вот тут нашел подходящий пример по findstr тут в конце даже пример расписан. Но у меня, почему-то, не взлетает.
МаскаПоиска =  ОбщегоНазначенияКлиентСервер.ДобавитьКонечныйРазделительПути(Объект.КаталогДляПравилОбмена)+"*.xml";//Файл.ПолноеИмя;//"\FlashBackIN\*.xml";
        СтрокаПоиска = "БухгалтерияПредприятияКОРП";
        
        КомандаПоиска = "findstr /i /s /m /c:" + """" + СтрокаПоиска + """" +  " """ + МаскаПоиска + """";

        
        Shell = Новый COMОбъект("WScript.Shell");
        WshExec = Shell.Exec(КомандаПоиска);
        OutStream = WshExec.StdOut;
        Str = "";
        Пока Не OutStream.AtEndOfStream Цикл
            Str = Str + СокрЛП(OutStream.ReadLine());
        КонецЦикла;
        Сообщить("Str = " + Str);

Str всё время пустая.
ЧЯДНТ?

Пробовал и в каталог только с латинскими символами в названии переносить, и в ковычки дополнительные брать искомое слово - не хочет искать

(25) проблемы с кодировками могут быть. Скажем, в stdout выводятся данные в CP866, а ReadLine () ожидает, что они будут в UTF-16. То же самое русский текст в строке поиска на входе. Но это не точно, надо проверять. Вопрос также по кодировкам самих файлов XML. Я что-то не нашел в ключах /I /S /M /C: ничего такого, что указывало бы на поиск по разным кодировкам, а в XML теоретически может быть любая, как минимум распространены windows-1251 и utf-8, которые довольно сильно различаются в части кириллицы. И точно ли findstr отработает правильно? Нужно понимать, что если вы не используете XML-парсер для открытия XML-файлов, то вся головная боль с кодировками и правильным чтением данных ложится на вас.

(25) да, моя ошибка,findstr не работает с разными кодировками. Для grep можно указать кодировку, но это "ручной режим", не универсально.

(24) >ЧЯДНТ?
Все не так.
Не используй findstr/grep.
Используй (1) и (3)
Или возьми нормальный ЯП (тот же Golang) и напиши нормальный сервис

Для общего развития как это примерно делается
https://habr.com/ru/articles/519024/

(24) если тупо найти строку, то вот это попробуй
https://cloud.mail.ru/public/Qm9S/hMysC4pvR
там текст командной строки в utf-8 преобразуется

запускать так
textfind.exe c:\test\data *.xml "текст поиска"