Парсилка контента

Да это так!

защитить... думаю не реально...)

Виктория Родочинская добавил 05.03.2008 в 17:40

хотя могу узнать у папы, может быть он что подскажет...

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

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

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

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

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

А вы не боитесь, что первым, кто обломается такой документ парсить будет яндекс или гугл?

А потом, у вас же всё равно структура будет одинаковая. Ну будут разные стили/теги. Но общая-то структура останется...

Если захотят, заточат парсер под любой набор.

Смена стилей и набора тегов на пс никак не повлияет, т.к. оформление их интересует в меньшей степени, чем сам контент.

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

ну вот я и хочу посмотреть.. вот в частности на теги типа <p id=949075> или <br id=09374> которые и в оформлении и в контенте встречаются, яндексу пофиг асболютно будет.. а вот парсилка не осилит узнать где нужный кусок.. Логика такая примерно... но я не знаком с парсилками, поэтому интересуюсь как они работают

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

Все последующие регулярные совпадения будут обработаны существенно быстрее (PCRE кеширует выражения), чем первое, поэтому при обработке больших объёмов текста регулярные выражения могут быть существенно быстрее строкового поиска...

Конкретно тех скриптов нет и чего там выпарсилось, я уже и не помню. Поэкспериментируйте :)

Вот перловый скрипт:

#!/usr/bin/perl



open LOG, '<', 'access.log';

while (my $line = <LOG>) {

    if ($line =~ /(GoogleBot|Slurp)/i) {

        # do something

    }

}

close LOG;

Вот на php:

#!/usr/local/bin/php

<?php

$fp = fopen('access.log', 'r'); 

while ($line = fgets($fp)) {

    if (preg_match('/(GoogleBot|Slurp)/i', $line)) {

        # do something

    }

}

?>

Попробуйте поменять паттерны на свои, добавить какую-то логику... В общем, пофантазируйте ;)

Неверно Вам кажется :)

Зачем загонять огромный файл в память, когда можно открыть поток и просто читать его построчно? Для запоминания текущей позиции курсора в потоке нужно гораздо меньше памяти, чем 8М.

огромное спасибо...

хотела бы заметить, что если взять 100 метровый файл к примеру и загнать его весь в буфер и после этого сделать 1 регексп то это будет на многооооо быстрее если делать 1000чи регекспов читая блочно...

А Вы проверьте, попробуйте (я про загнать большой файл в файл) ;)

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

От Яндекса и Google тоже хотите защитить? 🙄

Слава Шевцов добавил 06.03.2008 в 04:05

Время чтения с диска либо гиг в секунду, либо не учитывалось. Обычно 2Гб/60Мб/сек ~ 35 сек 🙄

Часто парсите такие логи? 🙄 PHP работает достаточно быстро. В любом случае строковыми функцими быстрее написать и отладить парсер, чем вспоминать Перл с его трудночитабельным кодом и регулярками. То есть код получится дешевле. Хотя если двухгигабайтный лог надо парсить каждый день, то можно и о Перле подумать. Или о С++ 🚬