Regexp в бинарниках

← →
DmitriyG. © (2011-11-06 14:44) [0]

Посоветуйте библиотеку позволяющую искать регулярные выражения в бинарных данных

← →
Медвежонок Пятачок © (2011-11-08 07:53) [1]

http://RegExpStudio.com

← →
DmitriyG. © (2011-11-11 23:24) [2]

Так она же вроды бы только в строках ищет... Или я не все увидел?

← →
Германн © (2011-11-11 23:45) [3]

> регулярные выражения в бинарных данных

Эээ а это как? Какие в бинарных данных могут быть "регулярные выражения"?

← →
DiamondShark © (2011-11-12 00:04) [4]

> Германн © (11.11.11 23:45) [3]

Точно такие же, как в тексте.
Ваш К.О.

← →
Германн © (2011-11-12 00:19) [5]

> Точно такие же, как в тексте.

Можно "пример для дурака"?

← →
Германн © (2011-11-12 00:24) [6]

> Можно "пример для дурака"?

Но пример должен иметь реальный смысл.

← →
DiamondShark © (2011-11-12 00:55) [7]

> Германн © (12.11.11 00:19) [5]
> Можно "пример для дурака"?

Нельзя. Дурака учить -- как мёртвого лечить.

Для не-дурака -- любая формальная спецификация формата.

← →
Германн © (2011-11-12 04:10) [8]

>
> > Германн © (12.11.11 00:19) [5]
> > Можно "пример для дурака"?
>
> Нельзя. Дурака учить -- как мёртвого лечить.
>
> Для не-дурака -- любая формальная спецификация формата.

Ну да. Как мы любим бросаться умными терминами типа "спецификация формата". :)
А пример-то где, Дима?

← →
Медвежонок Пятачок © (2011-11-12 11:35) [9]

Так она же вроды бы только в строках ищет... Или я не все увидел?

Ищет в строках, в которых может лежать двоичка.

← →
Медвежонок Пятачок © (2011-11-12 12:01) [10]

А пример-то где, Дима?

На тебе пример (практический)

Атс авайя. Управляется и диагностируется по телнет.
Есть много таких атс в сети.
Поочередно соединяемся с ними и посылаем им команды ответы на которые надо парсить.
Например надо вырезать все управляющие эскейп-последовательности в ответах. И там полно двоички.

← →
sniknik © (2011-11-12 14:28) [11]

> эскейп-последовательности в ответах
насколько помню эскейп-последовательность в бинарном виде это начинающаяся с кода 27, т.е. в дельфи представлении #27.
ну вот, тоже бы, ради интереса, хотел бы посмотреть на регексп который "выкусывает" бинарные последовательности типа - #27#1#2, #27#1#3, ... (не строки как тут написано, а то что эта строка значит в бинарном пакете).

p.s. мне это не нужно, не пользуюсь... но интересно. а вдруг понадобится...

← →
DmitriyG. © (2011-11-14 00:25) [12]

Ну с эти проблем не должно быть: "\u0027\u0001\u0002"
Но вот если в данных будет символ с кодом 0, то на этом разбор остановиться...

← →
sniknik © (2011-11-14 00:39) [13]

> Ну с эти проблем не должно быть: "\u0027\u0001\u0002"
нет проблем, да, кроме того, что ищет символ "u", а не #27.

← →
Германн © (2011-11-14 01:06) [14]

> Медвежонок Пятачок © (12.11.11 12:01) [10]
>
> А пример-то где, Дима?
>
> На тебе пример (практический)
>
> Атс авайя. Управляется и диагностируется по телнет.
> Есть много таких атс в сети.
> Поочередно соединяемся с ними и посылаем им команды ответы
> на которые надо парсить.
> Например надо вырезать все управляющие эскейп-последовательности
> в ответах.

Извини, МП, но это не пример! Это чушь и бред!
Это частный случай поиска ESC-последовательностей в некоторых данных. При чём тут "RegExp для бинарных данных"?

← →
Медвежонок Пятачок © (2011-11-14 08:39) [15]

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

