Comments 44
Нам препод рассказывал что можно парсить страницы с помощью недетерменированых конечных автоматов, как просто парсить например xml/html и строить его дерево например с их помощью я знаю, а вот как проанализировать например веб-страницу на наличие нужно информации?
Анализ наличия нужной информации — это довольно абстрактная тема, так как признаки нужности могут быть очень разными. Что-то можно проверить простенькой регуляркой, а что-то нужно прогонять через мощный синтаксический анализатор на НКА.
Спасибо за статью. Недавно я тоже написал две на такую же тему, с чуть более узким предметом:
https://habrahabr.ru/post/274475/
https://habrahabr.ru/post/277513/
Там разбираются многие темы, о которых вы упомянули.
Сделаю несколько заметок.
Использование JSDOM (в консольных скриптах) или NW.js (в GUI) помогает отказаться от сразу нескольких модулей, поскольку берёт на себя и HTTP, и парсинг DOM, и разрешение ссылок, и правильную обработку кодировок.
В качестве предосторожности от сбоев можно вести два лога: лог данных и лог успешно сохранённых адресов. Если чистовой файл результата нужен в виде единого объекта JSON, в конце работы лог данных можно переконвертировать, если достаточно простого несортированного результата — лог данных и будет таким результатом. Лог адресов можно загружать после прерывания, чтобы, во-первых, проверять по нему ссылки не грузить их по второму разу, и чтобы можно было начинать с последнего успешного адреса.
Если данные нужно сохранять в последовательном порядке (как в случае со словарями), параллельность выполнения будет мешать, если данных нужно сохранить очень много. В моей первой статье я описываю сохранение словаря размером в 2 гигабайта — строить такую структуру в памяти и потом её сортировать очень рискованно. Писать её в файл и потом его сортировать тоже может быть небезопасно (не у всех машины позволят такое провернуть, да и Node нужно будет запускать с ключами увеличения памяти).
- Также при асинхронной параллельности нужно учитывать политику сайта для ботов. Иногда её можно подсмотреть в robots.txt, а иногда приходится выяснять экспериментально. Многие сайты забанят особо ретивый скрипт после первых десятков запросов. Тогда приходится даже вставлять искусственные таймауты в однопоточную работу.
1. Никто не мешает собрать несколько модулей в один и использовать его и для всей последовательности задач. Проблема в том, что универсальные модули часто не учитывают много частных случаев, так что постоянно приходится лезть под капот, поэтому стоит иметь представление о том, как там всё устроено. Я и сам использую для скрейпинга собственный модуль, который «берёт на себя и HTTP, и парсинг DOM, и разрешение ссылок, и правильную обработку кодировок» и много чего ещё делает, но часто попадаются сайты, которые он не в состоянии обработать. Приходится к дедлайну всё делать на коленке из специализированных модулей, а потом, в спокойной остановке, допиливать универсальный модуль на будущее. Так он и развивается.
2. Всё верно. Вообще, это отдельная тема, и по ней я тоже планирую отписаться. Просто для начала взял пример попроще, где и без этого можно справиться, чтобы статья в здоровенный учебник не превращалась :)
3. Упорядочить можно уже готовые данные. Надо просто предусмотреть соответствующие поля заранее. Огромные структуры скрейпить в память — сизифов труд, да. В идеальном мире стоит писать в БД и проверять ошибки при перезапусках. Но в реальном мире заказчики иногда просят сохранение в читабельные файлы (например, им лень или трудно поднять БД на своей стороне), так что приходится выкручиваться, и не только с сортировкой. Про скрейпинг больших объёмов тоже будет статья, да.
4. Всякое бывает. Некоторые сайты честно просят не пинать их ботами чаще, чем раз в Х секунд, например. Теоретически, можно скрейпить параллельно через несколько прокси, и блокировки не будет, но можно, например, положить сервер нагрузкой, что как минимум не этично. Надо смотреть по ситуации. Конкретно в случае с Ferra.ru я запрашивал у главреда разрешение на использование скрейпера.
Короче, по каждому из четырёх пунктов стоит ответить полноценной статьёй :)
Не знал, что это называется «Web scraping»…
С терминологией в этой области до сих пор бардак. Возможно решусь сделать словарик отдельной статьёй. Пока в поисковике приходится десятки терминов пробивать, чтобы ничего не упустить. Термин «Web scraping» более-менее устоялся на англоязычных биржах фриланса.
Есть ещё проекты NW.js и Electron, связывающие Node.js и Chromium.
Да, у них очень широкое предназначение, но в том числе и такое. Я использовал NW.js для копирования сетевого словаря, довольно удобно и надёжно.
он по сути эмулирует бразуер и дает удобный доступ к html страницы
ну и защититься наверно от такого сложнее, так как происходит полноценная эмуляция браузера
Ну, htmlunit — это обычный headless. Как PhantomJS только на Java. Защититься от него можно так же легко/трудно, как от PhantomJS. Вот тут я эту тему немного раскрыл, если что.
все собирался у Вас спросить но стеснялся ) а не попадалась ли Вам (может свой опыт есть) инфа по детекту фантома (да и вообще версии движка хрома) по оптимизациям кода? Типа берем два куска кода, один оптимизируемый, другой нет, гоняем, замеряем. Если версия выше такой-то — один из семплов соптимизируется и будет быстрее другого, если ниже — то оба сопоставимо. И на разных наборах оптимизаций определять версию движка. Чет искал такое — не нашел, а идея очевидная. Возможно неправильно терминологию на английском в запросах использую, не верю что таких исследований не было.
Честно говоря, лучшая инфа, что мне попадалась по этой теме — это те две ссылки, которые kirill3333 привёл в комментариях к этой статье (выше и ниже соответственно). Главное, что стоит знать, на мой взгляд, если разработчик сайта захочет детектировать робота — значит он детектирует и гарантированных способов ему помешать нет. Просто как пример того, насколько далеко можно зайти в этом направлении посмотрите технологии на сайте areyouahuman.com. И это ещё не предел.
areyouahuman.com
Ммм, там чуть чуть не то, они статистически отслеживают, это даст более точный результат (скорее всего), но у меня чуть другая задача стоит. Мне надо по одному заходу поймать бота, то есть в первое же его появление, причем поймать в его же внутренностях. Ну ок, спасибо, буду думать дальше! Видимо придется самому попыхтеть )
так как происходит полноценная эмуляция браузера
Полноценная эмуляция броузера — это selenium на полноценном хроме или файрфоксе. А фантом все таки огрызок, и если это не специальная сборка, то вычислить его можно.
А какие методы детектирования headless-браузеров имеете в виду вы? анализ нагрузки, генерируемой с одинаковыми cookies с одинакового IP?
Борются часто не со скрейпингом, а, например, с ботами-коментаторами, с накруткой, с DDoSами, с попытками взлома и так далее, а скрейпинг попадает под раздачу. Но иногда такая хитрая защита означает настойчивую просьбу не скрейпить, и тогда это уже вопрос морали и закона. Но технически через Selenium скрейпится всё, что можно скрейпить вручную.
Я недавно натолкнулся на подобную особенность. Сначала долго ломал голову себе и докучал создателям jsdom, почему модуль не видит ссылку на следующую страницу. Весь код и структура идентичны в браузере и скрипте, за исключением ссылки на следующую страницу. Потом меня осенило, я переопределил userAgent в скрипте, и ссылка появилась.
значит нам не понадобится устанавливать специальные куки или http-заголовки чтобы получить страницу.Однако, стоит в любом случае передавать заголовки как в браузере. Это поможет защититься от подводных камней.
используется JQuery. Это довольно надёжный признак того, что cheerio с таким сайтом спарвитсяПолагаю взаимосвязи тут нет и быть не может, принципы работы jQuery и cheerio абсолютно разные, несмотря на схожий интерфейс использования и язык реализации.
— Я имел в виду, что если html достаточно «семантический» для того, чтобы использовать CSS-селекторы в jQuery, то эти же селекторы можно использовать и в cheerio. И то и другое — DOM-парсер в своей основе, так что если на странице используют jQuery, то она под него оптимизирована и cheerio на ней будет хорошо работать. Просто иногда бывает жуткая мешанина из div вообще без атрибутов и сориентироваться можно только по текстовым данным — тогда любые DOM-парсеры справляются плохо (а иногда и регулярки подводят).
Бесплатная версия для основных задач такого рода вполне подходит.
Ну вот представьте ситуацию: человек изучает такой инструмент для основных задач, чувствует себя могучим скрейпером, берёт заказ не глядя (а глядеть часто некогда, ибо конкуренция), начинает работать и вдруг понимает, что его любимый инструмент именно эту задачу не тянет ну никак. Важно понять, что на этапе взятия заказа не видно многих подводных камней, так что приходится принимать естественный риск, что над одним сайтом из нескольких десятков придётся повозиться подольше.
Я и сам использую универсальный модуль собственного сочинения и написание скрейпера для простого сайта у меня занимает от получаса, но бывают случаи, когда приходится вспоминать знания низкоуровневых основ. Это происходит всё реже, так как модуль непрерывно совершенствуется после таких случаев, но это всегда будет происходить, так как веб — это очень терпимая к нарушениям и ошибкам среда, где универсальные решения крайне сложно делать. Это я ещё не говорю о том, что даже начинающий хакер легко напишет защиту от сервисов уровня screen-scraper.com.
Всего лишь инструмент.
Без понимания именно тех низкоуровневых основ — в любом случае не получится сделать что-то сложное.
Но инструмент достаточно гибкий и удобный. Сильно помогает в парсинге полученного html, облегчает и ускоряет рутинные задачи, тот же самый анализ заголовков запросов/ответов.
Защиту от него написать — ну тут не знаю… Он же шлет себе http-запросы… Я же их сам и редактирую, если надо. Как сайт определит, что я не из браузера захожу?
Другой вопрос, что если это надо отдать клиенту для постоянного применения — то тут да, нужно уже своё что-то на эту тему использовать, под конкретный сайт заточенное.
Защита пишется влёгкую. Конечно, это типичная «битва брони и снаряда», и пока одни люди совершенствуют защиты — другие люди совершенствуют методы их обхода. Анализ заголовков браузера — это в последние годы и защитой-то не считается. Сейчас сайт определит, что вы зашли не из браузера, так как в ваших http-запросах не будет тех хитрых зашифрованных данных, которые в браузере вычислились бы подключённым js-скриптом, крайне трудным для реверс-инжиниринга. В запрос можно подставить всё — куки, заголовки, данные форм и так далее — однако все эти данные откуда-то нужно получить, а они не обязательно хранятся в http-ответах в открытом виде. Есть и другие способы защиты, вплоть до анализа частоты запросов. Это серьёзно. Чтобы понять, насколько это серьёзно, надо осознать, что большая часть защит пишется не от скрейперов, а от профессиональных взломщиков банковских онлайн-клиентов, а уж потом используется и против скрейперов тоже.
Кстати, насчёт защиты вычислением. Хотя этикет и требует, чтобы основные данные на страницах были доступны и при отключении JavaScript, часто бывает, что данные почти целиком генерируются скриптами. В таком случае мало скачать код и распарсить его регулярками или dom-парсером. Нужен инструмент, который сможет выполнить скрипты в правильном контексте с поддержкой всех нужных стандартов, и построить дерево динамически. Тут как раз и понадобятся средства вроде jsdom или интерфейсов к браузерным движкам.
Для тяжелых случаев вполне подойдет selenium, странно что его не упомянули.
Я почему и пишу, пару лет назад как раз и занимался этим. Сейчас — нет.
И тогда как раз скрин-скрейпер мне реально помог. Правда там был enterprise edition, у заказчиков был куплен.
С защитой постоянно сталкивался.
Всё обходилось легко, всякие сессии, cookies и т.д. — влёт, это вообще не вопрос. Эмуляция запроса-ответа, потом следующий запрос с новыми данными. А js я же в ответе получаю, его же и использую.
AJAX — вызывал проблемы, там уже руками приходилось писать, но тоже решаемо.
Вот частота запросов — это да.
Тогда мы обходились несколькими серверами, частоту регулировали скриптом, да еще и прокси всякие подставляли, геморрой еще тот был.
С другой стороны — стандартные задачи они стандартно и решаются… У меня обычно было что-то типа каталога на сайте. Сначала поиск по одному критерию, получаешь несколько страниц списков. По всем страницам пройти, зайти в каждый элемент списка и оттуда взять данные, сохранить в удобоваримой форме.
Доходило до 4-5 дней на один сайт (с паузами, чтобы не блокировали по частым запросам)
Но написание скрипта на каждый сайт (а их больше 500 было) в итоге занимало по полчаса.
Хоть я и фанат nodejs, такие несложные задачи обычно решаю на bash с использованием curl и pup. Если не заморачиваться с кодированием выходной информации, скрипт получается гораздо короче. Очень удобно использовать, например, для проверки баланса на счете или для определения инфы по внешнему ip…
Тема выбора языка для скрейпинга тянет на отдельную статью. Для проверки баланса и других подобных задач bash более чем достаточно. Тут я согласен. Но если нужно пройтись по десятку другому тысяч ссылок — тут уже стоит использовать… ну, хотя бы perl :)
Смысл статьи в том, чтобы на простом примере показать те основы, которые нужно хорошо знать, чтобы поверх них проектировать решения сложных задач. Естественно я планирую развивать тему.
Я бы даже сказал, что задача древняя как Netscape.
Я имел в виду задача для nodejs древняя.
По поводу выбора языка, на данный момент bash по гибкости не сильно уступает perl. Многие используемые bash`ом инструменты по обработке текстов написаны на perl. А уж проверить баланс или спарсить внешний ip откуда-нибудь — задача вообще одной строчки.
а тут получается спагетти из кода. Хотя node.js мне нравится, но для парсинга/скрапинга использую python.
Да, хорошая штука. Для node.js нечто подобное только ещё предстоит написать.
Суть в том, что подобные фреймворки появляются только тогда, когда реальный практик берётся изучать и использовать самые основы, а не выбирает из имеющихся недорешений и костылей к ним. Я на 100% уверен, что lorien умеет скрейпить без фреймворка, просто для него это пройденный этап.
Вообще, если только структура html поменялась, то это пустяковая проблема, она быстро решается. Вот если сама архитектура бэкенда меняется или защита усиливается — тогда это практически новый заказ. Это большинство клиентов как минимум способны понять, если их заранее предупредить.
Web scraping при помощи Node.js