Поиск в бинарном файле.

← →
Stas12 (2007-04-25 18:36) [0]

Не хочется изобретать велосипед, поэтому занимаюсь поиском хорошего, готового решения "поиска в бинарном файле", например требуется найти некоторую последовательность байт (6-10) в некотором файле. Может кто-то использовал/видел готовые хорошие модули, исходники?

← →
Германн © (2007-04-25 18:58) [1]

> Stas12 (25.04.07 18:36)
>
> Не хочется изобретать велосипед, поэтому занимаюсь поиском
> хорошего, готового решения "поиска в бинарном файле", например
> требуется найти некоторую последовательность байт (6-10)
> в некотором файле. Может кто-то использовал/видел готовые
> хорошие модули, исходники?
>

Ищи в поисковиках, например, Boyer-Moore-Horspool.

← →
Leonid Troyanovsky © (2007-04-25 22:39) [2]

> Stas12 (25.04.07 18:36)

> хорошего, готового решения "поиска в бинарном файле", например
> требуется найти некоторую последовательность байт (6-10)

Насчет хорошего и готового не уверен, но посмотри
http://groups.google.com/group/fido7.ru.delphi.chainik/msg/1bdc145369d6a42d

--
Regards, LVT.

← →
Loginov Dmitry © (2007-04-26 07:59) [3]

А "нехорошее" это решение из-за того, что при поиске данных в больших файлах метод будет стараться засунуть весь файл в оперативную память, из-за чего может начаться активная работа с файлом подкачки. С таким подходом в общем случае невозможно обработать файл размером более 2 гигов даже в Win XP. Для обработки больших файлов следует периодически осуществлять вызов MapViewOfFile и UnMapViewOfFile и задавать оправданное ограничение на размер отображения (в идеале, имхо, не более 10 МБайт), однако для Win98 такой способ один фиг не подойдет, поэтому более универсальный способ обработки больших файлов - использование TFileStream.

← →
Игорь Шевченко © (2007-04-26 11:56) [4]

Loginov Dmitry © (26.04.07 07:59) [3]

> поэтому более универсальный способ обработки больших файлов
> - использование TFileStream.

У класса TFileStream не нашел метода поиска. Как обрабатывать большие файлы для поиска с использованием TFileStream ?

← →
begin...end © (2007-04-26 12:07) [5]

Де жа вю :)

http://www.mytempdir.com/1309232

← →
Loginov Dmitry © (2007-04-26 17:59) [6]

> У класса TFileStream не нашел метода поиска. Как обрабатывать
> большие файлы для поиска с использованием TFileStream ?

Код выпрашиваете?
:))

Вообще сообщением [3] я ставил целью объяснить автору, какие грабли могут его ожидать при обработки больших файлов с помошью FileMapping"a. Насчет кода мы не договаривались. Хотя пример с TFileStream вот: http://code.progler.ru/view/245

← →
Leonid Troyanovsky © (2007-04-26 18:16) [7]

> Loginov Dmitry © (26.04.07 07:59) [3]

> в больших файлах метод будет стараться засунуть весь файл
> в оперативную память, из-за чего может начаться активная
> работа с файлом подкачки.

Какой такой метод? Файл подкачки тут, вообще, ни причем
потому как это проекция физического файла.
Размещаться же в ОЗУ будет столько страниц,
сколько нужно на код, плюс обрабатываемые данные -
это дело системы.

Ну, а насчет 2 гб - все верно, но в ТЗ я такого не видел.

--
Regards, LVT.

← →
Loginov Dmitry © (2007-04-26 21:42) [8]

> Какой такой метод? Файл подкачки тут, вообще, ни причем
> потому как это проекция физического файла.
> Размещаться же в ОЗУ будет столько страниц,
> сколько нужно на код, плюс обрабатываемые данные -
> это дело системы.

