Про парсеры подробнее...

[dacuan]

Вот именно путем сравнения и всевозможных замеров времени и сьедаемой памяти я и пришел к такому выводу.

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

 

[Virtual]

Классно, что ты провел такое исследование. Хотелось бы еще тебя попросить протестировать регулярки на Perl - мне что то кажется, что регулярки перловые должны быстрее работать, не скажу почему - но кажется
Предлагаю провести подробное тестирование.
Для этого прошу выложить код твоих тестов сюда, на какой-нибудь файло-обменник или мне в личку. Я со своей стороны перепишу версию регексповую на перл и проверим скорость работы в комплексе.
Думаю эта тема будет интересна всем.

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

По поводу выложить код - сорри, не получится. %) т.к. над парсером я карпел в мае, и все остальные варианты были убиты, как совершенно не подходящие к требованиям. Текущую версию выкладывать - тоже смысла нет, т.к. на весь парсер используется порядка 3-4х регулярок.. парсер - sax. Без всей остальной логики от него толку ноль, саму логику выкладывать не буду, т.к. ее там реально дофига, и я нигде не видел обсуждений подобной логики... эдакое закрытое, приватное ноу-хау..

Добавлено через 7 минут

что ты вкладываешь в понятие простейших регулярок?

/(.*?)(?:[\s]|(>)|$)/si - например такая. на мой взгляд - простейшая регулярка. а вообще - как было замечено выше - стрпос с кучей логики реально будет медленнее, поэтому он заменяется на простейшую регулярку. к примеру, найти значение атрибута тега. если делать стрпос - то в любом случае, надо делать какой-нить цикл, и по нахождении позиции скажем кавычки - просматривать предыдущий символ, или даже несколько предыдущих. с такими вещами - отлично справляются простые регулярки, причем, не прег_мач_олл, а прег_мач, и искользовать их в том случае, когда точно знаешь, что она сработает скажем в ближайших 50-100 символах. чтоб не лопатить весь огромный документ.. т.е. половина стрпосов для которых надо прикручивать доп. логику в зависимости от пред. и след. символов - использовал простые регулярки, которые однозначно сработают 1 раз, пройдя минимум символов по тексту...

 

[Virtual]

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

Я не спорю. И вообще, не претендую на конечную инстанцию в данном вопросе. И, совсем не могу сказать что я в регулярках гуру. Но, для себя, я сделал такой вывод... да и парсеров было написано на самом деле не мало, за последний год-полтора.. в итоге, практически везде удавалось добиться повышения производительности уменьшением регулярок.. а в связи с новыми версиями pcre - вообще запарился. т.к. работает в пхп4, и не работает в пхп5..

ПС. Регулярки таки зло. но, не всегда есть возможность совсем от них избавиться. Я никому не навязываю свое мнение. Озвучил выводы, сделанные самим для себя. Т.к. буквально год-полтора назад, был ярым фанатом регулярок, и пихал их везде где только можно... а уже потом посмотрел на проблему с другой стороны, и выяснилось, что не такие уж они и классные, регулярки эти..

 

[Ahmady]

Плиз помогите на конкретном примере.

сл. выражение берет все от начала ссылки до закрывающего тега:
<a*?\s?+href=[^>]+>.*<\/a.*?>

Но вместе с сылками захватываются и картинки.
Как исключить ссылки, содержащие картинки?

 

[dacuan]

Ahmady
Самое простое -- постобработка

 

[Ahmady]

Если можно пример дайте.

Добавлено через 34 минуты
Точнее с тэгами разобрался, но не могу догнать как работать с текстом внутри тэгов

Например есть
<a href="http://www.softosmotr.com/images/stories/rss_news/6fed0a24580bdeaaa6c042cba1efef17.jpg" target="_blank">

Как показать,что строку надо пропустить по причине *.jpg ?

Добавлено через 36 минут
Пробывал вот так
/(<a*?\s?+href=[^>]+?!jpg.*?>.*<\/a.*?>)/si
но оказался неправ

 

[nnmkayf]

Вот тебе пример работающего парсера, для этого сайта, использующего принцип пост-обработки. Предполагается, что страница лежит в файле a.txt

$fh = fopen('a.txt','r');
while ($string = fgets($fh,8192))
{
    if (preg_match("/\<a[\s\r\n\t][^>]*HREF[\s]?\=[\s'\"]?([^\"'>#\s]+).*?\>(.*?)\<\/a\>/i",$string,$match))
    {
        if (!strstr($match[2],'img') && !strstr($match[1],'javascript'))
        {
            echo "Сылка: ". $match[1]."\n";
            echo "Название: ". $match[2]."\n";
        }
    }
}
fclose($fh);

 

[Ahmady]

Мне надо не парсер.
Мне надо В эту сроку <a*?\s?+href=[^>]+>.*<\/a.*?>
прописать "НЕ JPG" и все.
Поясню: Для того чтобы окружить тэгами не JPG-ссылки.
(img не предлагать)

 

[HappyWorld]

Для того чтобы окружить тэгами не JPG-ссылки.

Сначало ответь на вопрос, что такое "не JPG-ссылки", и как отличить ссылки от "не JPG-ссылки". После этого решение само придет.

 

[nnmkayf]

Мне надо не парсер.
Мне надо В эту сроку <a*?\s?+href=[^>]+>.*<\/a.*?>
прописать "НЕ JPG" и все.
Поясню: Для того чтобы окружить тэгами не JPG-ссылки.
(img не предлагать)

твой регексп приведенные тобой же примеры не матчит.
в моем варианте если заменить img на .jpg ты как раз найдешь все ссылки в том числе картинки не jpg.
А суть процесса окружать тегами не jpg ссылки, осталась покрыта для меня тайной, приведи плиз наглядный пример того, что ты хочешь получить.
если тебе нужен не прасер, зачем в топик про парсеры вопрос задавать?