Успешные парсеры веб-страниц следуют некоторым практикам, которые делают их успешными в этой области. Если вы хотите достичь успеха в парсинге веб-страниц, вам нужно придерживаться этих лучших практик. Присоединяйтесь сейчас, чтобы узнать о них.

Как новичок в парсинге веб-страниц, вы можете подумать, что ваш скрипт может справиться с любой задачей любого масштаба, но рано или поздно вы обнаружите, что ваш скрипт - это всего лишь концепция, и вы поймете, насколько наивны были.

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

В этой статье вы узнаете о лучших практиках при парсинге веб-сайта. Вы также узнаете, как решать распространенные проблемы, с которыми вы столкнетесь при парсинге веб-страниц, и как их решить.

Основные проблемы при парсинге веб-страниц

Как парсер веб-страниц, вам нужно знать, что есть некоторые проблемы, с которыми вы, вероятно, столкнетесь в процессе парсинга. Некоторые из них происходят часто, а некоторые - реже. Независимо от частоты возникновения, вам нужно о них знать. Ниже рассмотрены наиболее распространенные из них. [su_youtube url=”https://www.youtube.com/watch?v=SA18JCBtlXY" title=”проблемы парсинга веб-страниц”]

• Изменение HTML-разметки страницы

Я решил начать с этой проблемы, потому что в большинстве случаев это не связано с попыткой веб-сайта предотвратить парсинг. Однако это одна из самых популярных причин, по которым скрипты парсинга перестают работать. Большинство сайтов обычно меняют свой макет через некоторое время, и при этом меняется HTML-разметка.

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

• Ошибочный парсинг неправильных данных

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

Однако, когда объем данных для парсинга большой, и вы не можете их все просмотреть, вам нужно задуматься о целостности и качестве всех спарсенных данных. Это связано с тем, что некоторые данные могут не соответствовать вашим качественным требованиям. Для этого вам нужно подвергнуть данные тестовому случаю перед добавлением их в базу данных.

• Техники борьбы с парсингом

Веб-сайты не хотят, чтобы их данные парсились, и если хотят, они предоставят вам API для этого. Большинство сложных веб-сайтов имеют системы борьбы со спамом, чтобы предотвратить доступ к их контенту веб-парсеров, краулеров и других автоматизированных ботов.

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

• Проблема парсинга в большом масштабе

Если вы новичок в области парсинга веб-страниц, вы можете подумать, что парсинг сайта из 10 000 страниц такой же, как парсинг сайта из 2 миллионов страниц. Однако, чем больше данных вам нужно спарсить, тем более осторожным и планирующим вы должны быть. В целом, вам нужно знать, что чем больше данных вам нужно спарсить, тем больше времени это займет.

Обычно разработка парсера для параллельного парсинга и распределение работы между разными компьютерами/серверами сделает весь процесс быстрее. Также ваша система базы данных должна быть масштабируемой, быстрой, надежной и безопасной. В противном случае вы рискуете потратить много времени на попытки выполнить запрос к базе данных. Amazon Web Services (AWS) - один из лучших выборов на рынке.

Лучшие практики парсинга веб-сайтов

Как и в любой другой деятельности, существуют определенные лучшие практики, которые следует соблюдать при парсинге веб-сайтов. В этой части статьи я опишу эти лучшие практики.

• Уважение к файлу robots.txt веб-сайта

Большинство веб-сайтов имеют файл robots.txt, который используется для взаимодействия с автоматическими ботами, такими как краулеры и парсеры, и указывает, какие страницы можно и нельзя парсить. Он также может содержать другие команды, такие как частота краулинга и время между запросами и т. д. Одно из замеченных мной отличий между большинством парсеров, за исключением поисковых систем, и файлами robots.txt заключается в том, что они не учитывают эти файлы - они полностью их игнорируют. Фактически, некоторые парсеры считают файл robots.txt устаревшим.

Однако, соблюдение файла robots.txt веб-сайта является одной из лучших практик. Даже если вы не хотите следовать правилам запрета, указанным в файле, вы все равно можете уважать задержку между запросами, чтобы быть более вежливым к веб-серверам. Вы можете найти информацию о том, как разобрать файл robots.txt на вашем предпочитаемом языке программирования и в парсере. Для программистов на Python это можно сделать с помощью модуля urllib.robotparser.

• Спуфинг User-Agent и других заголовков HTTP

Когда браузер отправляет запрос на веб-сервер, он отправляет детали, такие как User-Agent, который является строкой, идентифицирующей браузер. Вместе с User-Agent отправляются другие данные, такие как Accept, Accept-Language, Accept-Encoding и Referrer.

Парсеры также должны отправлять эту информацию, иначе некоторые сайты могут отказать в доступе. Некоторые сайты автоматически блокируют определенные краулеры и парсеры, используя их User-Agent для их идентификации.

Если вы не хотите, чтобы ваш бот был идентифицирован как парсер, вам нужно спуфить User-Agent, заменив его на User-Agent популярного веб-браузера. Еще лучше, если вы сможете менять User-Agent, но вам нужно убедиться, что сайт не представляет разные макеты для разных User-Agent, иначе ваш код сломается, если произойдет изменение макета, которое вы не учли в своем коде. При использовании строки User-Agent популярного браузера также убедитесь, что другие заголовки HTTP соответствуют ему. Убедитесь также, что вы предоставляете значение для заголовка Referrer, чтобы он выглядел более естественно.

• Обработка входа в систему и сессионных файлов cookie

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

Но как же войти в систему и сохранить сессионные файлы cookie в первую очередь?

Хотя это может показаться сложной задачей, на самом деле это несложно, если вы знаете, что делаете. Вам просто нужно создать сессию, затем отправить запрос на URL входа в систему с вашими учетными данными в качестве данных запроса. Если ваш запрос успешен, вы получите ответ с прикрепленными сессионными файлами cookie.

С полученным сессионным файлом cookie вы можете прикрепить его к каждому из ваших запросов, и вас не будут просить войти в систему снова, так как сайты используют файлы cookie для идентификации своих пользователей. Чтобы узнать URL входа в систему и название полей формы, которые нужно использовать для данных запроса, вам нужно проанализировать форму в браузерной среде, щелкнув правой кнопкой мыши и выбрав опцию "Инспектировать элемент".

Значение атрибута action формы является URL входа в систему. Для данных запроса проанализируйте элемент формы и извлеките правильное имя поля имени пользователя и пароля - а также другое поле, если оно есть.

• Обработка скрытых (но обязательных) защитных полей в формах POST

Вышеуказанный метод входа в систему может не работать для некоторых сайтов, которые имеют скрытые защитные поля для предотвращения доступа хакеров и спамеров к своим сайтам. Это связано с тем, что если вы попытаетесь отправить только имя пользователя и пароль без данных для скрытого поля, запрос не будет успешным.

Помимо входа в систему, многие формы POST также имеют защитные поля, такие как csrf_token, скрытые от обычных пользователей и автоматически заполняемые хэш-значением, которое вы не можете воспроизвести. Чтобы получить данные для этого поля, вам нужно создать сессию, посетить страницу и извлечь значение из этого скрытого поля. После этого вы можете отправить запрос с значением для скрытого поля в данных запроса.

• Замедление запросов, чтобы избежать перегрузки веб-сайта

Парсинг веб-сайтов включает отправку большого количества запросов на веб-сайты, которые вам не принадлежат. Это означает, что вы естественным образом увеличиваете затраты на поддержку сайта, не добавляя никакой ценности самому сайту. Если вы не можете добавить ценность веб-сайту, который вы парсите, то постарайтесь быть вежливым и установите задержку между запросами, чтобы не перегружать сервер веб-сайта. Некоторые веб-сайты даже указывают оптимальную задержку для краулеров и парсеров в своем файле robots.txt.

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

• Распределение запросов по нескольким IP-адресам

Честно говоря, этот пункт не должен быть частью лучших практик, так как использование прокси при парсинге является обязательным. Каждый веб-сайт имеет ограничение на количество запросов, которое разрешено с одного IP-адреса за определенный период времени. Если IP-адрес пытается превысить это ограничение, он будет заблокирован на некоторое время.

Поэтому, если вы планируете парсить в большом масштабе, вам необходимо использовать прокси. С помощью прокси вы можете распределить свои запросы по нескольким IP-адресам и сделать так, чтобы они выглядели, как будто они поступают на веб-сайт с разных устройств.

Использование пула прокси - это лучший вариант. Это связано с тем, что у них есть много IP-адресов в своем пуле, и вам не нужно беспокоиться о повороте IP-адресов и устранении неправильных IP-адресов. Что касается типов прокси, лучше всего использовать резидентные прокси. Однако для некоторых выбранных сайтов дата-центровые прокси работают отлично.

• Обработка отсутствующих HTML-тегов

При парсинге веб-сайтов важно понимать, что код HTML страницы нельзя считать надежным, и это имеет свои причины - он постоянно меняется.

Поэтому важно всегда проверять наличие элемента перед его обработкой или извлечением данных из него. При попытке извлечь данные из отсутствующего HTML-тега некоторые библиотеки парсинга будут возвращать None, в то время как другие будут вызывать исключение.

Рекомендуется всегда использовать оператор if для проверки наличия тега перед его обработкой. И если элемент отсутствует, парсер должен записать это в журнал и уведомить вас, чтобы вы знали, что что-то изменилось на странице и могли принять соответствующие меры.

• Обработка сетевых ошибок

Вы пишете код для своего парсера и не думаете о сетевых ошибках, верно?

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

Золотое правило состоит в том, чтобы никогда не полагаться на то, что сеть будет работать так, как вы ожидаете. Проблемы возникнут, и поэтому вы должны написать свой код таким образом, чтобы учесть возможность сетевых ошибок и обрабатывать их соответствующим образом.

Убедитесь, что в каждой части вашего кода, где вы отправляете веб-запросы, есть обработка исключений, например:

requests.get(https://www.google.com)
except requests.exceptions.RequestException:
# код для обработки исключения здесь.

При обработке ошибки вы можете повторить запрос, и после нескольких попыток вы можете перейти к следующему URL и записать этот конкретный URL и ошибку, чтобы вы могли решить эту проблему вручную. Также убедитесь, что вы начинаете извлекать данные только тогда, когда возвращается код состояния HTTP 200.

• Парсинг кэша Google для нечувствительных к времени данных

Вам необходимо спарсить данные, которые не зависят от времени? Тогда вы можете оставить веб-сайт в покое и парсить его данные, парся копии на кэше Google. Вас может заинтересовать тот факт, что большинство страниц, которые вы пытаетесь спарсить, уже были спарсены Google, и вы можете спарсить их напрямую из кэша Google, особенно когда речь идет о исторических данных. Вы можете получить весь HTML страницы, включая изображения и другие файлы, из кэша Google.

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

Об этом нельзя сказать о других веб-сайтах, серверы которых могут легко перегрузиться запросами. Даже Scrapy советует парсить исторические данные из кэша Google, а не напрямую с веб-сайта.

Заключение

Парсинг веб-сайтов - это серьезное дело, требующее хорошей подготовки и внимательного выполнения, особенно если вы планируете заниматься им в значительном масштабе. При планировании необходимо учитывать некоторые ключевые правила парсинга веб-сайтов, которые были рассмотрены выше.