1. $NEST() очень полезен для правильного захвата и обработки тегов вроде:

Код:

<img src=forward.gif alt=">">

Был у нас по началу работающий вариант без $NEST(), только с ним гораздо проще и понятней.

2.

Код:

Name = "New HTML filter" Active = FALSE Limit = 256 Match = "<script*</script>" Replace = "<!--removed-->"

Тест:

Код:

<script> </script> <script> </script>

Результат:

Код:

<!--removed--> <!--removed-->

To: Unknown Mystic

Какой ты хитрый, в задаче написано:

Цитата:

Попробуй к примеру грохнуть многострочный java скрипт по ключевому слову, используя исключительно "Язык сравнения Проксомитрона" и не прибегая к "Специальным командам Проксомитрона"

Про ключевое слово там ничего не написано разве? Нужно внимательнее читать!

А вот твой вариант но уже с ключевым словом "baner":

Код:

Name = "New HTML filter" Active = FALSE Limit = 256 Match = "<script*baner*</script>" Replace = "<!--removed-->"

Текст:

Код:

<script> Code 1 </script> Text 1 <script> baner </script> Text 2 <script> Code 3 </script>

И результат:

Код:

<!--removed--> Text 2 <script> Code 3 </script>

Вопрос - КУДА ДЕЛСЯ ПЕРВЫЙ СКРИПТ и ТЕКСТ, который не имеет блокируемого ключевого слова, но был почему-то удален совместно со вторым скриптом!!! Без $NEST() у вас работал только условно, т.к. прокатывал параметр "Limit = 256"

Низачот!!! Кто следующий?

Добавление... И чтобы картина была полной, не забывайте, что скрипт может нести в себе динамический html, который в свою очередь может содержать последовательности "</..>" и "<..>"!!!

Виноват :)

Код:

Name = "New HTML filter" Active = FALSE Limit = 256 Match = "<script*baner*</script&&"         "(^*</script>)*" Replace = "<!--removed--"

А как наскет регекспа? ;)

Добавлено 16:12
Вопрос снимается :)

Код:

/(.*)<script>.*baner.*?<\/script>(.*)/

А

Код:

$NEST(<script>,*baner*,</script>)

коротче и красивей :)

Добавлено 16:27

Код:

Name = "New HTML filter1" Active = FALSE Limit = 256 Match = "<([a-z]+)\1&"         "($NEST(<$TST(\1)>,*baner*,</$TST(\1))&&"         "(^*</$TST(\1)>)*)" Replace = "<!--removed--"

А как насчет убирания произвольного тега, содержащего "плохие" слова, на регекспах? ;)

То: Unknown Mystic

Справился, чуствуется рука специалиста

А вот реализация аналогичного фильтра для привокси (на регэкспах)

s@</script>@<\escript>@sig
s@<script[^\e]*?(show_ads|hotlog|spylog|random|88|31).*?<\escript>@<!-- JS blocked by word (MM) -->@sig
s@\e@/@sig

Первый шаблон помечает символом '\e' конец скрипта
Второй шаблон производит поиск "плохих" слов
Третий шаблон удаляет пометку конца скрипта.

Это единственный (мне известный) работоспособный способ реализации данного фильтра на привокси на основе регэкспов. Может кто знает лучше способ?

Я вообще-то privoxy или как там не знаю...
Как оно вообще работает? Что первая строка делает?
Оно заменяет только первый "/" из закрывающего тега скрипта или же все "/"?
Потому как, если говорить терминами прокса, сдается мне, что у тебя то ли заданы границы, то ли вообще 3 фильтра...

Как оно со вложеными скриптами (тегами) работает? Для чего $NEST() как раз очень полезен.

Не вижу аналога для New HTML filter1 :))

Вот ещё была похожая тема.
Особенно с вот этого поста.

Пожалуй, скромно процитирую, что я там год назад писал:

Цитата:

По-моему, основная разница в том, что усложнение фильтров на PCRE обусловлено синтаксическими особенностями, а на языке Прокса -- существенной частью. Т.е. в Проксе чем сложнее (логически) структура искомого выражения, тем труднее его описать. А на регэкспах чем больше, тем труднее, а сложность почти не влияет, т.к. сам язык мощнее и многое умеет. Например, в приведённых примерах фильтров для Прокса надо иметь ввиду, что пробел означает (в терминах регэкспов) "\s*", знак "равно" означает "\s*=\s*", двойная кавычка означает "["']" и т.п. Т.е. всё предназначенно для фильтрации HTML-кода, поэтому почти всё делается проще, чем на регэкспах.

Цитата:

Цитата: PCRE-это стандарт, который постоянно пользуются многие, а встроенный язык Proxomitron - это продукт творческой деятельности его разработчика, с которым даже профессиональным программистам на Perl ещё разбираться надо будет Так и есть. И в этом основная разница: Прокс рассчитан не на профессионально больных Перлом, а на нормальных юзеров, которые хотят удобно и эффективно получать результат. В данном случае язык регулярных выражений -- это такой недружественный к юзеру, но неизбежный шаг, направленный на радикальное повышение функциональности по-сравнению с различными интерфейсными (GUI) решениями для аналогичных задач. Но использовать для этого намного более сложный язык, будь он трижды стандарт, смысла нет. А то придём к тому, что надо интерпретатор Си использовать: на нём-то точно ВСЁ можно сделать. Есть ещё один аспект, который в большей степени представляет моё частное мнение, чем предыдущие, более-менее аргументированные высказывания. Я считаю, что Scott R. Lemmon (автор Proxomitron) был не просто талантливым программистом, он был-таки гением. Именно поэтому у него хватило смелости отойти от канонов и создать нечто лучшее, чем любимый миллионами язык PCRE. И многого из его решений мне, как программисту, не хватает в стандартных регэкспах. А то, что технология стала индустриальным стандартом, никогда не говорило о том, что это лучшая технология.

To: Unknown Mystic

Фильтр один, правда работает он в 3 захода (состоит из 3 шаблонов)... и границ, как не странно нет!

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

MortalMan писал(а):

Фильтр один, правда работает он в 3 захода (состоит из 3 шаблонов)... и границ, как не странно нет! :)

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

MortalMan ,

Цитата:

По поводу "жадности" прокса - символ "*" съедает все символы до самого последнего совпадения (см. описание), поэтому вам не от хорошей жизни приходится прибегать к конструкциям типа $NEST $INEST и прочим ухищрениям, а так же выставлять границу поиска.

1. Как раз сам посмотри описание

Цитата из справки:
В основном, звездочка значит "искать вперед на соответствие чему-нибудь, пока вы не найдете то, что следует за звездочкой"

Т.е. если есть входная строка axxx и соответствие a*x (в замене пусто), то на выходе будет xx.
А на регеспах при соответствии a.*x выходная строка будет пустой.

И $NEST нужен не из-за того, что Прокс захватит больше, а для ограничения диапазона поиска при присутствии вложенных тегов.
Попробуй свой вот этот фильтр

Цитата:

s@</script>@<\escript>@sig s@<script[^\e]*?(show_ads|hotlog|spylog|random|88|31).*?<\escript>@<!-- JS blocked by word (MM) -->@sig s@\e@/@sig

примени на скриптах, которые имеют вложенные скприты, т.е. на конструкции вида

Цитата:

<script> show_ads <script> проверка </script> <script>

или

Цитата:

<script> проверка <script> show_ads </script> <script>

На выходе твоего фильтра будет такое:
</script>

To: unreal666

Откуда же ты такой умный взялся? Где же ты видел незамаскированный вложенный скрипт? На каком браузере ты сможешь выполнить фрагмент своего вложенного java кода?

Проверь на браузере этот вариант:

Код:

<script language="JavaScript" type="text/JavaScript"> function eml(name, server, zone) {document.write(''+name+'@'+server+'.'+zone+'');} </script> <script> eml('mortalman', 'jabber', 'ru'); </script> <script>eml('mortalman', 'jabber', 'ru');</script>

Ты увидешь строку -

Код:

имя@jabber.ru имя@jabber.ru

А вот твой вариант с вложенным скриптом:

Код:

<script language="JavaScript" type="text/JavaScript"> function eml(name, server, zone) {document.write(''+name+'@'+server+'.'+zone+'');} </script> <script> eml('mortalman', 'jabber', 'ru'); <script>eml('mortalman', 'jabber', 'ru');</script> </script>

И что ты увидел? Ничего!!!

Этот вариант был проверен на ie, Firefox и Опере, и не в одном он не заработал!!! Может ты покажешь, как его без маскировки заставить работать? Если так дальше пойдет, то ты мне скоро про трижды вложенный <img src=...> говорить начнешь

To: Unknown Mystic

Не знаю, с какой скоростью раборает Проксомитрон, но могу заметить следующее: у меня на сайте для поддержки модулей (новости, документы, коментарии, пользователи...) работает модуль обслуживания БД собственного формата, ну вот нет резона использовать mysql и все. Когда я писал этот модуль, приходилось постоянно его тестировать на производительность (основная обработка реализована на регэкспах). И получается, чтобы используя поиск выдать произвольных 10 строк базы, (10 000 строк, 5мб) потребовалось чуть больше 0,6 секунды!!! А шаблоны там по сложности и количеству намного превышают этот шаблон "s@</script>@<\escript>@sig". Да и любой шаблон, что я пишу для привокси проходит тестирование по скорости, т.е. на локальном сервере создается тестовая страница (1 мб), грузится скриптом и подсчитывается время работы шаблона. Если оно слишком велико, то его или оптимизирую, или отказываюсь от него вообще.

To: chAlx
Вот от c++ на банерезке я бы не отказался...