Файл подкачки при том, что если память уже порядком загружена другими приложениями, то есть вероятность, что система станет выгружать соответствующие им страницы оперативной памяти в файл подкачки. Допустим (насколько я понимаю данный механизм), есть файл размером в 1 Гиг. Создано файловое отображение в 1 Гиг. Во-первых, файловое отображение создается в адресном пространстве приложения, которого и так не много - всего 2 Гига (по дефолту), а если приложение уже чем-то заняло более 1 Гига, то и файловое отображение такого размера уже негде будет создавать.
Во-вторых, при обработке большого файлового отображения, система особо не будет стремится выгрузить использованные странички из оперативной памяти, а выгружать она их начнет после того, как места в оперативке не останется, причем выгрузит сперва давно неиспользуемые странички, занятые, как правило, другими приложениями (хотя это и дело системы, но нужно иметь ввиду). Поэтому для больших файлов следует ограничивать размеры файлового отображения разумными числами.

← →
Sha © (2007-04-26 22:41) [9]

> Loginov Dmitry © (26.04.07 17:59) [6]

По-моему, в функции FindHexStringInFile есть неточность,
кажется, она не находит данные, если они пересекают границу буфера
(в твоем случае 8k).

Чтобы проще отладить, замени 8k на 2 и попробуй найти в файле
с данными "abcd" строки "ab", "bc" и "cd". Функция найдет
первую и третью строки, но не найдет вторую.

Успехов.

← →
Sha © (2007-04-26 22:51) [10]

> Loginov Dmitry © (26.04.07 07:59) [3]
> С таким подходом в общем случае невозможно обработать файл размером более 2 гигов даже в Win XP.

Кстати, ты тоже под размер файла используешь переменную типа integer,
так что и у тебя эта проблема имеется )

← →
Loginov Dmitry © (2007-04-26 23:36) [11]

Дык дату исходника видели? Это ж одна из древнейших моих работ. Пришлось ссылку с помощью яндекса отыскивать :))
Неужели описание исходника не отпугнуло, и Вы все-равно решились его скачать?!

> По-моему, в функции FindHexStringInFile есть неточность,
>
> кажется, она не находит данные, если они пересекают границу
> буфера
> (в твоем случае 8k).

Сейчас специально проверил - функция все отыскивает. Она корректно ищет текст, разделенный границей буфера.

> Кстати, ты тоже под размер файла используешь переменную
> типа integer,
> так что и у тебя эта проблема имеется )

Когда вся эта хрень писалась, о размерах файлов свыше 2-х гигов и речи не велось. А откуда взялось магическое число 8192 я и говорить не хочу :)

← →
Leonid Troyanovsky © (2007-04-27 00:05) [12]

> Loginov Dmitry © (26.04.07 21:42) [8]

> Файл подкачки при том, что если память уже порядком загружена
> другими приложениями, то есть вероятность, что система станет
> выгружать соответствующие им страницы оперативной памяти

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

> 2 Гига (по дефолту), а если приложение уже чем-то заняло
> более 1 Гига, то и файловое отображение такого размера уже
> негде будет создавать.

С этим никто не спорил. Но, как уже говорилось, в ТЗ про это нет.

> Во-вторых, при обработке большого файлового отображения,
> система особо не будет стремится выгрузить использованные
> странички из оперативной памяти, а выгружать она их начнет
> после того, как места в оперативке не останется, причем
> выгрузит сперва давно неиспользуемые странички, занятые,
> как правило, другими приложениями (хотя это и дело системы,
> но нужно иметь ввиду). Поэтому для больших файлов следует
> ограничивать размеры файлового отображения разумными числами.

Весьма спорно как насчет нестремления, так и приоритетного
выгружения страниц других процессов. Ну и вывод расплывчат.

Если есть возможность целиком отобразить, то - отображать.
Нет - уменьшать размер просмотра особого смысла нет, потому что,
как и в случае с ReadFile, надо следить за правильностью
перехода через границу буфера/просмотра.

Как-то Дмитрий Голдобин изучал как дискардятся страницы
у просмотров размера меньших размера проекции.
На сколько я помню, к.л. преимуществ перед проекцией на
весь файл обнаружено не было.

