Функции парсинга веб страниц.

[kasus]

К этому добавить парсер гугла и можно крутой сплог сделать типа vipbablo ))

 

[lobzik]

Ужасный код у ТС. Про не уверсальные регэкспы уже сказали...

А вот зачем писать столько ненужных функций?

// получение всех h4 tags  
function get_h4($file){  
    $h1tags = preg_match_all("/(<h4.*>)(\w.*)(<\/h4>)/ismU",$file,$patterns);  < cut. >
}

если можно

// получение любого тега
function get_tag($file, $tag){  
    $h1tags = preg_match_all("/(<".$tag".*>)(\w.*)(<\/".$tag.">)/ismU",$file,$patterns);  
}

 

[Alternator]

Ребята.
А чем вам не подходят стандартные функции предназначенные для парсинга (X)HTML и XML-документов
Лично я использую DOM,который способен парсить HTML, и горя не знаю
помимо него в PHP есть Tidy предназначенный как раз для HTML-а
Остальные наборы функций вроде как предназначены только для XML, но и этих двух инструментов должно хватить.
И не надо говорить, что они медленные или не работают.
да, они медленнее RegExp-ов, но они гораздо универсальней.
вам не надо думать об положении атрибутов при формировании регулярки(о чем тут упоминулось), и еще много о чем. этот инструмент заточен именно под парсинг HTML-страниц.
по скорости же, еще ни на одном из моих проектов скорость парсинга не была медленее, чем работа с сетью.
среди моих проектов встречались и парсеры работающие в 100 потоков с фдовлетворительной скоростью.
Описание упомянутых мною библиотек естественно можно найти в оф-документации(надеюсь в Pro-разделе это очевидно, но на всякий случай)

 

[lorien]

> И не надо говорить, что они медленные или не работают.
> да, они медленнее RegExp-ов, но они гораздо универсальней.

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

 

[Alternator]

> И не надо говорить, что они медленные или не работают.
> да, они медленнее RegExp-ов, но они гораздо универсальней.

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

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

после 7 более-менее крупных выборок(ссылки, ID-шники,картинки) DOM уже быстрее чем регулярки. дальше DOM становится значительно лучше

при парсинге более-менее сложных страниц с кучей разномастных данных, которые надо выделить DOM выходит лучше. если же нам надо просто выдрать текст из одного тега, либо найти e-mail-ы, то регулярки лучше

при парсинге 100к страниц выигрыш регулярок на самой выигрышной для них комбинации составит порядка 1-2часов(речь идет о чистом парсинге, без учета скачивания файлов и прочего)

в свою очередь , ИМХО, XPath+DOM гораздо быстрее в отладке и анализе, не говоря уже о сравнительной простоте составления XPath выражений по сравнению с регулярками, и их большей семантической гибкости.
Попробуйте составить десяток регулярок, в которых будет анализироватся вложенность тегов, дополнительные атрибуты, и всякое прочее.вы задолбаетесь сотавлять эту регулярку, а выглядеть она будет просто ужасно, изанимать пару строк кода, и просто будет неизменяема, при таковой необходимсоти

 

[lorien]

Если надо что-то мегасложное, то я готов пожертвовать скоростью и юзать DOM-генераторы, но вот, скажем, выцепление форм я сделал без особого труда с помощью регулярных выражений. И работало это намного быстрые, чем BeautifulSoup или libtidy + ElementTree. Это я на python делал.

Пример такого парсера:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

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

 

[Alternator]

честно не совсем понимаю о какой разнице в скорости говорится.
да, формально на простейших обработках регулярки быстрее.
но насколько?!
раза в два, а то и меньше, что в пересчете на парсинг 100к документов составляет пару часов.
мягко говоря экономия на спичках, потому что время скачивания 100к документов через прокси будет гораздо выше(не менее 24 часов, в зависимости от ресурса и качества проксь.это в идеале).
не вижу разницы, подождать 26 или 28 часов.

смысл этой экономии может быть только если вы "на лету" воруете чужой контент, и вам надо быстро выдать контент своему пользователю

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

 

[lorien]

> не думаю, что вы начнете писать парсеры на DOM-е из-за моих доводов
Что за домыслы странные? В основном я DOM и использую

 

[Alternator]

странно.
просто по тому, как вы отстаиваете право на жизнь регулярок в парсинге HTML-а, я решил, что вы только их и используете

 

[lorien]

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