← →
Германн © (2011-11-14 08:50) [16]

> Медвежонок Пятачок © (14.11.11 08:39) [15]
>
> При том, что
> ... позволяющую искать регулярные выражения в бинарных данных

Ну где же тут "регулярные выражения"?

← →
sniknik © (2011-11-14 09:24) [17]

прежде чем их искать, их нужно настроить... а настройка в тексте, и в описаниях применяется к тексту и вообще, из википедии -
Regexp - это формальный язык поиска и осуществления манипуляций с подстроками в тексте.

← →
Медвежонок Пятачок © (2011-11-14 10:15) [18]

Ну где же тут "регулярные выражения"?

Тут - это где?

прежде чем их искать, их нужно настроить...

Жаль, что я этого не знал. Я просто искал и успешно находил.
Вот жеж жопа.

← →
sniknik © (2011-11-14 11:07) [19]

> Я просто искал и успешно находил.
ну так покажи саму регулярку на - sniknik © (12.11.11 14:28) [11]
или ты искал строки в строках, перемежающихся бинарными данными (все условно, и это тоже строка, пока нет #0).

← →
Медвежонок Пятачок © (2011-11-14 11:32) [20]

В чем гиганская мегапроблема-то?

нуль я регулярками найду? найду.
засплиттить по нулю и обработать по частям могу? могу.

по хекс коду регулярка сработает? Сработает.

В чем у вас проблемы-то?
В том что Пятачок в ветке или в чем?

← →
DVM © (2011-11-14 23:51) [21]

Бинарные данные сплошь и рядом регулярными выражениями обрабатываются.
Чаще всего это случаи, где текст перемежается с бинарными данными - типичный пример HTTP.

← →
Германн © (2011-11-15 00:21) [22]

> Бинарные данные сплошь и рядом регулярными выражениями обрабатываются.
>
> Чаще всего это случаи, где текст перемежается с бинарными
> данными - типичный пример HTTP.

Ну если для тебя, Дима гипертекст это "бинарные данные", тогда спорить не буду. Осталось только спросить у автора вопроса что он имел в виду под "бинарными данными".

← →
Германн © (2011-11-15 01:40) [23]

> В чем у вас проблемы-то?
> В том что Пятачок в ветке или в чем?

У нас-то проблем нет.
Только зачем усложнять "некими регулярками" поиск по "бинарньм данным"?

← →
Медвежонок Пятачок © (2011-11-15 08:44) [24]

Только зачем усложнять

Усложнять не надо, надо упрощать.
Что регулярки с успехом и делают.

← →
han_malign (2011-11-15 10:11) [25]

> нет проблем, да, кроме того, что ищет символ "u", а не #27.

- /\x1B\x01(\x02|\x03)/
\u - это символ в верхнем регистре...

> Но вот если в данных будет символ с кодом 0, то на этом разбор остановиться...

- кто вам сказал такую глупость - и TRegExpr, и PCRE - принимают на вход строку с длиной... И \Z - указывает на позицию соответствующую указанной длине, а не на первый #0.
А EOT это - если что - ^Z(#$1A), а не #0...

← →
sniknik © (2011-11-15 12:03) [26]

> - /\x1B\x01(\x02|\x03)/
о, а вот это работает, как ожидается... получатся, действительно, ограничений нет.

← →
DVM © (2011-11-15 18:25) [27]

> Германн © (15.11.11 00:21) [22]

> Ну если для тебя, Дима гипертекст это "бинарные данные",
> тогда спорить не буду.

Не путай HTTP и HTML. Гипертекст = HTML. HTTP - текстово-бинарный протокол.

В ответе HTTP сервера может быть текстовый заголовок, а следом могут идти бинарные данные, например, картинка. Если тип контента multipart/x-mixed replace то следом за бинарными данными может идти опять текстовый подзаголовок и потом опять бинарные.

← →
Германн © (2011-11-16 00:38) [28]

> Не путай HTTP и HTML

Да не путаю я HTTP и HTML! :)
Это вы путаете "бинарные данные" со всем тем, что вам родно и близко. :(

> Германн © (16.11.11 00:38) [28]

> Это вы путаете "бинарные данные" со всем тем, что вам родно
> и близко. :(

Ты хочешь сказать, что в HTTP бинарных данных нет?

> Ты хочешь сказать, что в HTTP бинарных данных нет?

Я хочу

> Осталось только спросить у автора вопроса что он имел в
> виду под "бинарными данными".

понеслась душа в рай.....

> DVM (16.11.2011 10:40:29) [29]

Возьми в кавычки

> Германн © (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 вводит некоторых в заблуждение. Он передает гипертекст, а не текст, гипертекст - это не только текст, а еще и картинки, файлы и прочее.

> Германн © (16.11.11 11:43) [30]

> Я хочу
>
> > Осталось только спросить у автора вопроса что он имел
> в
> > виду под "бинарными данными".

Да понятно, что он имел в виду. Буфер в памяти он имел в виду. Не строку, а произвольный буфер. Многие библиотеки для работы с регулярными выражениями позволяют работать с такими данными. Но не далеко не все.

> Да понятно, что он имел в виду. Буфер в памяти он имел в
> виду. Не строку, а произвольный буфер. Многие библиотеки
> для работы с регулярными выражениями позволяют работать
> с такими данными. Но не далеко не все.

Ну собственно да... Именно была проблема нулевыми символами (после которых поиск должен останавливаться)....

> - кто вам сказал такую глупость - и TRegExpr, и PCRE - принимают
> на вход строку с длиной... И \Z - указывает на позицию соответствующую
> указанной длине, а не на первый #0.А EOT это - если что
> - ^Z(#$1A), а не #0...

Странно, почему то в описании на сайте я функцию вида
ExecRegExpr(RegExpr, Data, DataSize)
пока не увидел... Надо будет завтра на свежую голову посмотреть...

> DmitriyG. © (16.11.11 23:42) [35]
>
>
> > Да понятно, что он имел в виду. Буфер в памяти он имел
> в
> > виду. Не строку, а произвольный буфер. Многие библиотеки
> > для работы с регулярными выражениями позволяют работать
> > с такими данными. Но не далеко не все.
>
>
> Ну собственно да... Именно была проблема нулевыми символами
> (после которых поиск должен останавливаться)

Вот и разберись тут "Кто прав? Кто неправ?" (с) Пиф-Паф
:)

← →
han_malign (2011-11-17 09:13) [37]

> Странно, почему то в описании на сайте я функцию вида
> ExecRegExpr(RegExpr, Data, DataSize)
> пока не увидел... Надо будет завтра на свежую голову посмотреть...

- она не нужна, т.к. (Ansi/Byte)String - и так "бинарный" буфер с длиной...

Но TRegExpr(Andrey V. Sorokin - v0.952) - действительно обрубится по нулю - хотя буфер и выделяется по длине строки - дальше везде прописано терминирование по #0...

Так что единственный(известный мне) нормальный - PCRE(но там придется С - прослойку делать, либо BC++ -> obj -> {$LINK ...}, либо DLL)...
(Хотя наверняка кто-то TRegExpr допиливал, там делов на пол-дня)

ОК... Спасибо за подсказку - PCRE + dll это то что нужно... И функция похожа на требуемую...

А по поводу передачи String внтури которого #0 - боюсь нужно будет устраивать некоторые танцы с бубном чтобы длина была "реальная", а не там где #0 :-)
Да и тем поболее, что все равно потом TRegExp только до #0 смотрит...

Допилить можно было бы - но это только если чем-то не устроит PCRE...

← →
han_malign (2011-11-18 09:05) [39]

> если чем-то не устроит 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 stack for pcre_exec()

..........

Limiting pcre_exec()"s stack usage

..........

- и не забывать, что каждый подшаблон /(...)/ требует места в векторе результатов поиска - но можно задавать подшаблон результат которого в вектор не кладется - /(?:...)/...

Если честно пока это не принципиально. Главное чтобы поиск производился в памяти указанного размера...

Regexp в бинарниках Найти похожие ветки