Comments 38
В чем преимущество парсера на SlimmerJs от парсера написанного на perl или на NodeJs? Зачем так усложнять?
ответил ниже)
В сложных ситуациях. Например:
1. Когда есть какие-нибудь браузерные уловки. Правда это, в 99% случаев, будет уже зловредительство. Вроде рассылки спама, или скачивания информации, которую попытались от скачивания защитить.
2. API сервера меняется, чаще вёрстки. В этом случае можно довериться вёрстке :)
1. Когда есть какие-нибудь браузерные уловки. Правда это, в 99% случаев, будет уже зловредительство. Вроде рассылки спама, или скачивания информации, которую попытались от скачивания защитить.
2. API сервера меняется, чаще вёрстки. В этом случае можно довериться вёрстке :)
использование того или иного инструмента обусловлена в первую очередь тем какой сайт придется парсить, незнаю каким образом вы парсите динамически подгружаемый контент или ситуации когда во время загрузки сайта появиться каптча.
Динамически подгружаемый контент парсится на много легче когда он вынесен в api сайта, потому что, как правило, там обёрточных данных меньше и можно задавать доп параметры, в особенности те, что нужны. Например кол-во элементов в выдаче, или поиск. Еще api менее всего уделяют внимание в плане защиты. Более того, когда есть такой api, почти вся работа ложится именно на него
про какой парсинг вообще можно говорить если вы работаете с API?
Я говорю про парсинг тех источников данных, которые создатели сайта используют доя подгрузки динамического контента. Странно что вы не поняли этого. Можно назвать это api или как угодно, сути не меняет.
Если бы все было так просто. Вам видимо не приходилось парсить сайты которые заботятся о своих данных и разными средствами пытаются их защитить. Для примера: запрос на получение данных может не сработать, если предположить что сайт ставит куки о посещенных страницах или вам требуется ввести каптчу без перегрузки страницы
Я работаю с многими сайтами, более того практически в реальном времени (задержка 5-10 мин). Например самая большая доска объявлений по России или сайт, где все продают свои машины.
Протокол HTTP текстовый, куки передаются так де текстом, магии в работе со страницей без ее перезагрузки нет ;)
Как мне кажется, лучшем решением по работе с текстовым протоколом является то, на котором легче всего обрабатывать строки. По этому предпочитаю Perl за его легкость в работе регулярных выражений.
На данный момент нет ни одной адекватной защиты против автоматического распознавания чего либо.
Протокол HTTP текстовый, куки передаются так де текстом, магии в работе со страницей без ее перезагрузки нет ;)
Как мне кажется, лучшем решением по работе с текстовым протоколом является то, на котором легче всего обрабатывать строки. По этому предпочитаю Perl за его легкость в работе регулярных выражений.
На данный момент нет ни одной адекватной защиты против автоматического распознавания чего либо.
как вы реализовали проблему с каптчами?
В зависимости от конкретного ресурса. Чаще всего просто когда мне предлагают капчу, меняю ip-адрес, тру куки и меняю user-agent. Многие пользуются antigate но я его не использовал.
Простые капчи парсятся через OCR-программы. Они бесплатные, есть консольные и с возможностью обучения.
Простые капчи парсятся через OCR-программы. Они бесплатные, есть консольные и с возможностью обучения.
Всегда есть сервис, который может решить эту проблему. antigate уже упомянули, но в целом их достаточно много. Опят же для интернет магазина капча в контексте парсинга каталога товаров совершенно не актуальна.
с этими сервисами я знаком, как раз один из них интегрирован в парсер яндекса, но и вопрос в том что как разгадывать каптчи клиент-серверными приложением? допусти каптча возвращается ни как страница, а возникает в процессе работы, т.е грубо говоря аяксом поверх основного контента
Учитывая, что SlimerJS это headless браузер, то имеем полный DOM с рендерингом страницы. Не вижу, чем принципиальная разница между парсингом характеристик товаров и капчей. Это все парсинг данных которые в браузере видит человек, значит спарсить это можно.
Может конечно в SlimerJS с этим какие-то проблемы… Но я в работе использую PhantomJS (а SlimerJS пытается его догнать по функционалу, только на базе FireFox-а) в режиме selenim hub, т.е. управление по webdriver, с написанием бизнес-логики парсинга на XPath. И там уже не важно что, откуда и как вообще грузиться. Видно на странице в браузере? Значит можно стянуть.
Может конечно в SlimerJS с этим какие-то проблемы… Но я в работе использую PhantomJS (а SlimerJS пытается его догнать по функционалу, только на базе FireFox-а) в режиме selenim hub, т.е. управление по webdriver, с написанием бизнес-логики парсинга на XPath. И там уже не важно что, откуда и как вообще грузиться. Видно на странице в браузере? Значит можно стянуть.
Я с вами согласен, но хочу добавить, что все зависит от ситуации, потому что когда надо получать данные с множества сайтов делая по 10000 запросов единовременно, SlimmerJS, как и PhantomJS потребляют слишком много ресурсов. Для одного потока конечно нормально. А на счет изменений в верстке, DOM структура так же легко может измениться. Мне PhantomJS нравится и я его использовал регулярно. Так что могу с уверенностью сказать, что все зависит от задачи, но 95% случаев решается оптимальнее на Perl
Конечно DOM может меняться. Именно поэтому и используется XPath. При правильном написании выражений парсер может продолжать работать даже если часть разметки изменилось. Не говоря уже о том, что какие-то вещи на регулярках пишуется слишком сложно и малочитаемо в том время как XPath получается лаконичным и удобно поддерживаемым.
)) вы видимо не внимательно прочитали мой ответ, я не говорил что с этим проблемы в SlimerJS. Все что касаеться работы с DOM он справляеться более чем отлично. PhantonJS я тоже использовал, но SlimerJs понравился больше тем что позволяет отображать окно браузера, это очень удобно при автоматизации определенных бизнес процессов.
API SlimerJS очень близко к PhantomJS и у разработчиков огромное желание к версии 1.0.0 полностью скопировать API PhantomJs
API SlimerJS очень близко к PhantomJS и у разработчиков огромное желание к версии 1.0.0 полностью скопировать API PhantomJs
т.е грубо говоря аяксом поверх основного контента
Тогда в чем суть вопроса-то?
вопрос был в том как эту проблему решает dmx102 с помощью perl, так как насколько я понимаю он использует cURL или что то подобное для парсинга
Любая капча начинается с инициализации на целевой странице. Затем отдается картинка. Потом следует запрос, верифицирующий переданное значение капчи и параметра ее инициализирующее. В зависимости от сложности капчи она либо скармливается подпрограмме OCR и получается ее расшифрованное значение, либо отдается антигейту и подобным. Других вариантов нет.
На SlimmerJS вы точно так же получите картинку капчи и придете к тому же выбору: «а что же делать дальше?»
Рекоммендую при парсинге просто не допускать ее появления, укладываясь в «разрешенные» (антиспам) лимиты. Они либо вычисляются имперически, либо читаются на специализированных ресурсах.
На SlimmerJS вы точно так же получите картинку капчи и придете к тому же выбору: «а что же делать дальше?»
Рекоммендую при парсинге просто не допускать ее появления, укладываясь в «разрешенные» (антиспам) лимиты. Они либо вычисляются имперически, либо читаются на специализированных ресурсах.
В SlimereJS все проще, перед какой то бизней логикой анализируется изначально известный html блок в котором появляется каптча. Далее. без перегрузки страницы автоматически делается скриншот каптчи, кодируеться в base64 и в том же окне генерируется запрос а API того же антигейта и через пару секунд уже получен результат.
Все это работает без перегрузки целевой страницы.
при таком подходе получается долго парсить ресурс без всяких лимитов, единственное соблюдая определенный таймаут
Все это работает без перегрузки целевой страницы.
при таком подходе получается долго парсить ресурс без всяких лимитов, единственное соблюдая определенный таймаут
Таймауты решаются пачкой прокси. Это еще одна причина по которой я использую PhantomJS. Его можно при запуске зацепить к заданной прокси. К большому сожалению не хватает возможности динамически их менять. Приходится иметь пачку запущенных фантомов — по одному для каждой прокси. А уже приложение по кругу их обходит отправляя задание на парсинг.
На perl'е тоже не перезагружается страница)
Все верно, точно так же. Вопрос, какими силами. Сделать скрин с окна это тупо вызов одного метода в коде. Без волнений вообще как эта капча там появляется.
Безголовые браузеры сильно теряют на потреблении ресурсов и скорости работы, но сильно помогают на сапорте кода парсера.
Безголовые браузеры сильно теряют на потреблении ресурсов и скорости работы, но сильно помогают на сапорте кода парсера.
Большая доска как ни крути это относительно адекватная разметка и работа сайта. А когда сайт поставщика это детища написанное в начале нулевых, и поддерживаемая ХХ разработчиками кто во что горазд, то чисто работы с текстом может не хватать. Потому что мешанина из JS-CSS-HTML такая, что порой на супорте проще поддерживать парсер с возможностью рендеринга страниц, чем каждый раз подстраивать тестовой парсер под изменения, зачастую кривые.
Вы статью читали?
Речь вообще про ШАБЛОННЫЕ интернет-магазины и СТРУКТУРИРОВАННЫЕ данные
Речь вообще про ШАБЛОННЫЕ интернет-магазины и СТРУКТУРИРОВАННЫЕ данные
А вы?
Я тоже про структурированный данные. Могу даже пошутить «со слабо структурированными данными». Если не приходилось иметь дело со страницами на которых один и тот же шаблон может в итоге давать немного отличающийся результат, то это не значит, что таких ситуаций нет. И я сейчас даже не беру вариант, когда это делается намеренно с цель «защиты».
Я тоже про структурированный данные. Могу даже пошутить «со слабо структурированными данными». Если не приходилось иметь дело со страницами на которых один и тот же шаблон может в итоге давать немного отличающийся результат, то это не значит, что таких ситуаций нет. И я сейчас даже не беру вариант, когда это делается намеренно с цель «защиты».
Единственное, что при рендеренге хорошо, это отображение данных, которые генерятся на js с целью маскировки через обфусцирование
Назвать это API нельзя. Потому что в итоге даже к такому «API» приходится писать кастомый парсер (парсер != разбор_только_веб_страницы).
Я для этих целей написал обертку вокруг x-ray + needle, а данные сохраняю в тарантул через tarantool-driver.
Sign up to leave a comment.
Попытка реализации универсального парсера интернет магазинов с помощью SlimerJS