Парсинг статей.

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

Парсинг статей.

Никаких особых настроек (типа регулярок и чего-либо в том же духе) тут не предусмотрено, но хотя бы на уровне алгоритма Вы должны знать, как это работает:

  1. Получив URL статьи для её парсинга, скрипт открывает исходящее соединение до сайта-донора, посылает запрос на получение контента, и ждёт ответа. Секунд десять.

    Если за это время никакого ответа не поступает, по всё равно какой причине (к примеру, сайт в дауне), скрипт считает выданный ему URL не кошерным, ставит на нём крест, и более к нему не возвращается.

  2. Если донорский ресурс откликнулся, то этот отклик анализируется.

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

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

  3. В случае, когда по ссылке открылся документ со статьей (хоть по изначально прямой ссылке, хоть после вменяемого числа редиректов с 301 и 302 хедером), скрипт анализирует всю доступную информацию, которую можно почерпнуть из открывшегося документа:

    1. Кодировка документа может быть разнообразной, и постулироваться как метатегом, так и хедером самого документа, без явного указания кодировки в HTML коде.

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

      Правильно поймутся Windows-1251, UTF-8, KOI8-R.
      То есть то, в чём могут жить русскоязычные статьи.

    2. За заголовок статьи изначально принимается её тайтл.
      В HTML коде должен быть такой метатег.

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

    3. Сам контент (текст статьи) детектируется математически, по распределению русских буковок в объёме статьи. Буковки всегда можно сосчитать, и построить график плотности их распределения. А потом с помощью гауссиана (или любой иной кривульки) предположить, что именно стоит считать контентом с наибольшей вероятностью, а также откуда и докуда в коде документа он простирается.

      Метод, конечно, не стопроцентный, и изложен предельно упрощённо.
      Но работает неплохо.

    4. После детектирования области контента из этого участка кода вычищаются все Джава скрипты, формы, комментарии, ифреймы, и вообще всё, что не является текстом.

      Обратите внимание, что таблицы вырезаются также. Как и все прочие теги, не являющиеся параграфом, переносом, списками (нумерованными или ненумерованными).

      Исключением являются картинки, которые из текста не изымаются, а при их наличии в удаляемых таблицах, из таблиц вытаскиваются, и кладутся на место удалённой таблицы.

    5. Сильно поменявшееся форматирование скрипт пытается откорректировать.
      Не трогая разбиение на абзацы.
      То бишь не внося отсебятину в смысловые блоки статьи

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

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

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

Ограничения при импорте статей.

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

  1. Качество текста импортируемой статьи.
    Под качеством текста тут скорее понимается чистота его кода.

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

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

    Не присваивайте рассматриваемому параметру значения ниже 50%, и Вам не придётся в области модерирования остервенело жать на ссылку "удалить это с глаз долой".

  2. Минимальная длина импортируемой статьи.

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

  3. Максимальная длина импортируемой статьи.

    Противоположный по смыслу ограничитель.
    В жанре "не осилил, много букв".

  4. Фильтры кейвордов.

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

    В качестве критерия удобно выбрать точное вхождение ключевика.

    Простой пример.

    Допустим, сайт живо интересуется сателлитами, под чем подразумевает вспомогательные сайты для продвижения СДЛ. Это SEO ниша. Между тем поисковик, как бы тщательно мы не составляли поисковый запрос для парсера поисковика, может поместить в выдачу на наш запрос и что-то про акустические сателлиты (колонки, динамики, и т.п.)

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

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

    Будет полезен какой-нибудь наглядный пример заполнения такой формы.
    Ключевики и их вес вписаны навскидку, без долгого анализа:

колонки=-1000
акустика=-1000
акустический=-1000
акустическая=-1000
SEO=100
дорвеи=100
сайт=50
сайты=50
доры=50
вебмастер=20
SE=30
яндекс=70
гугл=70
оптимизация=20
продвижение=30
продвигать=30
раскрутка=40

Работа с изображениями.

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

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

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

  1. Исходно прописанный изображению класс удаляется, в тег подставляется URL изображения на своём, а не донорском, хосте, а высота и ширина изображения указываются атрибутами тега. Эти параметры считываются прямо с физической картинки на своём хосте.

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

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

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

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