--
Regards, LVT.

> Loginov Dmitry © (26.04.07 23:36) [11]
> Неужели описание исходника не отпугнуло, и Вы все-равно решились его скачать?!

Интересно ж проверить, наскоколько описание нутру соответстует )

>> По-моему, в функции FindHexStringInFile есть неточность,
>> кажется, она не находит данные, если они пересекают границу
>> буфера (в твоем случае 8k).

> Сейчас специально проверил - функция все отыскивает. Она корректно
> ищет текст, разделенный границей буфера.

Я тоже проверил. Сделал все, как предложил - не ищет ни фига.

> Я тоже проверил. Сделал все, как предложил - не ищет ни
> фига.

Ищет-неищет-ищет-неищет....
Ну фик с нею. Сто лет как не нужна никому! :))

> [12] Leonid Troyanovsky © (27.04.07 00:05)

У меня система Win XP. 512 Мбайт оперативки. Запущено несколько приложений. Безо всякой теории, буквально по звуку работающего винта определяю, на сколько оказывается загруженным файл подкачки.
Вот такой тривиальный код:

uses ...MemMapUnit, {Teiksera, Pacheka, Delphi 5} ProgressViewer { (c) }; procedure TForm1.Button1Click(Sender: TObject); var Ar: PByteArray; I: Integer; Counter: Integer; Pv: TProgressViewer; begin Counter := 0; if FileExists(FilenameEdit1.Text) then with TMemMapFile.Create(FilenameEdit1.Text, fmOpenRead, 0, True) do try Ar := Pointer(Data); Pv := TProgressViewer.Create("Обработка файла", True); try for I := 0 to Size - 1 do begin if Ar[I] = 0 then Inc(Counter); if I mod 10000 = 0 then Pv.CurrentValue := I / Size * 100; end; finally Pv.Terminate; end; finally Free; end else raise Exception.Create("Файл не найден!"); Caption := IntToStr(Counter); end;

Тестю на VOB-файле размером 1073565696.
После обработки данного файла система еще минуты 3 "отвисает". Это подтверждает слова, сказанные мною ранее.
И противоречит Вашему утверждению:
Вклад просматриваемой последовательно
проекции (только для чтения) здесь невелик - давно неиспользуемые
страницы не сбрасыватся в файл или в своп.

Модуль MemMapUnit взят из книги Teiksera, Pacheka, Delphi 5.

Код открытия файла:
FFileHandle := FileOpen(FFileName, fmOpenRead)

Код создания объекта отображения:
FMapHandle := CreateFileMapping(FFileHandle, Nil, Page_ReadOnly, 0, FSize, Nil);

Код создания окна просмотра:
FData := MapViewOfFile(FMapHandle, File_Map_Read, 0, 0, FSize);

> Ну фик с нею. Сто лет как не нужна никому!

А зачем выкладываешь, да еще и на memory mapping наезжаешь ?
Слону, как ты понимаешь, нифига не сделается.

> Loginov Dmitry © (27.04.07 08:44) [15]

> Тестю на VOB-файле размером 1073565696.
> После обработки данного файла система еще минуты 3 "отвисает".
> Это подтверждает слова, сказанные мною ранее.
> И противоречит Вашему утверждению:

Не знаю, что там у тебя отвисает, но приведенный мной ранее
пример ничего такого не демонстрирует.
Запустив Performance Monitor и изучив то, что относится
Paging File легко заметить, что он здесь ни причем.

Конечно, Page faults; Pages/sec великоваты, но это и понятно,
и ничего другого я и не обещал.

--
Regards, LVT.

Я вот что не пойму, откуда в этой задаче проблемы возникают? Разве нельзя читать файл последовательно блоками килобайт по восемь и искать? Ну можно даже не последовательно, а сделать небольшой перехлест блоков байтов на 100, если хочется использовать функцию Pos. Неужели на файлах 2 Гб возникнут какие-то проблемы? Ну за минуту он его прочитает.

Поиск в бинарном файле. Найти похожие ветки