Распознавание капчи, отправка текста капчи и получение ответных cookies (с использованием WBApp) при парсинге контента

Распознавание капчи, отправка текста капчи и получение ответных cookies (с использованием WBApp) при парсинге контента

Если парсить контент через библиотеку Internet Explorer (DOM) (ctrl+h), то для автоввода капч достаточно лишь прописать в проект WBApp группу макросов [CAPCHA] (смотрите видео распознавание текста капчи с помощью сервиса Antigate на этой странице http://sbfactory.ru/cd/?p=1515). В этом случае, группа макросов [CAPCHA] сама проверяет наличие капчи на странице и устанавливает в Internet Explorer нужные cookies.

Но если же мы парсим контент с использованием библиотек Indy или Clever Internet Suite (ctrl+h), которые не имеют отношения к Internet Explorer (это GET-запросы программы Content Downloader), техника обхода капчи должна быть примерно такой:
1) Проверка появления капчи макросом шаблона вывода [CHECKENTRY];
2) Вызов нужного проекта WBApp (Internet Explorer (DOM)) из шаблона вывода Content Downloader макросом [WBAPP] для распознавания капчи и получения ответных cookies обратно в Content Downloader.


1) Проверка появления капчи макросом шаблона вывода [CHECKENTRY]:

В шаблон вывода Content Downloader добавляем примерно следующую конструкцию:

1
[CHECKENTRY(img src="capcha.jpg" alt="введите текст с картинки")][DOCSOURCE][THENTEXT][WBAPP(C:\Anticapcha.wbapp|<CD_DOCURL!>)][/WBAPP][RELOADDOCUMENT][/CHECKENTRY]

Данная конструкция проверит – есть ли на странице капча и выполнит вызов WBApp (если капча присутствует). Поясняю: макрос CHECKENTRY проверяет наличие текста img src=”capcha.jpg” alt=”введите текст с картинки” в коде WEB-документа (макрос [DOCSOURCE] выводит код всего WEB-документа, который мы парсим). Если текст, характеризующий наличие капчи присутствует в [DOCSOURCE], то выполняется запуск проекта WBApp и макроса [RELOADDOCUMENT] (этот макрос произведет перезагрузку документа после получения ответных cookies).


2) Вызов нужного проекта WBApp (Internet Explorer (DOM)) из шаблона вывода Content Downloader макросом [WBAPP] для распознавания капчи и получения ответных cookies обратно в Content Downloader:
В пункте 1 мы видели C:\Anticapcha.wbapp – это путь к проекту WBApp, который и будет распознавать и отправлять текст с капчи + возвращать полученные Cookies в Content Downloader. Смотрим http://sbfactory.ru/cd/?p=1515 (Распознавание текста капчи с помощью сервиса Antigate) для того, чтобы составить группу макросов распознавания и отправки текста.

Для того, чтобы вернуть в Content Downloader Cookies из WBApp, вставьте в конец списка событий WBApp макрос [GETCOOKIES_EX]. После такого вызова WBApp, cookies из Internet Explorer должны автоматически вставиться в настройку HTTP-запросов Content Downloader (ctrl+h).

Желаем вам успехов!

1 Star2 Stars3 Stars4 Stars5 Stars (оценок: 1, средний балл: 5.00)
Loading...
Вы можете пропустить до конца и оставить ответ. Pinging в настоящее время не доступны.
Есть 2 коммент. к теме: “Распознавание капчи, отправка текста капчи и получение ответных cookies (с использованием WBApp) при парсинге контента”
  1. Андрей says:

    это снижает количество выдаваемых капч? к примеру от гугла?

    • admin says:

      Нет, количество выдаваемых капч снижает меньшее количество запросов к сайту за единицу времени. Можно выставить 1 поток и подобрать паузу между запросами так, что капча вообще никогда не вылетит. Думаю, для Гугла сейчас эта пауза будет составлять 8000-10000 МС (8-10 секунд).

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

Написать комментарий к admin

Пожалуйста, ознакомьтесь с правилами комментирования (причина УДАЛЕНИЯ некоторых комментариев)

Добавить изображение к комментарию (jpg)