Поиск статей через SE.

Lasto's Abductor, Похититель буковок Lasto's Abductor, Похититель буковок

Поиск статей поисковыми системами (парсинг SE).

Видимо, наиболее универсальный способ сбора контента на любую тему.
Хотя необходимый и достаточный инструмент дан в этих двух документах:

1. парсер доноров
2. инструкция к парсеру

тем не менее многие не могут постигнуть, даже на уже имеющихся примерах (поиск по Гуглу, поиск по блогам Гугла, поиск по новостям Гугла, поиск по Яндексу и блогам Яндеса), как же пишутся правила парсинга для произвольного ресурса, и поисковика в частности.

Давайте рассмотрим это на примере. Возьмём какой-нибудь тематический каталог статей со встроенным в сайт поиском (для максимальной сложности на собственном движке сайта, а не от Яндекса или Гугла), и напишем для него правило парсинга. Прямо по шагам.

Мастер-класс по парсингу поисковика.

Пусть в качестве пациента выступает kata•log.ru. Почему в качестве донора (хотя бы даже для примера) выбран этот сайт, а не любой из десятков ему подобных, наверное, стоит кратко объяснить.

Имеет немалое значение, откуда мы берём статью. Данный сайт, хоть и имеет какие-то пузомерки, считается низкотрастовым (каковым и на самом деле является), что можно проверить хотя бы тулзой из опуса про эротические будни экономных бородатых дядек. Почитайте, для подумать полезно.

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

Ну и при выборе донора другим глазом надо поглядывать на глубину закромов. Если в закрома заложена 35000 статей, то, наверное, всё-таки стоит потратить пять минут времени на составление правил парсинга этого ресурса.

Хорошо, этот момент понятен. Переходим на ресурс, находим там строку поиска, и вводим в неё запрос "блондинка" (или любой другой). Жмём кнопку, и смотрим на экран, действуя далее по схеме:

  1. Прежде всего, копируем содержимое адресной строки браузера в какой-нибудь текстовый редактор, честно показывающий нам текстовые файлы в ASCII, а не во всяких там UTF-ах. Ибо в адресной строке браузера, чаще всего, Вы видите русские буквы запроса, не понимая при этом, как именно они там закодированы (а варианты возможны).

    В нашем случае всё просто, URL получается без затей:
    http://kata-log.ru/search/?q=%E1%EB%EE%ED%E4%E8%ED%EA%E0

  2. Глядючи на сиё, мы понимаем, что это стандартное кодирование поискового запроса оператором PHP urlencode(); Ибо с виду оно шестнадцатеричное.

    Узрев такую шестнадцатеричность, сразу пишем строчку правил:

    [kata-log.ru][serp][code]=urlencode

    где в первых квадратных скобочках kata-log.ru является выдуманным нами идентификатором для каждой строчки составляемых правил. Этот идентификатор может быть произвольным, но не повторяющимся в правилах парсинга других ресурсов. Так что тупо используем тут домен донора.

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

    1. Донорский сайт в виндовой кодировке, и поисковому запросу "блондинка" в URL-е будет соответствовать указанное ранее.

    2. Донорский сайт в UTF, либо зачем-то перекодирует введённый запрос в UTF. Тогда URL поисковой выдачи будет содержать более длинный вариант, по две шестнадцатеричности на одну букву запроса:

      %D0%B1%D0%BB%D0%BE%D0%BD%D0%B4%D0%B8%D0%BD%D0%BA%D0%B0

      Скорее всего, в адресной строке браузера Вы увидите не это, а обычные русские буквы. Однако текстовый редактор в режиме ASCII покажет всю правду, как оно есть на самом деле.

    В зависимости от того, с чем мы столкнулись (есть перекодировка поискового запроса в UTF или нет), и следует сформулировать вот эту строку правил парсинга донорского ресурса:

    [kata-log.ru][serp][utf8]=false

    Тут у нас перекодировки в UTF нет, что мы и зафиксировали, вписав "ложь".

  4. Теперь поперемещаем курсор над ссылками последующих страниц выдачи.
    Мы видим, что в URL-e появляется &start=10 и далее циферки по нарастающей.

    Значит, URL страницы с результатами поиска должен выглядеть так:

    [kata-log.ru][serp][url]=http://kata-log.ru/search/?q====query===&start====page===

    куда вместо ===query=== и ===page=== скриптом по мере надобности подставятся запрос и номер страницы выдачи соответственно.

    Так же мы уже понимаем, что инкремент при перемещении между страницами выдачи равен 10 (а не единице, как обычно), что тут же находит отражение в соответствующей строчке правил прсинга этого ресурса:

    [kata-log.ru][serp][page]=10

  5. Теперь пришла пора заглянуть в код страницы.
    Берём один из сниппетов - пусть он будет вот таким на взгляд и код:

<!-- Block_item -->
 
