| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Regexp в бинарниках
DmitriyG. © (2011-11-06 14:44:00)Посоветуйте библиотеку позволяющую искать регулярные выражения в бинарных данных
DmitriyG. (2011-11-19 18:25:00) [1]Если честно пока это не принципиально. Главное чтобы поиск производился в памяти указанного размера...
han_malign (2011-11-18 09:05:00) [2]
> если чем-то не устроит PCRE...
- это скорее потом TRegExp никак не устроит - одни "subroutine" с поддержкой рекурсии(хоть и простенькой) чего стоят, не говоря уж об условных шаблонах и юникодовых классах...
Только особое внимание надо обратить на документик pcrestack, иначе на безобидном, на первый взгляд, шаблоне можно переполнение стека словить...
PCRE DISCUSSION OF STACK USAGE
..........
Reducing pcre_exec()'s stack usage
Each time that match() is actually called recursively, it uses memory
from the process stack. For certain kinds of pattern and data, very
large amounts of stack may be needed, despite the recognition of "tail
recursion". You can often reduce the amount of recursion, and there-
fore the amount of stack used, by modifying the pattern that is being
matched. Consider, for example, this pattern:
([^<]|<(?!inet))+
It matches from wherever it starts until it encounters "<inet" or the
end of the data, and is the kind of pattern that might be used when
processing an XML file. Each iteration of the outer parentheses matches
either one character that is not "<" or a "<" that is not followed by
"inet". However, each time a parenthesis is processed, a recursion
occurs, so this formulation uses a stack frame for each matched charac-
ter. For a long string, a lot of stack is required. Consider now this
rewritten pattern, which matches exactly the same strings:
([^<]++|<(?!inet))+
This uses very much less stack, because runs of characters that do not
contain "<" are "swallowed" in one item inside the parentheses. Recur-
sion happens only when a "<" character that is not followed by "inet"
is encountered (and we assume this is relatively rare). A possessive
quantifier is used to stop any backtracking into the runs of non-"<"
characters, but that is not related to stack usage.
This example shows that one way of avoiding stack problems when match-
ing long subject strings is to write repeated parenthesized subpatterns
to match more than one character whenever possible.
Compiling PCRE to use heap instead of stackfor pcre_exec()
..........
Limiting pcre_exec()'s stack usage
..........
- и не забывать, что каждый подшаблон / (... )/ требует места в векторе результатов поиска - но можно задавать подшаблон результат которого в вектор не кладется - / (?:... )/...
DmitriyG. (2011-11-17 23:04:00) [3]ОК... Спасибо за подсказку - PCRE + dll это то что нужно... И функция похожа на требуемую...
А по поводу передачи String внтури которого #0 - боюсь нужно будет устраивать некоторые танцы с бубном чтобы длина была "реальная", а не там где #0 :-)
Да и тем поболее, что все равно потом TRegExp только до #0 смотрит...
Допилить можно было бы - но это только если чем-то не устроит PCRE...
han_malign (2011-11-17 09:13:00) [4]
> Странно, почему то в описании на сайте я функцию вида
> ExecRegExpr(RegExpr, Data, DataSize)
> пока не увидел... Надо будет завтра на свежую голову посмотреть...
- она не нужна, т.к. (Ansi/Byte)String - и так "бинарный" буфер с длиной...
Но TRegExpr(Andrey V. Sorokin - v0.952) - действительно обрубится по нулю- хотя буфер и выделяется по длине строки - дальше везде прописано терминирование по #0...
Так что единственный(известный мне) нормальный - PCRE(но там придется С - прослойку делать, либо BC++ -> obj -> {$LINK ...}, либо DLL)...
(Хотя наверняка кто-то TRegExpr допиливал, там делов на пол-дня)
Германн (2011-11-17 00:19:00) [5]
> DmitriyG. © (16.11.11 23:42) [35]
>
>
> > Да понятно, что он имел в виду. Буфер в памяти он имел
> в
> > виду. Не строку, а произвольный буфер. Многие библиотеки
> > для работы с регулярными выражениями позволяют работать
> > с такими данными. Но не далеко не все.
>
>
> Ну собственно да... Именно была проблема нулевыми символами
> (после которых поиск должен останавливаться)
Вот и разберись тут "Кто прав? Кто неправ?" (с) Пиф-Паф
:)
DmitriyG. (2011-11-16 23:42:00) [6]
> Да понятно, что он имел в виду. Буфер в памяти он имел в
> виду. Не строку, а произвольный буфер. Многие библиотеки
> для работы с регулярными выражениями позволяют работать
> с такими данными. Но не далеко не все.
Ну собственно да... Именно была проблема нулевыми символами (после которых поиск должен останавливаться)....
> - кто вам сказал такую глупость - и TRegExpr, и PCRE - принимают
> на вход строку с длиной... И \Z - указывает на позицию соответствующую
> указанной длине, а не на первый #0.А EOT это - если что
> - ^Z(#$1A), а не #0...
Странно, почему то в описании на сайте я функцию вида
ExecRegExpr(RegExpr, Data, DataSize)
пока не увидел... Надо будет завтра на свежую голову посмотреть...
DVM (2011-11-16 12:31:00) [7]
> Германн © (16.11.11 11:43) [30]
> Я хочу
>
> > Осталось только спросить у автора вопроса что он имел
> в
> > виду под "бинарными данными".
Да понятно, что он имел в виду. Буфер в памяти он имел в виду. Не строку, а произвольный буфер. Многие библиотеки для работы с регулярными выражениями позволяют работать с такими данными. Но не далеко не все.
DVM (2011-11-16 12:27:00) [8]
> Германн © (16.11.11 11:43) [30]
> Я хочу
Когда ты делаешь GET запрос для получения картинки в теле HTTP ответа сервера картинка в каком виде тебе приходит? В бинарном. Не закодированном в Base64 или еще как, а именно в БИНАРНОМ. Т.е HTTP протокол позволяет передавать бинарные данные и при анализе HTTP ответов сервера этот самый ответ нельзя рассматривать только как текст, как текст можно рассматривать только его заголовок до первого CRLFCRLF.
> Anatoly Podgoretsky © (16.11.11 12:17) [32]
> > DVM (16.11.2011 10:40:29) [29]
>
> Возьми в кавычки
Не надо ничего брать в кавычки. HTTP это не текстовый протокол, не смотря на то, что его название Hyper Text Transfer Protocol вводит некоторых в заблуждение. Он передает гипертекст, а не текст, гипертекст - это не только текст, а еще и картинки, файлы и прочее.
Anatoly Podgoretsky (2011-11-16 12:17:00) [9]> DVM (16.11.2011 10:40:29) [29]
Возьми в кавычки
Медвежонок Пятачок (2011-11-16 12:02:00) [10]понеслась душа в рай.....
Германн (2011-11-16 11:43:00) [11]
> Ты хочешь сказать, что в HTTP бинарных данных нет?
Я хочу
> Осталось только спросить у автора вопроса что он имел в
> виду под "бинарными данными".
DVM (2011-11-16 10:40:00) [12]
> Германн © (16.11.11 00:38) [28]
> Это вы путаете "бинарные данные" со всем тем, что вам родно
> и близко. :(
Ты хочешь сказать, что в HTTP бинарных данных нет?
Германн (2011-11-16 00:38:00) [13]
> Не путай HTTP и HTML
Да не путаю я HTTP и HTML! :)
Это вы путаете "бинарные данные" со всем тем, что вам родно и близко. :(
DVM (2011-11-15 18:25:00) [14]
> Германн © (15.11.11 00:21) [22]
> Ну если для тебя, Дима гипертекст это "бинарные данные",
> тогда спорить не буду.
Не путай HTTP и HTML. Гипертекст = HTML. HTTP - текстово-бинарный протокол.
В ответе HTTP сервера может быть текстовый заголовок, а следом могут идти бинарные данные, например, картинка. Если тип контента multipart/x-mixed replace то следом за бинарными данными может идти опять текстовый подзаголовок и потом опять бинарные.
sniknik (2011-11-15 12:03:00) [15]> - /\x1B\x01(\x02|\x03)/
о, а вот это работает, как ожидается... получатся, действительно, ограничений нет.
han_malign (2011-11-15 10:11:00) [16]
> нет проблем, да, кроме того, что ищет символ "u", а не #27.
- /\x1B\x01(\x02|\x03)/
\u- это символ в верхнем регистре...
> Но вот если в данных будет символ с кодом 0, то на этом разбор остановиться...
- кто вам сказал такую глупость - и TRegExpr, и PCRE - принимают на вход строку с длиной... И \Z- указывает на позицию соответствующую указанной длине, а не на первый #0.
А EOT это - если что - ^Z(#$1A), а не #0...
Медвежонок Пятачок (2011-11-15 08:44:00) [17]Только зачем усложнять
Усложнять не надо, надо упрощать.
Что регулярки с успехом и делают.
Германн (2011-11-15 01:40:00) [18]
> В чем у вас проблемы-то?
> В том что Пятачок в ветке или в чем?
У нас-то проблем нет.
Только зачем усложнять "некими регулярками" поиск по "бинарньм данным"?
Германн (2011-11-15 00:21:00) [19]
> Бинарные данные сплошь и рядом регулярными выражениями обрабатываются.
>
> Чаще всего это случаи, где текст перемежается с бинарными
> данными - типичный пример HTTP.
Ну если для тебя, Дима гипертекст это "бинарные данные", тогда спорить не буду. Осталось только спросить у автора вопроса что он имел в виду под "бинарными данными".
DVM (2011-11-14 23:51:00) [20]Бинарные данные сплошь и рядом регулярными выражениями обрабатываются.
Чаще всего это случаи, где текст перемежается с бинарными данными - типичный пример HTTP.
| |
Страницы: 