Lain_13
Уже сделал.
Добавлено 23-02-2011 15:21:52
Размер антипорно-подписки сократился с 212.1 КБ до 193.4 КБ. Правда, это отчасти за счёт создания общих правил, но обобщил я на этот раз мало что.
Отсутствует
Small_Z
В правилах блокировки всегда так было.
Есть или нет в конфиге, не знаю (неохота на оф. сайте читать), но даже если есть, включать не советую, потому что подписки на это не рассчитаны. Просто добавляйте $match-case (это опция «учитывать регистр букв» в мастере составления правил) в конце тех правил, для которых это важно. Вообще за всё немалое время, сколько я пользуюсь Adblock Plus и участвую в составлении подписок, я использовал эту опцию всего в одном исключении и то только для подстраховки. В нашей подписке есть одно правило с $match-case , но кажется, само это правило уже давно не нужно и не знаю, зачем там нужен был учёт регистра.
В правилах скрытия не различается регистр в названиях тегов и атрибутов, но различается в значениях атрибутов, и это изменить нельзя.
Отредактировано Радик245 (24-02-2011 12:01:50)
Отсутствует
Радик245
Люди не читают предупреждения. И не знают, зачем щелкают на кнопку "Block" видео, которое смотрят. Увидев диалог они случайным образом выбирают одну из трех кнопок, чтобы от него избавиться - то есть шансы, что они добавять правило, в районе 30%. Сообщения лишь еще раз указали на то, что это серьезная проблема. Для большинства пользователей вполне достаточно возможности отключить Adblock Plus на сайте и отправить сообщение - подписки не идеальны, но мало у кого выйдет лучше.
example.com,example.org,site.org##foo по быстродействию не отличается от отдельных правил по доменам, но по крайней мере стили будут более компактными - а это в теории меньший расход памяти и более быстрый запуск. То же самое касается ##A[href*="foo"],A[href*="something"].
В случае неоптимируемых правил одна регулярка как правило будет быстрее - но и существенно запутанней. Поэтому заменять десяток правил одной регуляркой я все-таки не рекомендую. Adblock Plus преобразует || в ^[\w\-]+:\/+(?!\/)(?:[^\/]+\.)?
В правилах скрытия не различается регистр в названиях тегов, но различается в атрибутах, и это изменить нельзя.
Это свойство HTML - регистр в названиях тегов и атрибутов игнорируется, но значений атрибутов это не касается. В интернете редко, но попадается XHTML (к примеру http://planet.mozilla.org/) - тут регистр букв учитывается всегда.
Отсутствует
В случае неоптимируемых правил одна регулярка как правило будет быстрее - но и существенно запутанней.
Скорее всего, распутывать мне придётся лишь собственное творчество, притом эти правила несложные, одного вида — блокируют определённые слова в начале домена, так что регулярка получается не очень сложная. В нескольких регулярках, которые уже есть в антипорнушке, разбираюсь — надеюсь, и с этой не запутаюсь. А скорость для антипорно-подписки важна: хотя сам я не замечаю, чтобы она тормозила, но жалобы есть (возможно, дело не столько в производительности компьютера, сколько в скорости подключения к интернету — на очень высокой разница с подпиской и без должна быть заметнее). Это несмотря на то, что при нынешнем алгоритме почти все правила, о которых я упомянул, оптимизируются.
И не знают, зачем щелкают на кнопку "Block" видео, которое смотрят.
Такое не лечится… Разве что заменить надпись на «Блокировать видео» — длинно, не очень правильно, когда эта кнопка будет показываться для флеш-анимации, зато защитит хотя бы от части таких нажатий, когда блокируют, потому что думают: «Adblock Plus знает, что нужно блокировать, раз предлагает».
Увидев диалог они случайным образом выбирают одну из трех кнопок, чтобы от него избавиться
А я думаю, что они нажимают только на ту кнопку, которая и позволяет от него избавиться — «Добавить фильтр». А вот то, что в этом диалоге часто по умолчанию предлагаются страшные правила (особенно тогда, когда адрес короткий), знаю точно, и то, что Вы хотите сделать, эту проблему не решит, так как те, кто включит добавление правил (или у кого они уже есть), в большинстве своём будут выбирать то правило, которое предлагает Adblock Plus (точнее, ничего не будут выбирать, а просто нажимать кнопку «Добавить фильтр»). Поэтому моё предложение по совершенствованию мастера составления фильтров не теряет значимости и в случае, если по умолчанию добавление правил будет отключено.
Вместо полного отключения по умолчанию создания правил можно только убрать кнопку «Блокировать», а блокировку изображений через контекстное меню сделать без диалога, по полному адресу (возможно, с автоматической заменой http:// и http://www. на || ). Естественно, с возможностью включить полноценное добавление правил!
Вообще думаю, что достаточно будет доработать мастер добавления правил и заменить надпись на кнопке «Блокировать» на «Блокировать видео» (можно отключить по умолчанию «Показывать ярлык на Flash и Java», но это хуже, чем полное отключение составления правил, потому что почти никто не догадается включить, даже не заметят этой настройки или не поймут, что она значит).
Отредактировано Радик245 (24-02-2011 13:02:10)
Отсутствует
Владимиp Палант
> Adblock Plus преобразует || в ^[\w\-]+:\/+(?!\/)(?:[^\/]+\.)?
1. Что даёт «(?!\/)» после «\/+»? Если я правильно понимаю, то только время тратит на не нужную проверку отсутствия «/» после серии из символов «/». Это имело бы смысл в случае ленивого квантификатора «+?» (который здесь даром не нужен), но в случае обычного квантификатора жадности «+» он сначала сожрёт всю последовательность символов «//», а потом посмотрит непосредственно на следующий символ и лишь убедится в том, что это не «/». Зачем?
2. Почему «(?:[^\/]+\.)?», а не «(?:[^./]+\.)*?»? Ты же заставляешь интерпретатор сначала доходить до конца имени домена, а потом отдавать строку обратно по 1 символу и сверять его с точкой. Сверка не прошла? -1 символ и снова сверка. Прошла? Пытаемся идти дальше.
В моём варианте интерпретатор будет пытаться откусывать целые блоки до точки + точка, а из-за ленивого квантификатора будет стартовать с нуля таких блоков и пытаться этот участок пропустить вовсе.
3. «/» не нужно эскейпить вовсе, а «-» не нужно эскейпить внутри группы если этот символ стоит последним (он не создаёт открытой с одного края последовательности).
Т.е. я предлагаю использовать:
Такая регулярка куда более оптимальна по времени исполнения.
Кстати, согласно POSIX «\w» эквивалентно «[A-Za-z0-9_]», но на сколько я знаю на практике это часто оказывается «любая буква любого алфавита и знак подчёркивания». Как оно реализовано конкретно в JS я не знаю. Если я правильно понимаю, то там никогда не бывает ни чего кроме «[A-Za-z-]+» (причём A-Z тут для ситуации с $match-case и без него можно добавлять просто «[a-z-]+»). Может лучше так?
Отредактировано Lain_13 (24-02-2011 12:57:07)
Отсутствует
Lain_13
1. Правило ||/example.com^ - неправильное и не должно срабатывать.
2. Правило ||example.com^ должно срабатывать и для http://foo.bar.example.com/
3. Можно не эскейпить. Но хуже от этого не будет, а сомнения в правильности регулярки отпадут.
POSIX в данном случае роли не играет, \w в JavaScript признает исключительно латинские буквы. Регулярки в JavaScript ввели слишком давно.
Отсутствует
И не знают, зачем щелкают на кнопку "Block" видео, которое смотрят.
Не потому ли, что "Block" — это не только «блокировать», но и «блокировка». М. б., люди пытаются как раз решить проблемы с «блокировкой», когда видео не воспроизводится по каким-то причинам? Нельзя ли заменить "Block" в англ. локали на какое-нибудь более точное выражение?
Добавлено 24-02-2011 13:19:06
Правило ||/example.com^ - неправильное и не должно срабатывать.
А что плохого в том, что оно сработает? Если кто-то ошибся при составлении правила, то зачем его за это наказывать, тем более за счёт снижения (пусть и небольшого) производительности у всех?
Отсутствует
Владимиp Палант
> Правило ||/example.com^ - неправильное и не должно срабатывать.
Вот и добавь проверку на «||/» с сообщением об ошибке, а не вставляй хак в код, который часто выполняется. Не?
Там и «-» будет неправильно, и вообще что угодно кроме буквы или цифры, на сколько я знаю.
> Правило ||example.com^ должно срабатывать и для http://foo.bar.example.com/
Оно и будет.
> Можно не эскейпить. Но хуже от этого не будет, а сомнения в правильности регулярки отпадут.
У меня они от этого только появляются. Эскейпить можно вообще всё, но регулярка становится трудночитаемой, а она и так не сахар.
Добавлено 24-02-2011 13:35:00
Я б «/+» вообще записал бы как «/++» если б сверхжадные квантификаторы в JS работали (кстати, это был бы самый правильный вариант и в случае ||/ не работало бы).
Отредактировано Lain_13 (24-02-2011 13:39:22)
Отсутствует
Вот и добавь проверку на «||/» с сообщением об ошибке
Да даром никому не нужна вообще такая проверка. Грамотность ради грамотности…
> Правило ||example.com^ должно срабатывать и для http://foo.bar.example.com/
Оно и будет
Ага, работает.
отлично блокирует всё оформление на этом форуме.
Добавлено 24-02-2011 13:46:35
Можно не эскейпить. Но хуже от этого не будет, а сомнения в правильности регулярки отпадут.
А что тут сомневаться, если работает правильно? И зачем усложнять те регулярки, которые используются почти для всех правил, хотя бы лишними эскейпами?
Отсутствует
Вот и добавь проверку на «||/» с сообщением об ошибке, а не вставляй хак в код, который часто выполняется. Не?
То есть, несколько строчек кода и, возможно, дополнительная строка, которую нужно переводить, вместо четырех символов - ради мизерного улучшения производительности?
> Правило ||example.com^ должно срабатывать и для http://foo.bar.example.com/
Оно и будет
Понял, что имелось в виду. На практике разницы не будет, но исправил: https://hg.adblockplus.org/adblockplus/rev/4035e6528db1
Эскейпить можно вообще всё, но регулярка становится трудночитаемой, а она и так не сахар.
Если честно, то она не предназначена для того, чтобы ее читать. Если есть сомнения в правильной работе регулярки - на то есть автоматические тесты.
Добавлено 24-02-2011 13:57:11
Радик245
"Странные" правила, которые поддерживаются сейчас, надо будет поддерживать всегда - их поведение должно будет оставаться тем же, даже если в будущем регулярка изменится. Спасибо, я воздержусь.
Отсутствует
То есть, несколько строчек кода и, возможно, дополнительная строка, которую нужно переводить, вместо четырех символов
Да не нужно ни то, ни другое. Думаю, таких правил и пользователей очень мало будет; и это не стóит усложнения регулярок на четыре символа и замедления загрузки страниц даже на миллисекунду. Как правильно составлять правила, написано на сайте и мастер составления правил наглядно показывает, как их составлять. Я не представляю, в каком случае пользователь может добавить такое правило — по ошибке разве что. В подписках такие правила, надеюсь, не появятся, а пользователи себе новые правила создадут, если это потребуется.
Lain_13 как-то выразился (по другому поводу), что подписка людям мозги не заменит и не надо пытаться сделать это. От себя добавлю, что расширения это тоже касается.
Если не ошибаюсь, раньше в обычных правилах можно было использовать выражения вроде example.com/[to|eto|voteto] — удалили эту возможность и ничего. Не говоря уже про то, что была удалена очень полезная блокировка картинок по ссылкам (ну это, как я понял, вынужденно).
Отредактировано Радик245 (24-02-2011 14:46:05)
Отсутствует
Владимиp Палант
> То есть, несколько строчек кода и, возможно, дополнительная строка, которую нужно переводить, вместо четырех символов - ради мизерного улучшения производительности?
Нет. На самом деле эти несколько строк кода объяснять пользователю _почему_ так нельзя делать и почему это сводит на нет преимущества использования «||». Сейчас же оно просто не будет работать без объяснения причины. Либо делать правильно, либо не проверять этот случай вовсе, я так считаю. А сейчас ты специально ломаешь регулярку так, что б в случае этой по-сути не существенной ошибки не работало. Это просто бессмысленно.
Можно вообще как предупреждение добавить в генератор правил блокировки и забить на проверку вовсе.
Отредактировано Lain_13 (24-02-2011 14:54:22)
Отсутствует
Сейчас же оно просто не будет работать без объяснения причины.
Если правило добавлять с помощью мастера, а не клавиши Insert, то сейчас появляется предупреждение: «Введённый шаблон не соответствует адресу, для которого вы создаёте правило, и никак не повлияет на него». В твоём варианте для правил, которые начинаются с ||/ , этого предупреждения не будет, потому что такие правила работать будут.
Отсутствует
Радик245
example.com/[to|eto|voteto] ни мы, ни Adblock никогда не поддерживали. На самом деле есть ряд "фич" синтаксиса фильтров, сохранившихся исключительно по историческим причинам - я бы рад от них избавиться, но это достаточно сложно. Нужно перевести фильтры пользователя в "современные" варианты и надеяться, что все списки фильтров со временем обновятся. Тогда когда-нибудь можно будет выкинуть код, который занимается переводом. Но на все это нужно много времени, пока что проще сохранять совместимость.
Отсутствует
Радик245
Причина несоответствия не раскрыта + без проверки и без субдоменов мой вариант работать будет, а с субдоменами выведет вон то самое предупреждение.
Добавлено 24-02-2011 15:39:33
Если кто-то напишет через insert «||/» самостоятельно, то ССЗБ. Всё равно доступ к частным правилам будет только у тех, кто теоретически умеет их создавать.
Отредактировано Lain_13 (24-02-2011 15:40:21)
Отсутствует
Владимиp Палант
example.com/[to|eto|voteto] ни мы, ни Adblock никогда не поддерживали.
Да?! Почему тогда _Denis_ предлагал подобное правило (когда оно уже не работало)? Он, может быть,имел в виду регулярку (неправильную), но в подписках Хакруса долго наряду с правилами вроде example.com/files/$image были правила вроде example.com/files/*.[jpg|gif|png] . Помню, я писáл Хакрусу, чтобы он убрал эти правила, потому что уже не работают.
Всё равно доступ к частным правилам будет только у тех, кто теоретически умеет их создавать.
А кто умеет создавать — напишут правильно.
есть ряд "фич" синтаксиса фильтров, сохранившихся исключительно по историческим причинам
Вы о старых правилах скрытия или о чём-то ещё?
Отредактировано Радик245 (24-02-2011 16:01:34)
Отсутствует
Радик245
Потому что _Denis_ и Хакрус путают обычные правила с регулярными выражениями (причем неправильными регулярными выражениями). См. мой ответ там же чуть ниже. Такого синтаксиса никогда не было.
Добавлено 24-02-2011 16:03:26
Вы о старых правилах скрытия или о чём-то ещё?
Да, о них. А также о @@http:// и @@https://, у которых подразумевается $document.
Отредактировано Владимиp Палант (24-02-2011 16:01:46)
Отсутствует
Владимиp Палант
> .replace(/^\\\|\\\|/, "^[\\w\\-]+:\\/+(?!\\/)(?:[^.\\/]+\\.)*?")
Хо-хо! Тебе приходится эскейпить сами слэши в своём собственном коде. Вот уж где несколько лишних точно не добавляет удобочитаемости.
Хотя конечно код расширения мало кому интересен.
Отредактировано Lain_13 (24-02-2011 16:36:42)
Отсутствует
https://reports.adblockplus.org/17be59e … b=requests
Я что-то не могу понять, а что здесь происходит с логом запросов? Посмотри, там в коце больше половины — одни и те-же адреса.
Кстати, забавно, но на этот сайт мне пришло больше сообщений чем на вконтакт и остальные соц-сеточки. Хотя подозреваю, что это один и тот же ж человек делал — там везде эта проблема парсинга списка запросов.
Отсутствует
Lain_13
Это он по навигации слева пощелкал, там картинки каждый раз заново загружаются. В сообщении, в отличии от списка элементов, для каждого запроса своя строчка - независимо от того, одинаковый там адрес или нет. "Открыть все" и "закрыть все" - уже 130 дополнительных запросов.
Отсутствует
Владимиp Палант
Может имеет смысл так не делать? Если хочется узнать сколько было таких запросов — добавь колонку со счётчиком и считай на стороне клиента, а то парсеру вон крышу сносит. Я периодически вижу эту ошибку и далеко не только на этом сайте.
Отредактировано Lain_13 (24-02-2011 18:13:01)
Отсутствует
Lain_13
Не знаю, может и имеет. Парсеру на самом деле все равно, просто я не хочу хранить на сервере слишком много данных.
Отсутствует
Владимиp Палант
Вот это-то и позволит тебе не хранить слишком много данных, разве нет? А то оно аж до лимита по размеру доходит. Можно даже без счётчика, в принципе. Тогда только аггрегатор на клиентской стороне поменять нужно.
Хм… ты это так написал будто цифры занимаю больше чем строки, кстати.
Для счётчика достаточно 2 байт более чем. Для строки их хватит лишь на 1-2 символа. Экономия на повторах колоссальная и ни какой потери информации (кроме порядка загрузки?).
Отредактировано Lain_13 (24-02-2011 19:51:16)
Отсутствует