<span style="color:grey;margin-left:-5px;">5.</span> 
<a class="CategoryItem" href="/education/blondinka-s-rodoslovnoy.html"><b>Блондинка с родословной</b></a> <br>
Некоторые директора компаний ищут секретарей по нескольку месяцев. Один из клиентов искал девушку "с мужским складом ума, с хорошим воспитанием, образованием и происхождением, и чтобы была очаровательна и красива". <br/>
<div class="result_info">Категория: Образование | Автор: <a href="/profile/margo-223.html">Марго</a>
| Добавлено: 26.02.2007 </div>
<br>
 
<!-- /Block_item -->
  1. Нам нужно написать регулярку для извлечения из этого сниппета URL-а статьи.
    И самое простое, что приходит на ум, выглядит так:

    [kata-log.ru][snip][tmpl]=<a class=\"CategoryItem\" href=\"(.+)\">

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

  2. Если вдруг окажется, что для формирования сниппетов донорский сайт не использует никаких специальных классов в HTML коде, и вот такой вот простой регуляркой отделаться не получается, а приходится включать в регулярку помимо HTML тегов ещё и какие-то слова на русском языке (формирующие "опалубку" сниппета), внимательно смотрим на кодировку страницы выдачи донора. По метатегам кодировка устанавливается сразу.

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

    [kata-log.ru][snip][1251]=false

  3. Теперь обратите внимание на локальные адреса статей в коде сниппета. Естественно, их необходимо перевести в абсолютные, что делается указанием абсолютного адреса страницы, на которой выводятся такие сниппеты. Скрипт сам сообразит, к чему привязаны ссылки (к корню сайта или к текущей странице выдачи), и произведёт все необходимые преобразования.

    [kata-log.ru][snip][url]=http://kata-log.ru/search/

  4. Иногда бывает, что адреса статей в сниппетах закодированы, и прямо сверкают шестнадцатеричностями. Понятно, что такие URL-ы предстоит сперва привести к нормальному виду, для чего и существует специальная запись. Тут она не используется, ибо никакой кодировки адресов статей мы не наблюдаем. Но читайте инструкцию - у сервисов Гугла всё несколько сложней.

Теперь сведём все эти обрывки правила парсинга в один блок:

[kata-log.ru][serp][url]=http://kata-log.ru/search/?q====query===&start====page===
[kata-log.ru][serp][utf8]=false 
[kata-log.ru][serp][code]=urlencode
[kata-log.ru][serp][page]=10
[kata-log.ru][snip][tmpl]=<a class=\"CategoryItem\" href=\"(.+)\">
[kata-log.ru][snip][1251]=false
[kata-log.ru][snip][url]=http://kata-log.ru/search/

Эти строчки заносятся в поле формы Правила поиска статей на донорских ресурсах:
Естественно, тут имеется ввиду не демо админки, а реальная админка Вашего сайта.

Далее на этой же странице админки в одном из полей формы "Правила наполнения разделов:" (то есть для какого-то из разделов Вашего сайта) должно быть создано задание по извлечению статей с нашего "поисковика".

Договоримся, что собирать статьи про блондинок (или про кого угодно) мы будем с первых двух страниц выдачи "поисковика". Или со страничек в любом другом диапазоне, но обычно вебмастер собирает ссылки на топовые статьи, ибо чем дальше в лес, тем страшнее девки.

Сама запись проста и наглядна:

[kata-log.ru][блондинка][1-2]=

- то есть скрипту нужно взять в руки правила парсинга с идентификатором kata-log.ru, и выдрать с первых двух страниц выдачи по запросу "блондинка" все ссылки на представленные там статьи. Каковые потом и будут импортироваться в отдельном процессе.

Замечание.

Хотя такая система организации правил парсинга и не блещет особой наглядностью и очевидностью, она избавляет пользователя от написания фрагментов парсера на PHP, Python, и прочих языках программирования. Которыми пользователь вовсе не обязан владеть.

Просто применяем этот конструктор вариантов, и получаем результат.

Регулярные выражения RegExp при этом нужно знать, хотя бы на начальном уровне. Они используются повсеместно, даже в JavaScript, и в perl-совместимом варианте имеют сходный синтаксис для любого языка. В связи с чем любой учебник для начинающих по регуляркам тут будет уместен, и даст превосходный результат.

Тренировка:

Админка скрипта содержит раздел, помогающий оттестировать создаваемые правила парсинга, не перенося их на сам сайт. Так сказать, "в песочнице".

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

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

Важно:

Хотя в настройках парсера доноров есть всё, чтобы работать с ними через прокси, на самом деле Вам не нужно (и не придётся) заморачиваться ни с какими прокси. И вот почему:

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

    Для импорта нескольких статей в сутки совершенно достаточно распарсить десяток страниц Гугла (или иного поисковика). За этот десяток запросов в сутки никто Ваш сайт блокировать не будет, и никакие прокси не понадобятся вовсе.

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

  3. Замечено, что тот же Гугл, замечательно отдавая свой серп напрямую, отказывает в обслуживании при использовании рабочего и проверенного прокси. Стало быть, у искалки имеется чёрный список айпишников, который пополняется в том числе и проксями.

  4. Коннект через прокси долог, глюкав, и часто отрубается по таймауту.

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