Требования к системе… по большому счёту как у jsdom, остальное там по мелочи.
Javascript выполняет. Через evaluate.
Смотря что понимать под "постоянно работающим парсером". Всё, в конечном итоге, сводится к требуемой частоте запросов. Если частота небольшая — можно использовать, если большая — нельзя (как и любой другой hedless). Лично я любые hedless использую только для разовой инициализации сессии, а дальше — честные http-запросы. Обратите внимание, что в этой статье рассматривается только задача получения cookies при запуске скрейпера. Предполагается, что дальше можно будет скрейпить как обычно.
Честно говоря, лучшая инфа, что мне попадалась по этой теме — это те две ссылки, которые kirill3333 привёл в комментариях к этой статье (выше и ниже соответственно). Главное, что стоит знать, на мой взгляд, если разработчик сайта захочет детектировать робота — значит он детектирует и гарантированных способов ему помешать нет. Просто как пример того, насколько далеко можно зайти в этом направлении посмотрите технологии на сайте areyouahuman.com. И это ещё не предел.
Ну, htmlunit — это обычный headless. Как PhantomJS только на Java. Защититься от него можно так же легко/трудно, как от PhantomJS. Вот тут я эту тему немного раскрыл, если что.
Парсинг — это преобразование строки в удобные для программы данные, а веб-скрейпинг — это вытаскивание данных со страниц. Ну, это если грубо.
В первой статье цикла я вроде бы показал как соотносятся парсинг со скрейпингом.
На импортных биржах "parsing" — это когда, например, есть здоровенный файл (или куча файлов) в экзотическом формате и надо из него надёргать данные. А "scraping" там — это когда есть сайт, с которого надо вытащить данные, тем или иным способом, хоть скриптом, хоть копипейстом.
Короче, я понял, проблема есть. Постараюсь сделать статью с терминологией по всей этой области.
В боевых условиях я использую phantomjs только на этапе авторизации, чтобы получить куки, сохранить их и использовать пока не устареют. Я делал скрейпинг адресов ревьюеров из топа. Надо было сделать 10000 запросов. Даже через needle это долго, а уж через hedless — тем более. Добавлял в каждый запрос куки, которые в самом начале были получены из phantomjs, а сами запросы делал с помощью needle. Все 10000 прошли без сбоев с одним набором кук. А вот на этапе тестирования авторизации капча вываливалась после десятка-другого запросов.
В принципе, так и должно быть. 10000 авторизованных запросов для Amazon — ерунда, а вот подозрительная активность при авторизации — это может быть подготовка скрейпинга, а может быть и взлом денежного аккаунта.
Да, когда есть возможность — лучше использовать готовый API, чем страницы скрейпить. Поддерживаю.
Капчи я наблюдал после 10 успешных входов подряд. Через некоторое время опять начинал пускать без капчи. После авторизации с готовыми куками мне капча вообще не попадалась.
Прокси при авторизации тем же аккаунтом, естественно, не помогают, ибо и так понятно, что это тот же юзер :)
Mink — это неплохая штука. Я его не упомянул просто потому что подбирал варианты для Node, а так — да.
Тут можно использовать ORM, да. Но "лучше" — это немного субъективно. Я стараюсь держаться подальше от холивара "ORM vs. raw SQL".
и что это за слово такое «скрейпинг»?
Это слово, которым скрейперы иногда называют скрейпинг :)
Хочется сказать, что "так исторически сложилось", но, на самом деле общепринятого устоявшегося русскоязычного термина для этого понятия пока нет, и скрейпинг иногда как только не называют. Это точно не просто "получение" или "извлекание", а вполне конкретная разновидность получения или извлекания. Термин "scraping" в английском изначально был жаргонным, но прижился (он означает выскребание данных из источников, явно для этого не предназначенных). Может и "скрейпинг" в русском приживётся, но не факт. Пока в сети большая часть общения о скрейпинге идёт на английском, так что проще использовать английский устоявшийся термин (как в случае с "браузером"), а не тратить время на внедрение "правильного" русскоязычного термина.
Если руки дойдут — сделаю статью по терминологии в этой области.
Да, всё верно. Оба решения требуют установки Selenium+JVM. Насколько я понимаю, отдельного npm-пакета, содержащего рабочий Selenium, не существует. Технически было бы правильнее портировать Selenium (и драйверы браузеров) на js, но такого, вроде бы, тоже пока нет.
Обычно клиент заказывает доработку парсера под эти изменения. Это обычный риск и большинство клиентов это понимают. Некоторые сразу оговаривают условия «сопровождения» скрипта.
Вообще, если только структура html поменялась, то это пустяковая проблема, она быстро решается. Вот если сама архитектура бэкенда меняется или защита усиливается — тогда это практически новый заказ. Это большинство клиентов как минимум способны понять, если их заранее предупредить.
Текст таблички заполняют джаваскриптом не просто так, а из какого-то источника. На самом деле не важно как данные отображаются на сайте, важно в каком виде они приходят. Например, джаваскрипт может брать данные для таблицы из XML или JSON запрошенного по Ajax. Ну, или из массива в самом джаваскрипте. Это относительно простые случаи. Бывает и так, что данные приходят в зашифрованном виде. Или передаются по WS. Или ещё как-то по-сложному. Тут уж приходится думать, стоят ли эти данные такой возни.
Капча ломается специальными сервисами. Они платные и не сто процентов угадывают, но они есть. Скрейпинг защищённого капчей сайта — типичный заказ на биржах фриланса.
Адская защита — повод задуматься о легальности скрейпинга именно этого сайта. Но ломается любая защита. Без исключений. Как минимум реверс-инжинирингом скриптов сайта. Бывает так, что скрейпер, специализирующийся на таких сайтах, работает в команде с хакером.
Один из самых действенных способов обхода защиты — написать владельцам сайта и попросить доступ к API или прямо готовые данные. Не всегда помогает, но чаще, чем можно предположить. А уж если не стесняться заплатить, то часто получается дешевле, чем нанимать хакера.
Тут принцип простой: если скрипт на странице может распарсить ответ, пришедший на Ajax-запрос, то в принципе его распарсить можно. Если не DOM-парсером или XPath, так уж регулярками точно. Но иногда приходится подумать, да. Таблицы без классов и ID – это не так уж и сложно по сравнению с тем, что иногда встречается.
Я не останавливаюсь на теме парсинга слишком подробно только потому, что именно этот аспект скрейпинга описан очень подробно во множестве статей по всему вебу. От условного "парсинга для чайников" и до условного "вуду-магия профессионального парсинга". Остальные аспекты скрейпинга описаны далеко не так хорошо. Некоторые начинающие скрейперы даже не знают о существовании других аспектов. Иногда даже называют скрейпинг парсингом. Я стараюсь подобрать примеры с простым парсингом, чтобы сделать акцент на остальных моментах. Конечно, в реальной жизни попадаются сайты, которые парсить очень непросто, тут не поспоришь.
horseman – это просто способ запускать PhantomJS из ноды.
PhantomJS, как и все остальные headless-браузеры, отличается от Scrapy тем, что не просто читает/парсит http-ответы и формирует http-запросы, а выполняет скрипты с сайта. Другой принцип. Свои плюсы, свои минусы.
Совсем подобного нет, насколько я знаю. Платформа ещё молодая, а такие фреймворки быстро не делаются. Можно, конечно, написать скрейпер в стиле Python, не использующий сильные стороны Node.js, но он будет хуже Scrapy. Пока есть несколько сырых проектов, которые рано массово рекомендовать. Одно время подавал надежды node-crawler, но его поддержка прекращена, а замены, которые его автор рекомендует, мягко говоря не очень хороши.
Некоторые скрейперы потихоньку пилят свои фреймворки и однажды у одного-двух из них получится что-то приличное. Так было и со Scrapy, и с Grab.
Ещё есть такой момент, что с каждым годом писать фреймворки для скрейпинга становится всё труднее. Появляется всё больше частных случаев, которые надо учитывать, причём одновременно. И требования у заказчиков всё экзотичнее. Может быть напишу ещё об этом всём поподробнее.
Да, хорошая штука. Для node.js нечто подобное только ещё предстоит написать.
Суть в том, что подобные фреймворки появляются только тогда, когда реальный практик берётся изучать и использовать самые основы, а не выбирает из имеющихся недорешений и костылей к ним. Я на 100% уверен, что lorien умеет скрейпить без фреймворка, просто для него это пройденный этап.
Требования к системе… по большому счёту как у jsdom, остальное там по мелочи.
Javascript выполняет. Через evaluate.
Смотря что понимать под "постоянно работающим парсером". Всё, в конечном итоге, сводится к требуемой частоте запросов. Если частота небольшая — можно использовать, если большая — нельзя (как и любой другой hedless). Лично я любые hedless использую только для разовой инициализации сессии, а дальше — честные http-запросы. Обратите внимание, что в этой статье рассматривается только задача получения cookies при запуске скрейпера. Предполагается, что дальше можно будет скрейпить как обычно.
Честно говоря, лучшая инфа, что мне попадалась по этой теме — это те две ссылки, которые kirill3333 привёл в комментариях к этой статье (выше и ниже соответственно). Главное, что стоит знать, на мой взгляд, если разработчик сайта захочет детектировать робота — значит он детектирует и гарантированных способов ему помешать нет. Просто как пример того, насколько далеко можно зайти в этом направлении посмотрите технологии на сайте areyouahuman.com. И это ещё не предел.
Ну, htmlunit — это обычный headless. Как PhantomJS только на Java. Защититься от него можно так же легко/трудно, как от PhantomJS. Вот тут я эту тему немного раскрыл, если что.
Встречу. Но это не одно и то же.
Парсинг — это преобразование строки в удобные для программы данные, а веб-скрейпинг — это вытаскивание данных со страниц. Ну, это если грубо.
В первой статье цикла я вроде бы показал как соотносятся парсинг со скрейпингом.
На импортных биржах "parsing" — это когда, например, есть здоровенный файл (или куча файлов) в экзотическом формате и надо из него надёргать данные. А "scraping" там — это когда есть сайт, с которого надо вытащить данные, тем или иным способом, хоть скриптом, хоть копипейстом.
Короче, я понял, проблема есть. Постараюсь сделать статью с терминологией по всей этой области.
В боевых условиях я использую phantomjs только на этапе авторизации, чтобы получить куки, сохранить их и использовать пока не устареют. Я делал скрейпинг адресов ревьюеров из топа. Надо было сделать 10000 запросов. Даже через needle это долго, а уж через hedless — тем более. Добавлял в каждый запрос куки, которые в самом начале были получены из phantomjs, а сами запросы делал с помощью needle. Все 10000 прошли без сбоев с одним набором кук. А вот на этапе тестирования авторизации капча вываливалась после десятка-другого запросов.
В принципе, так и должно быть. 10000 авторизованных запросов для Amazon — ерунда, а вот подозрительная активность при авторизации — это может быть подготовка скрейпинга, а может быть и взлом денежного аккаунта.
Да, когда есть возможность — лучше использовать готовый API, чем страницы скрейпить. Поддерживаю.
Капчи я наблюдал после 10 успешных входов подряд. Через некоторое время опять начинал пускать без капчи. После авторизации с готовыми куками мне капча вообще не попадалась.
Прокси при авторизации тем же аккаунтом, естественно, не помогают, ибо и так понятно, что это тот же юзер :)
Mink — это неплохая штука. Я его не упомянул просто потому что подбирал варианты для Node, а так — да.
Ну, это уже будет не только ради читаемости :)
Тут можно использовать ORM, да. Но "лучше" — это немного субъективно. Я стараюсь держаться подальше от холивара "ORM vs. raw SQL".
Это слово, которым скрейперы иногда называют скрейпинг :)
Хочется сказать, что "так исторически сложилось", но, на самом деле общепринятого устоявшегося русскоязычного термина для этого понятия пока нет, и скрейпинг иногда как только не называют. Это точно не просто "получение" или "извлекание", а вполне конкретная разновидность получения или извлекания. Термин "scraping" в английском изначально был жаргонным, но прижился (он означает выскребание данных из источников, явно для этого не предназначенных). Может и "скрейпинг" в русском приживётся, но не факт. Пока в сети большая часть общения о скрейпинге идёт на английском, так что проще использовать английский устоявшийся термин (как в случае с "браузером"), а не тратить время на внедрение "правильного" русскоязычного термина.
Если руки дойдут — сделаю статью по терминологии в этой области.
Вот таким вот образом.
Или вот таким ещё.
Обе ссылки из комментария к первой статье.
Вообще, если только структура html поменялась, то это пустяковая проблема, она быстро решается. Вот если сама архитектура бэкенда меняется или защита усиливается — тогда это практически новый заказ. Это большинство клиентов как минимум способны понять, если их заранее предупредить.
В предыдущем комменте пункты 2,3,4, конечно же. Чёртова разметка :)
Тут принцип простой: если скрипт на странице может распарсить ответ, пришедший на Ajax-запрос, то в принципе его распарсить можно. Если не DOM-парсером или XPath, так уж регулярками точно. Но иногда приходится подумать, да. Таблицы без классов и ID – это не так уж и сложно по сравнению с тем, что иногда встречается.
Я не останавливаюсь на теме парсинга слишком подробно только потому, что именно этот аспект скрейпинга описан очень подробно во множестве статей по всему вебу. От условного "парсинга для чайников" и до условного "вуду-магия профессионального парсинга". Остальные аспекты скрейпинга описаны далеко не так хорошо. Некоторые начинающие скрейперы даже не знают о существовании других аспектов. Иногда даже называют скрейпинг парсингом. Я стараюсь подобрать примеры с простым парсингом, чтобы сделать акцент на остальных моментах. Конечно, в реальной жизни попадаются сайты, которые парсить очень непросто, тут не поспоришь.
horseman – это просто способ запускать PhantomJS из ноды.
PhantomJS, как и все остальные headless-браузеры, отличается от Scrapy тем, что не просто читает/парсит http-ответы и формирует http-запросы, а выполняет скрипты с сайта. Другой принцип. Свои плюсы, свои минусы.
Совсем подобного нет, насколько я знаю. Платформа ещё молодая, а такие фреймворки быстро не делаются. Можно, конечно, написать скрейпер в стиле Python, не использующий сильные стороны Node.js, но он будет хуже Scrapy. Пока есть несколько сырых проектов, которые рано массово рекомендовать. Одно время подавал надежды node-crawler, но его поддержка прекращена, а замены, которые его автор рекомендует, мягко говоря не очень хороши.
Некоторые скрейперы потихоньку пилят свои фреймворки и однажды у одного-двух из них получится что-то приличное. Так было и со Scrapy, и с Grab.
Ещё есть такой момент, что с каждым годом писать фреймворки для скрейпинга становится всё труднее. Появляется всё больше частных случаев, которые надо учитывать, причём одновременно. И требования у заказчиков всё экзотичнее. Может быть напишу ещё об этом всём поподробнее.
Да, хорошая штука. Для node.js нечто подобное только ещё предстоит написать.
Суть в том, что подобные фреймворки появляются только тогда, когда реальный практик берётся изучать и использовать самые основы, а не выбирает из имеющихся недорешений и костылей к ним. Я на 100% уверен, что lorien умеет скрейпить без фреймворка, просто для него это пройденный этап.
Да, их много. Для Node.js ещё вот эти есть: