Для lenta.ru помимо парсера статей дописаны модули парсинга новостей, авто-новостей, медицинских-новостей (в работе недвижимость и пресс-релизы) — хоть это парсеры практически разных порталов — все  парсеры входят в стоимость одного комплекта !!!

Покупателям парсера какого либо из 3х вышеуказанных сайтов — полная база и RSS парсер в подарок.

ВНИМАНИЕ !!! AHTUNG !!! АКЦИЯ !!! ДЕЙПИНГОВЫЕ ЦЕНЫ !!!

Стоимость одного комплекта — 15$
Желающим купить 2 парсера — 3й в подарок !
То есть все 3 комплекта — всего 30$ !

Отдельно текущая актуальная база — 5$
При покупке 2х баз — третья в подарок !
То есть все 3 базы — всего 10$ !

P.S.

База Articlesbase.com по причине ОГРОМНОГО количества статей — еще в процессе

ReTweet

Если кому нужно — уступлю за по 10 WMZ за каждый.

P.S.
Вышел свеженький номер seodigest — Новый дизайн и верстка мне особенно понравились ! Ну а материал там всегда интересен.

Обсуждение баз статей на форуме

ReTweet

У кого самые большие базы данных по онлайн информации ? — Правильно — у поисковиков ! Желая зарабатывать в онлайне денежки имхо просто необходимо уметь необходимую информацию вытягивать и этих баз ...

Итак — что такое поисковик надеюсь все знают, соответственно начнем с того, что поднимем вопрос — такое парсинг и для чего он нужен ?

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

Как правило парсеры применяются для поиска определенных ресурсов, либо определенного контента. Например поиск баз для спама — гостевых книг, форумов, блогов, адресов email,  поиск тематических статей для дальшейшего репостинга и реврайта.

Итак — что же тут такого, эдакого ?

А то, что для того, чтоб достичь поставленные результаты — т.е. напарсить максимально большое количество материала, просто необходимо владеть языком запросов той поисковой машины, которую парсим. Информации в сети довольно много и для начала я бы посоветовал проанализировать выдачу по соответствующим запросам «Язык запросов» Яндекса и Гугла.

По Яндексу, в принципе достаточно и встроенного описания языка запросов

А вот гугловское описание очень урезанное ... может в гугле и есть полное, но с лёту не нашел. Поэтому вот, что больше всего понравилось мне:

Компактное описание Google

Аdvanced operators reference

Заметки для простого поиска

Теперь чуток подробнее в режиме рассуждений на примере парсинга Гугла — допустим собиваем ссылочные базы гостевых книг и форумов:

Для начала конечно же необходимо подробно изучить как можно больше «кандидатов» — т.е. работающих примеров на разных движках.  (По умолчанию считаю, что Язык запросов , что уже изучен.)

* особенности URL-ов для регистрации, постинга и других специфических страничек (наличие в ссылке кеев guestbook, forum и пр.)

* особенности заполнения тайтла  (ключевые слова Форум, Гостевая книга и пр.)

* наличие на страничке определенного специфического текста, соответствующего данному движку (powered by phpbb, и пр.)

* наличие в анкорах на страничке определенного специфического текста (как правило тоже связано с используемым движком)

Далее столкнувшись с весьма неприятным ограничением по максимальному количеству отдаваемых страниц выдачи, напрягаем извилины в сторону «дробления» полученных результатов (неоходимо когда поисковик говорит, что результатов найдено дикие миллионы, а дает выдернуть только тыщу).

А в «дроблении» нам как раз очень поможет язык запросов !

* ну во первых неплохо бы исключить «дохлые» ресурсы добавляем в запрос -error -warning и т.п.

* дробим по доменным зонам и доменам site:ru site:com ...

* при запросах а-ля inurl:forum без использвания intitle можно дробить как раз по intitle:"a b" intitle:"aba" (тупо перебирая разные варианты)

* вообще можно в любые текстовые запросы добавлять перебор вариантов, напр. sign the guestbook «g», sign the guestbook «h» и т.д.

* в найденном по текстовым, либо тайтловым запросам можно включать либо исключать по типам урлов Напр. -inurl:"html" +inurl:"html" и т.д.

* для поиска в диапазоне используем цифровые операторы напр. page=#1:30#, так же можно и перебором page=1, page=2 и т.д. (где потребуется)

Маленькие хитрости

* конкретно при парсинге Гугла можно использовать различные дата-центры (это распределит нагрузку и исключит возможность бана одним дата-центром)

* особое внимание уделяем многоязычности при поиске, например гостевая книга в url-ах на разных языках может выглядеть очень по-разному guestbook, guestebook, gaestebuch, gastenboek, gaestebogen, gjestebok и т.д.   сам текст «добавить сообщение» и другие ключевики тоже

* конечно же не забываем о различных сокращениях и использования спец символов guest_b, guest-b, g-book и т.д.

* при парсинге ну допустим сабмит-форм не обязательно ведь выходить сразу на эту форму, возможно есть очень специфические странички которые гораздо легче «вытянуть», расположенные по соседству. Напр.  viewprofile viewtopcomments и прочее...

* отдельно внимание стоит уделить обратному поиску — т.е. зная какими запросами (фарма, казино, порно кейворды) в основном спамят — искать уже эти ресурсы.  Непосредственно найденные ресурсы использовать не рекомендую — т.к. уже заспамленые, а вот найти, что то «новенькое» по типу самого ресурса — и уже искать подобные — весьма полезно.

* желательно распределять запросы так, чтобы с одного IP было не более 1000 в сутки

В общем довольно творческий процесс получается

Напоследок пару слов о парсерах

Вообще лично мне нравился Aura SE Parser 1.1  — долгое время именно его и юзал, но к сожалению разработчик куда то запропал  и проект умер. Парсер написан на перле, исходный код никак не защищен — поэтому если есть желающие «оживить» софтину — стучите в личку. «Оживление» думаю не должно быть проблематичным — имхо нужно только подкорректировать регулярки да запросы.

Кому интересно ознакомиться поближе — велкам: интерфейс ауры и мануал

(повторяю — парсер в данный момент не парсит)

Добавлено 08.07.09  непосредственно Аура -  CGI и HTTP (perl специалисты — велкам)

Вообще, в идеале, парсер должен уметь следующее:

* Осуществлять многопоточный парсинг

* Работать через прокси (разных типов)

* Исходя из вышеперечисленного, желательно чтоб парсер был серверный (не win32)

* Запросы и регулярки для парсинга должны быть доступны для правки

* Автоматическое дробление при большом количестве найденных результатов

* ВООБЩЕ идеально было бы подключение какого нить сервиса типа анти-капчи — если поисковик усомниться в чистоте ваших намерений и подсунет капчу — вуаля ! и работаем дальше — но подобных фич я еще не видел ... (хотя реализация не сложная)

* Ну и пожелания, как и ко всему Программному обеспечению — хороший мануал, отзывчивый и дружественный саппорт, своевременные обновления (если вдруг формат выдачи поменяется)

кстати у Aura SE Parser мануал — супер, один из лучших которые я когда либо видел — всем бы так !

P.S.

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

ReTweet