To: unreal666

Насчет жадность проксомитрона признаю - был НЕ ПРАВ!!!

Цитата:

И получается, чтобы используя поиск выдать произвольных 10 строк базы, (10 000 строк, 5мб) потребовалось чуть больше 0,6 секунды!!!

Помоему это не круто... Хотя конечно от условий на выборку зависит...

А насчет скорости прокса... На первых 30К (больше тест не позволяет) сайта IXBT (правда я их когда-то давно копировал, ну да не важно) среди фильтров, которые я использую только 1 работает ~2,5 мс. Остальные меньше 1мс.
Мне быстродействия вполне хватает, даже когда работает дебаговая конфига, где фильтры присутствуют в двойном и более экземпляров, есть даже один, который ~6,5мс работает. Но, помоему, этого все равно вполне достаточно. Тем более, что бы фильтр работал так долго, он должен либо быть очень извратным, либо криво написаным...

Unknown Mystic писал(а):

Помоему это не круто... Хотя конечно от условий на выборку зависит...

Это очень даже круто!!! Можешь сам посчитать, что на одну только загрузку файла (5 мб) нужно около 0.3-0.4 сек., правда при тестировании я его не учитываол, т.к. на это время повлиять никак не мог. В указанное мною время входило получение заголовочных полей базы, поиск конкретного поля и вывод результата в хэш...

А в случае использовании тестового файла шаблон на нем выполняется в цикле, чтобы получить более точную величину времени.

Ну не знаю... Свои поиски я не писал, так что судить не могу, но... Если бы все выборки и запросы к таблицам так работали...
Вот мне запросы приходится делать из кучи таблиц, некоторые из которых здоровые...
Вот например запрос из 6 таблиц.
1,2 по ~200k записей
3 - 75k
Остальные сравнительно маленькие. Условия на два разных текстовых поля. Результат - 12 записей. Время выполнения:
Execute time = 2s 516ms

А вообще, что то мы совсем в оффтоп ушли...

MortalMan ,
Ладно. Со скриптами ты уговорил, без маскировки не получится. Но кроме скриптов есть обычные вложенные теги. С ними такое не прокатит. Короче проехали.

Такой вопрос.

Скачал я с сайта privoxy.asplinux.net rpm-пакет (privoxy-3.0.3-8b2.src.rpm), вытащил из него исходники. При компиляции Visual Studio 2003 .NET выдал такое:

Цитата:

s:\Privoxy\pcre\config.h(4): fatal error C1083: Не удается открыть файл include: '../config.h': No such file or directory s:\Privoxy\jcc.c(606): fatal error C1083: Не удается открыть файл include: 'pthread.h': No such file or directory s:\Privoxy\errlog.c(247): fatal error C1083: Не удается открыть файл include: 'pthread.h': No such file or directory s:\Privoxy\cgi.c(479): fatal error C1083: Не удается открыть файл include: 'pthread.h': No such file or directory ....

Посмотрел, и в правду таких файлов нет в папке privoxy.
Где они?
И сайт mortalman.webhost.ru умер что ли?

unreal666 писал(а):

Такой вопрос. Скачал я с сайта privoxy.asplinux.net rpm-пакет (privoxy-3.0.3-8b2.src.rpm), вытащил из него исходники. При компиляции Visual Studio 2003 .NET выдал такое: Цитата: s:\Privoxy\pcre\config.h(4): fatal error C1083: Не удается открыть файл include: '../config.h': No such file or directory s:\Privoxy\jcc.c(606): fatal error C1083: Не удается открыть файл include: 'pthread.h': No such file or directory s:\Privoxy\errlog.c(247): fatal error C1083: Не удается открыть файл include: 'pthread.h': No such file or directory s:\Privoxy\cgi.c(479): fatal error C1083: Не удается открыть файл include: 'pthread.h': No such file or directory .... Посмотрел, и в правду таких файлов нет в папке privoxy. Где они? И сайт mortalman.webhost.ru умер что ли?

Я использую сборку под windows взятую с http://sourceforge.net/projects/ijbswa/
Мой сайт помер, пишут, что в связи со сбоем электричества вышел из строя винчестер Придется заливать на ФТП по новой.

Unknown Mystic писал(а):

Ну не знаю... Свои поиски я не писал, так что судить не могу, но... Если бы все выборки и запросы к таблицам так работали... Вот мне запросы приходится делать из кучи таблиц, некоторые из которых здоровые... Вот например запрос из 6 таблиц. 1,2 по ~200k записей 3 - 75k Остальные сравнительно маленькие. Условия на два разных текстовых поля. Результат - 12 записей. Время выполнения: Execute time = 2s 516ms

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

А вообще-то я не очень понял причем тут твой модуль...

Unknown Mystic писал(а):

А вообще-то я не очень понял причем тут твой модуль...

В плане скорости... см свой предыдущий пост...