Ну… скрипт на perl или несколько скриптов на perl соединённые через bash — тут слишком тонкая грань. Но по сути я с вами согласен, парсинг нескольких незащищённых страниц — это пустячная задача.
В большинстве таких случаев данные не генерятся, а запрашиваются по ajax или как-то ещё, но в открытом виде. Или генерятся каким-то очевидным образом. Если данные трудно получить без таких вещей как PhantomJS, то владелец сайта точно против того, чтобы его скрейпили. И стоит задуматься, что у него могут быть не только хорошие хакеры, но и хорошие юристы. В любом случае, весь код страницы открыт для реверс-инжиниринга, вопрос только в трудоёмкости.
Я пока не готов написать обзор инструментов для скрейпинга, но среди них много неплохих решений для рутинных задач. Проблема в том, что существуют не только рутинные задачи. Более того, существуют задачи, про которые далеко не сразу можно понять рутинные они или нет.
Защита пишется влёгкую. Конечно, это типичная «битва брони и снаряда», и пока одни люди совершенствуют защиты — другие люди совершенствуют методы их обхода. Анализ заголовков браузера — это в последние годы и защитой-то не считается. Сейчас сайт определит, что вы зашли не из браузера, так как в ваших http-запросах не будет тех хитрых зашифрованных данных, которые в браузере вычислились бы подключённым js-скриптом, крайне трудным для реверс-инжиниринга. В запрос можно подставить всё — куки, заголовки, данные форм и так далее — однако все эти данные откуда-то нужно получить, а они не обязательно хранятся в http-ответах в открытом виде. Есть и другие способы защиты, вплоть до анализа частоты запросов. Это серьёзно. Чтобы понять, насколько это серьёзно, надо осознать, что большая часть защит пишется не от скрейперов, а от профессиональных взломщиков банковских онлайн-клиентов, а уж потом используется и против скрейперов тоже.
Я бы даже сказал, что задача древняя как Netscape. Но веб развивается, появляются сложности, которых раньше не было. Я занимался скрейпингом ещё до IE8 и берусь утверждать, что скрейпинг «уже не торт».
Тема выбора языка для скрейпинга тянет на отдельную статью. Для проверки баланса и других подобных задач bash более чем достаточно. Тут я согласен. Но если нужно пройтись по десятку другому тысяч ссылок — тут уже стоит использовать… ну, хотя бы perl :)
Смысл статьи в том, чтобы на простом примере показать те основы, которые нужно хорошо знать, чтобы поверх них проектировать решения сложных задач. Естественно я планирую развивать тему.
Есть довольно много подобных готовых инструментов. Проблема в том, что они подходят только основные задачи.
Ну вот представьте ситуацию: человек изучает такой инструмент для основных задач, чувствует себя могучим скрейпером, берёт заказ не глядя (а глядеть часто некогда, ибо конкуренция), начинает работать и вдруг понимает, что его любимый инструмент именно эту задачу не тянет ну никак. Важно понять, что на этапе взятия заказа не видно многих подводных камней, так что приходится принимать естественный риск, что над одним сайтом из нескольких десятков придётся повозиться подольше.
Я и сам использую универсальный модуль собственного сочинения и написание скрейпера для простого сайта у меня занимает от получаса, но бывают случаи, когда приходится вспоминать знания низкоуровневых основ. Это происходит всё реже, так как модуль непрерывно совершенствуется после таких случаев, но это всегда будет происходить, так как веб — это очень терпимая к нарушениям и ошибкам среда, где универсальные решения крайне сложно делать. Это я ещё не говорю о том, что даже начинающий хакер легко напишет защиту от сервисов уровня screen-scraper.com.
— needle отправляет некий минимальный набор заголовков. Без этого никак, да.
— Я имел в виду, что если html достаточно «семантический» для того, чтобы использовать CSS-селекторы в jQuery, то эти же селекторы можно использовать и в cheerio. И то и другое — DOM-парсер в своей основе, так что если на странице используют jQuery, то она под него оптимизирована и cheerio на ней будет хорошо работать. Просто иногда бывает жуткая мешанина из div вообще без атрибутов и сориентироваться можно только по текстовым данным — тогда любые DOM-парсеры справляются плохо (а иногда и регулярки подводят).
Да, бывают сайты, где только Selenium, только хардкор. К счастью, их мало :)
Борются часто не со скрейпингом, а, например, с ботами-коментаторами, с накруткой, с DDoSами, с попытками взлома и так далее, а скрейпинг попадает под раздачу. Но иногда такая хитрая защита означает настойчивую просьбу не скрейпить, и тогда это уже вопрос морали и закона. Но технически через Selenium скрейпится всё, что можно скрейпить вручную.
С терминологией в этой области до сих пор бардак. Возможно решусь сделать словарик отдельной статьёй. Пока в поисковике приходится десятки терминов пробивать, чтобы ничего не упустить. Термин «Web scraping» более-менее устоялся на англоязычных биржах фриланса.
1. Никто не мешает собрать несколько модулей в один и использовать его и для всей последовательности задач. Проблема в том, что универсальные модули часто не учитывают много частных случаев, так что постоянно приходится лезть под капот, поэтому стоит иметь представление о том, как там всё устроено. Я и сам использую для скрейпинга собственный модуль, который «берёт на себя и HTTP, и парсинг DOM, и разрешение ссылок, и правильную обработку кодировок» и много чего ещё делает, но часто попадаются сайты, которые он не в состоянии обработать. Приходится к дедлайну всё делать на коленке из специализированных модулей, а потом, в спокойной остановке, допиливать универсальный модуль на будущее. Так он и развивается.
2. Всё верно. Вообще, это отдельная тема, и по ней я тоже планирую отписаться. Просто для начала взял пример попроще, где и без этого можно справиться, чтобы статья в здоровенный учебник не превращалась :)
3. Упорядочить можно уже готовые данные. Надо просто предусмотреть соответствующие поля заранее. Огромные структуры скрейпить в память — сизифов труд, да. В идеальном мире стоит писать в БД и проверять ошибки при перезапусках. Но в реальном мире заказчики иногда просят сохранение в читабельные файлы (например, им лень или трудно поднять БД на своей стороне), так что приходится выкручиваться, и не только с сортировкой. Про скрейпинг больших объёмов тоже будет статья, да.
4. Всякое бывает. Некоторые сайты честно просят не пинать их ботами чаще, чем раз в Х секунд, например. Теоретически, можно скрейпить параллельно через несколько прокси, и блокировки не будет, но можно, например, положить сервер нагрузкой, что как минимум не этично. Надо смотреть по ситуации. Конкретно в случае с Ferra.ru я запрашивал у главреда разрешение на использование скрейпера.
Короче, по каждому из четырёх пунктов стоит ответить полноценной статьёй :)
Ну, про НКА стоит думать на этапе написания чего-то вроде cheerio или, например, lxml, а на этапе скрейпинга просто используется готовый парсер по принципу чёрного ящика.
Анализ наличия нужной информации — это довольно абстрактная тема, так как признаки нужности могут быть очень разными. Что-то можно проверить простенькой регуляркой, а что-то нужно прогонять через мощный синтаксический анализатор на НКА.
Защита пишется влёгкую. Конечно, это типичная «битва брони и снаряда», и пока одни люди совершенствуют защиты — другие люди совершенствуют методы их обхода. Анализ заголовков браузера — это в последние годы и защитой-то не считается. Сейчас сайт определит, что вы зашли не из браузера, так как в ваших http-запросах не будет тех хитрых зашифрованных данных, которые в браузере вычислились бы подключённым js-скриптом, крайне трудным для реверс-инжиниринга. В запрос можно подставить всё — куки, заголовки, данные форм и так далее — однако все эти данные откуда-то нужно получить, а они не обязательно хранятся в http-ответах в открытом виде. Есть и другие способы защиты, вплоть до анализа частоты запросов. Это серьёзно. Чтобы понять, насколько это серьёзно, надо осознать, что большая часть защит пишется не от скрейперов, а от профессиональных взломщиков банковских онлайн-клиентов, а уж потом используется и против скрейперов тоже.
Тема выбора языка для скрейпинга тянет на отдельную статью. Для проверки баланса и других подобных задач bash более чем достаточно. Тут я согласен. Но если нужно пройтись по десятку другому тысяч ссылок — тут уже стоит использовать… ну, хотя бы perl :)
Смысл статьи в том, чтобы на простом примере показать те основы, которые нужно хорошо знать, чтобы поверх них проектировать решения сложных задач. Естественно я планирую развивать тему.
Ну вот представьте ситуацию: человек изучает такой инструмент для основных задач, чувствует себя могучим скрейпером, берёт заказ не глядя (а глядеть часто некогда, ибо конкуренция), начинает работать и вдруг понимает, что его любимый инструмент именно эту задачу не тянет ну никак. Важно понять, что на этапе взятия заказа не видно многих подводных камней, так что приходится принимать естественный риск, что над одним сайтом из нескольких десятков придётся повозиться подольше.
Я и сам использую универсальный модуль собственного сочинения и написание скрейпера для простого сайта у меня занимает от получаса, но бывают случаи, когда приходится вспоминать знания низкоуровневых основ. Это происходит всё реже, так как модуль непрерывно совершенствуется после таких случаев, но это всегда будет происходить, так как веб — это очень терпимая к нарушениям и ошибкам среда, где универсальные решения крайне сложно делать. Это я ещё не говорю о том, что даже начинающий хакер легко напишет защиту от сервисов уровня screen-scraper.com.
— Я имел в виду, что если html достаточно «семантический» для того, чтобы использовать CSS-селекторы в jQuery, то эти же селекторы можно использовать и в cheerio. И то и другое — DOM-парсер в своей основе, так что если на странице используют jQuery, то она под него оптимизирована и cheerio на ней будет хорошо работать. Просто иногда бывает жуткая мешанина из div вообще без атрибутов и сориентироваться можно только по текстовым данным — тогда любые DOM-парсеры справляются плохо (а иногда и регулярки подводят).
Борются часто не со скрейпингом, а, например, с ботами-коментаторами, с накруткой, с DDoSами, с попытками взлома и так далее, а скрейпинг попадает под раздачу. Но иногда такая хитрая защита означает настойчивую просьбу не скрейпить, и тогда это уже вопрос морали и закона. Но технически через Selenium скрейпится всё, что можно скрейпить вручную.
С терминологией в этой области до сих пор бардак. Возможно решусь сделать словарик отдельной статьёй. Пока в поисковике приходится десятки терминов пробивать, чтобы ничего не упустить. Термин «Web scraping» более-менее устоялся на англоязычных биржах фриланса.
1. Никто не мешает собрать несколько модулей в один и использовать его и для всей последовательности задач. Проблема в том, что универсальные модули часто не учитывают много частных случаев, так что постоянно приходится лезть под капот, поэтому стоит иметь представление о том, как там всё устроено. Я и сам использую для скрейпинга собственный модуль, который «берёт на себя и HTTP, и парсинг DOM, и разрешение ссылок, и правильную обработку кодировок» и много чего ещё делает, но часто попадаются сайты, которые он не в состоянии обработать. Приходится к дедлайну всё делать на коленке из специализированных модулей, а потом, в спокойной остановке, допиливать универсальный модуль на будущее. Так он и развивается.
2. Всё верно. Вообще, это отдельная тема, и по ней я тоже планирую отписаться. Просто для начала взял пример попроще, где и без этого можно справиться, чтобы статья в здоровенный учебник не превращалась :)
3. Упорядочить можно уже готовые данные. Надо просто предусмотреть соответствующие поля заранее. Огромные структуры скрейпить в память — сизифов труд, да. В идеальном мире стоит писать в БД и проверять ошибки при перезапусках. Но в реальном мире заказчики иногда просят сохранение в читабельные файлы (например, им лень или трудно поднять БД на своей стороне), так что приходится выкручиваться, и не только с сортировкой. Про скрейпинг больших объёмов тоже будет статья, да.
4. Всякое бывает. Некоторые сайты честно просят не пинать их ботами чаще, чем раз в Х секунд, например. Теоретически, можно скрейпить параллельно через несколько прокси, и блокировки не будет, но можно, например, положить сервер нагрузкой, что как минимум не этично. Надо смотреть по ситуации. Конкретно в случае с Ferra.ru я запрашивал у главреда разрешение на использование скрейпера.
Короче, по каждому из четырёх пунктов стоит ответить полноценной статьёй :)
Анализ наличия нужной информации — это довольно абстрактная тема, так как признаки нужности могут быть очень разными. Что-то можно проверить простенькой регуляркой, а что-то нужно прогонять через мощный синтаксический анализатор на НКА.