Добрый день,

часто появляется желание на постоянной основе парсить сайты с разными рынками .
Типовой сценарий — получить список предложений по рынку невижимости.
Пройти весь список и сохранить в БД каждый объект недвижимости и все что к нему относится — параметры квартиры, фотки, коменты и пр.
Чтобы в БД всегда была полная история рынка с момента запуска парсера.
Далее это предполагается анализировать в разных разрезах.
Раньше писал свой парсер, который обходил нужный сайт и парсил (xpath, css selectors) все, что требуется в БД,
но много времени уходит на его поддержку, подозреваю, что должно быть проще решение,
однако, многочасовое гугление не привело к готовому решению.
Уточню требования:
1. крутится в отдельном процессе, который стартует автоматом
2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин)
3. многопоточный
4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них)

Работать с API, даже если оно есть, часто не вариант.

Если единственный вариант писать свое, то на каком языке и с какими библиотеками это проще/надежнее?

С уважением,
Алексей.

Здравствуйте, Keith, Вы писали:

K> Уточню требования:
K> 1. крутится в отдельном процессе, который стартует автоматом
K> 2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин)
K> 3. многопоточный
Посмотрите Selenium. Он чаще всего упоминается в контексте тестирования, но для вашей задачи тоже сгодится.

K> 4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них)
Мышкой вряд ли. Пример кода на Java (есть поддержка других языков)
http://www.qaautomation.net/?p=263

B>Здравствуйте, Keith, Вы писали:

K>> Уточню требования:
K>> 1. крутится в отдельном процессе, который стартует автоматом
K>> 2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин)
K>> 3. многопоточный
B>Посмотрите Selenium. Он чаще всего упоминается в контексте тестирования, но для вашей задачи тоже сгодится.

Selenium тяжеловесен — каждый поток выполнения создает отдельный процесс c браузером.
Проще UI-компонент "Web browser" в нативном приложении без отрисовки UI — там не будет такого расхода оперативки.
Подозреваю, что их и в пул можно будет засунуть.
Selenium Grid, на сколько я понимаю, тоже не решает проблемы в случае с 1 виртуалкой за $5 (2 уже перебор).

K>> 4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них)
B>Мышкой вряд ли.

Почему? У Selenium IDE есть возможность записывать действия мыши и клавиатуры.
Работает хорошо, если контролы стандартные.
Видел успешные примеры с генерацией rss для новостных сайтов, у которых нет rss.

K> Selenium тяжеловесен — каждый поток выполнения создает отдельный процесс c браузером.
Есть phantomjs, тоже процесс с браузером, но у браузера отвал башки (headless), потому полегче.

Здравствуйте, hi_octane, Вы писали:

K>> Selenium тяжеловесен — каждый поток выполнения создает отдельный процесс c браузером.
_>Есть phantomjs, тоже процесс с браузером, но у браузера отвал башки (headless), потому полегче.

Спасибо, нашел и у Selenium headess драйвер:
http://www.seleniumhq.org/docs/03_webdriver.jsp#htmlunit-driver

Здравствуйте, Keith, Вы писали:

K> Почему? У Selenium IDE есть возможность записывать действия мыши и клавиатуры.
Не знал, т.к. почти с ним не работал. Спасибо!

Здравствуйте, Keith, Вы писали:

K> Работать с API, даже если оно есть, часто не вариант.

А работать мимо API — часто забанят. Не ты один такой умный.

K>> Работать с API, даже если оно есть, часто не вариант.
Ops>А работать мимо API — часто забанят. Не ты один такой умный.

Я уже этим занимался и менял хэдеры, делал запросы через прокси и ограничивал частоту запросов.
Браузер с javascript'ом никак не отличить от пользователя, если приложить немного усилий.
API часто нет вообще.

Здравствуйте, Keith, Вы писали:

K>Добрый день,

K> Работать с API, даже если оно есть, часто не вариант.

K> Если единственный вариант писать свое, то на каком языке и с какими библиотеками это проще/надежнее?

K>С уважением,
K>Алексей.

