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

123
[Удален]
#11
_Ad:
А как нынче работают парсилки контента? Хочется защитить контент сайта (15 000 страниц).
Я правильно понимаю, что он выдирает контент заключенный между определенными тегами? Хотелось бы поподробней

Да это так!

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

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

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

[Удален]
#12

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

_
На сайте с 24.07.2002
Offline
299
_Ad
#13

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

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

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

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

Skom
На сайте с 02.12.2006
Offline
157
#14

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

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

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

Cras amet qui numquam amavit quique amavit cras amet
[Удален]
#15

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

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

_
На сайте с 24.07.2002
Offline
299
_Ad
#16
Skom:
А вы не боитесь, что первым, кто обломается такой документ парсить будет яндекс или гугл?
А потом, у вас же всё равно структура будет одинаковая. Ну будут разные стили/теги. Но общая-то структура останется...
Если захотят, заточат парсер под любой набор.

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

N
На сайте с 15.08.2007
Offline
5
#17
Виктория Родочинская:
все зависит от реализации!
какие маски регекспов или используете ли вы вообще регекспы...(они тормозные... жуть бррр...)
а не от того, что это перл или пхп....

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

Все последующие регулярные совпадения будут обработаны существенно быстрее (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
}
}
?>

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

Skom:
По дефолту, пхп 8 мегами памяти ограничен.
Почему-то мне кажется, что если ему сказать memory_limit 500M, то он будет парсить поменьше, чем 3 минуты :D
Конечно перл будет почти всегда быстрее. Он же для регекспов и сделан.
Просто из-за сиюминутной задачи вникать в особенности работы с перлом не всегда необходимо.

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

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

[Удален]
#18

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

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

N
На сайте с 15.08.2007
Offline
5
#19

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

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

Слава Шевцов
На сайте с 23.07.2005
Offline
370
#20
_Ad:
А как нынче работают парсилки контента? Хочется защитить контент сайта (15 000 страниц).
Я правильно понимаю, что он выдирает контент заключенный между определенными тегами? Хотелось бы поподробней

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

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

nopox:
Использовать php для парсинга большого объёма текста не очень желательно. Скорее даже очень нежелательно. Нет, я помимаю, что и микроскопом можно забивать гвозди, но для этого существуют гораздо более подходящие средства.

Для примера:двухигабайтный лог апача перлом парсился уть больше двух секунд. А пхп скрипел почти три минуты =)

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

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

Неизменность точки зрения неизменно порождает иллюзию понимания.
123

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