У меня уже заказов 20 было на фрилансе, именно на такую тему Если речь идет про .NET, то использовал вот что:
— WebBrowser — рабочее решение из коробки. Хорошо работает в WinForms, немного кастрированно в WPF, но для парсинга хватит. Из недостатков — это обертка для IE7, со всеми вытекающими. Есть варианты в реестре прописать, что это IE8,9,10, но эффекта по функциональности это не прибавляло.
— CEFSharp — Chromium движок, не столько для парсинга пригодился, сколько для расширенных фич, которые WebBrowser не умеет. В моем случае это был стриминг видео и аудио по ссылке.
— Плагин для Internet Explorer (BHO) — тоже добротно работает, и если мы пишем плагин например под IE10, то будем иметь возможностей побольше чем у WebBrowser. Ну и такие сайты как Facebook например, его с удовольствием встречают, а вот WebBrowser — нет, ибо устарел.
— WatiN — по задумке должен быть там, где нужен Web Test Automation. Но можно приспособить для парсинга и бегания по сайту. Сам в продакшене не использовал
— HTML Agility Pack — просто парсер без js


Если речь идет про С++:
— То опять же BHO под Internet Explorer на нем заводится через COM

Если про Python, мопед не мой, но мне под заказ писали и там такие импорты:

import requests
import logging
import os
import time
import argparse
import pickle
import pprint
import traceback
import json

А еще есть UBot, в котором мышкой наклацать можно воркфлоу, но я бы не рекомендовал как универсальное решение.

	Последний вариант
	А на Upwork'e такие задачи стоят в районе 50-200$ в зависимости от сложности.

Здравствуйте, Keith, Вы писали:

K> Раньше писал свой парсер, который обходил нужный сайт и парсил (xpath, css selectors) все, что требуется в БД,
K> но много времени уходит на его поддержку

Какая конкретно "поддержка"? Обновить XPath под новый дизайн?

K> подозреваю, что должно быть проще решение,

На основе чего появились такие подозрения?

K> однако, многочасовое гугление не привело к готовому решению.

Потому что подозрения — безосновательные, чисто "мне лень так делать".

K> Уточню требования:
K> 2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин)
K> 4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них)

Ха! Ну ты замахнулся на Шекспира.... От такого бы даже сам гугл не отказался, но увы — не может по причине нереальности задачи. Сам не чувствуешь, что сложность задачи граничит с глупостью? Мало того, что жабоскрипт, да ещё клики.
Если парсеру дают хотя бы статический HTML, который можно распарсить — уже счастье!

K>Какая конкретно "поддержка"? Обновить XPath под новый дизайн?

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

K>> подозреваю, что должно быть проще решение,
K>На основе чего появились такие подозрения?

На основе виденных мною инструментов схожей функциональности.

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

Конечно мне лень делать работу, которую можно не делать.

K>> Уточню требования:
K>> 2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин)
K>> 4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них)
K>Ха! Ну ты замахнулся на Шекспира....

Неужели так же красиво рифмую?

>От такого бы даже сам гугл не отказался, но увы — не может по причине нереальности задачи.

Вообще, я уже нашел мышко-кликательное решение — там xpath генерируется автоматом при выборе мышкой.
Однако я еще не все осмотрел из найденного, возможно, найду получше реализации...

>Сам не чувствуешь, что сложность задачи граничит с глупостью? Мало того, что жабоскрипт, да ещё клики.

Прошу прощения, Вы эксперт в этой области?
С удовольствием бы купил у вас часовую консультацию на эту тему за $200.

K>Если парсеру дают хотя бы статический HTML, который можно распарсить — уже счастье!

Видимо, я ошибся, поищите больше информации на эту тему, чтобы предметнее вести разговор.

Здравствуйте, Keith, Вы писали:

K> Если единственный вариант писать свое, то на каком языке и с какими библиотеками это проще/надежнее?

nodejs + jquery + jsdom

Все современные сайты заточены под CSS и jquery, так что тем же jquery они парсятся элементарно. Плюс легендарная надежность и асинхронность node.js

L>У меня уже заказов 20 было на фрилансе, именно на такую тему Если речь идет про .NET, то использовал вот что:
L>- WebBrowser — рабочее решение из коробки. Хорошо работает в WinForms, немного кастрированно в WPF, но для парсинга хватит. Из недостатков — это обертка для IE7, со всеми вытекающими. Есть варианты в реестре прописать, что это IE8,9,10, но эффекта по функциональности это не прибавляло.
L>- WatiN — по задумке должен быть там, где нужен Web Test Automation. Но можно приспособить для парсинга и бегания по сайту. Сам в продакшене не использовал
L>- HTML Agility Pack — просто парсер без js

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

L>Если про Python, мопед не мой, но мне под заказ писали и там такие импорты:

Для питона есть BeautifulSoup + стандартный способ делать http-запросы.
Ну и Selenium так же есть.

L>А еще есть UBot, в котором мышкой наклацать можно воркфлоу, но я бы не рекомендовал как универсальное решение.

Это уже ближе к тому, что я хотел бы, только дорого.
А почему не рекомендуете?
Кроме того, что это зависимость от вендора.

L>А на Upwork'e такие задачи стоят в районе 50-200$ в зависимости от сложности.

И часто такие задачи попадаются? Конкуренция высокая?

P>nodejs + jquery + jsdom

jsdom выглядит как интересная замена phantomjs'у.
А есть какие-нибудь преимущества у node в парсинге, которых нет, скажем, у java/python/ruby?

>Плюс легендарная надежность и асинхронность node.js

Еще бы синхронность была, вообще цены не было )
А вообще, многие жалуются на утечки.

Здравствуйте, Keith, Вы писали:

K> А есть какие-нибудь преимущества у node в парсинге, которых нет, скажем, у java/python/ruby?

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

K> Еще бы синхронность была, вообще цены не было )

Открой для себя async.js и забудь про синхронность как страшный сон.

K> А вообще, многие жалуются на утечки.

Нет там никаких утечек. У нас есть скрипты на ноде, у которых аптайм измеряется годами.

K>> А есть какие-нибудь преимущества у node в парсинге, которых нет, скажем, у java/python/ruby?
P>Нативный JS, скажем можно выполнить JS приехавший с сайта, поймать какой-нибудь промежуточный объект и извлечь из него данные.

А чем это отличается от других платформ?
Там тоже можно сделать http-запрос и десериализовать json в объекты языка.

K>> Еще бы синхронность была, вообще цены не было )
P>Открой для себя async.js и забудь про синхронность как страшный сон.

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

K>> А вообще, многие жалуются на утечки.
P>Нет там никаких утечек. У нас есть скрипты на ноде, у которых аптайм измеряется годами.

Скрипты, наверерное, простые?
Но, вообще, это не важно.
Я готов его опробовать, если будет того стоить.

Здравствуйте, Keith, Вы писали:

K> А чем это отличается от других платформ?
K> Там тоже можно сделать http-запрос и десериализовать json в объекты языка.

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

K> Но все равно оборачивать каждый раз вызовы в синхронные неудобно, когда для UI в основном надо
K> блокировать интерфейс между действиями.

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

K>> А чем это отличается от других платформ?
K>> Там тоже можно сделать http-запрос и десериализовать json в объекты языка.
P>В других платформах ты не можешь запускать приехавший с сервера код.

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

K>> Но все равно оборачивать каждый раз вызовы в синхронные неудобно, когда для UI в основном надо
K>> блокировать интерфейс между действиями.
P>Не нужно. Для UI нужно показать песочные часы, сделать запрос и повесить коллбек в котором спрятать песочный часы и показать результат.
P>В асинхронном варианте это делается прощей чем в синхронном.

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

 progress.Start();
 uicomponent.data = domainService.GetByIds(ids);
 progress.Stop();

P>Плюс асинхронной реализации в том что ты можешь показать песочные часы только в том месте индерфейса которое связано с запросом, а весь остальной может продолжать работать пераллельно.

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

Трогай за PhantomJS
Полный эмулятор браузера вместе с жабаскриптом, который могёт работать сам, в консоли, совсем буз гуя.

S>Трогай за PhantomJS
S>Полный эмулятор браузера вместе с жабаскриптом, который могёт работать сам, в консоли, совсем буз гуя.

А есть какое-нибудь преимущество node.js + phantomjs перед selenium'ом или
движком браузера на другой платформе (java, python, ruby)?
У Вас есть опыт разработки парсеров?