Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
Вы бы под кат убрали топик…
Эм… Всё это хорошо, но можно увидеть пример применения?
Мб мой вопрос странный, но что даём на вход и где здесь выход?
Мб мой вопрос странный, но что даём на вход и где здесь выход?
копируем выражение, идем по ссылке в заключении. Там вставляем и смотрим. Не забываем поставить галочку на «global» поиск
И-и-и… выражение вставлено, css вставлен, сверху тот же css без переноса строк, я счастлив)))
Я очень рад, то Вы счастливы. Теперь можете посмотреть в поле «Result» или в правый верхний угол, увидите разбор выражения на части. Если ничего не выводится, просто нажмите 2 раза на галочку «global». Вот что у меня
К сожалению, тоже ничего не работает. Справа одни циферки, а в поле Result отсутствует подсветка, что эквивалентно «сверху тот же css без переноса строк».
А проверять выражение на корректность кто будет? Или
К тому же, вы действительно полагаете что разбор строки это самый медленный этап в задаче поиска DOM элементов по CSS селекторам?
@#%([[^&*=1] — это корректное выражение?К тому же, вы действительно полагаете что разбор строки это самый медленный этап в задаче поиска DOM элементов по CSS селекторам?
в JavaScript — абсолютно уверен. Так как я реализовал такой парсер. И он на 10 мс быстрее чем jQuery, на 5мс — за yass в FF3.0 тестировал. Но статья не о том.
К сожалению "@#%([[^&*=1]", мне не удалось найти на странице :)
К сожалению "@#%([[^&*=1]", мне не удалось найти на странице :)
Скажу прямо, это не просто спорно, это вопиюще неправдоподобно.
На чем основываетесь? Что по-вашему быстрее (в JavaScript)? Вызов в цикле метода «exec» или же 1 «match»?
Да какая, собственно, разница. Все равно потом в лучшем случае с помошью браузера, в худшем вручную, перебирать элементы на странице в поисках удовлетворяющих условию.
ну вот теперь моя очередь сказать прямо. Основываясь на вашем последнем ответе, я думаю, что Вы вообще не знаете особенностей JavaScript. Так как разница есть.
P.S.: в jQuery сделано через «exec».
P.S.S.: перебор очень прост, единственная сложность — это чтобы элементы в коллекции не повторялись. Решение этой проблемыспер позаимствовал у реализации yass
P.S.: в jQuery сделано через «exec».
P.S.S.: перебор очень прост, единственная сложность — это чтобы элементы в коллекции не повторялись. Решение этой проблемы
Простите, вы тестировали на странице из 2-х элементов или из пяти, что их перебор занимал у вас ничтожное время? Можете привести реальные тесты, сколько времени занимает разбор строки и выборка элементов?
Я уже написал… Статья не о том! Тесты проводились точно такие же, как на сайте yass. Не уверен как сейчас, но раньше автор yass проводил тесты на этой страничке, то есть на самой документации, где DOM элементов предостаточно.
Думаю дискуссию стоит остановить, так как это бессмысленно сейчас. Хотите пообщаться пишете мне в личку
Думаю дискуссию стоит остановить, так как это бессмысленно сейчас. Хотите пообщаться пишете мне в личку
> чтобы это написать сделал анализатор регулярных выражений на JavaScript
А RegexBuddy чем не устроил?
P.S. Есть даже генератор RegexMagic
А RegexBuddy чем не устроил?
P.S. Есть даже генератор RegexMagic
Я знал, что есть online решения. Но понимаете, когда в чем-то новичок, то чтобы стать профи нужно все потрогать своими руками. Это ИМХО
Это оффлайн решение, весьма полезное как раз для новичков, существует достаточно давно. Сам c ним познакомился когда изучал regular-expressions.
Есть еще Regex Coach, халявен, написан на Лиспе.
Начинает напоминать brainfuck
«Если у вас есть проблема и вы решили использовать регулярные выражения, чтобы решить её ....»
Здравствуйте.
На мой взгляд, текст статьи довольно сумбурный и содержит ошибки. Взять хотя бы первую фразу: «В общем, наверное, как и другой любой начинающий JavaScript прогрммист (2 года назад), мне хотелось все реализовать своими руками.»: одна грамматическая и три стилистические ошибки, но самое главное — непонятно, о чём вообще речь. Поэтому поставил минус, несмотря на то, что тема может быть интересной.
Удачи.
На мой взгляд, текст статьи довольно сумбурный и содержит ошибки. Взять хотя бы первую фразу: «В общем, наверное, как и другой любой начинающий JavaScript прогрммист (2 года назад), мне хотелось все реализовать своими руками.»: одна грамматическая и три стилистические ошибки, но самое главное — непонятно, о чём вообще речь. Поэтому поставил минус, несмотря на то, что тема может быть интересной.
Удачи.
Регулярки — это хорошо, но вот пара моментов смущает.
Во-первых — а какая задача стояла перед автором?
Во-вторых — есть RFC или как их там, доки стандарта, там наверняка есть схема чего где идти должно, где буквы, где цифры. Конструкция вида "[^"]" мягко говоря смущает.
В-третьих — не стесняйтесь пользоваться сохраняющими скобками, если у вас там кавычки разные — смысла нет лепить вилку на 3 случая, лучше использовать ссылку на сохраненный элемент.
В-четвертых — предварительная оптимизация — ммм… бессмысленное времяпрепровождение. Приятное, но бессмысленное. Эдакая полировка сферического коня в вакууме.
И последнее — не лепите все руками. Есть либы, есть фреймверки, написанные талантливыми людьми не от хорошей жизни. Пользуйте их.
Во-первых — а какая задача стояла перед автором?
Во-вторых — есть RFC или как их там, доки стандарта, там наверняка есть схема чего где идти должно, где буквы, где цифры. Конструкция вида "[^"]" мягко говоря смущает.
В-третьих — не стесняйтесь пользоваться сохраняющими скобками, если у вас там кавычки разные — смысла нет лепить вилку на 3 случая, лучше использовать ссылку на сохраненный элемент.
В-четвертых — предварительная оптимизация — ммм… бессмысленное времяпрепровождение. Приятное, но бессмысленное. Эдакая полировка сферического коня в вакууме.
И последнее — не лепите все руками. Есть либы, есть фреймверки, написанные талантливыми людьми не от хорошей жизни. Пользуйте их.
задача стояла написать эффективное регулярное выражение. Конструкции вида "[^"]" — я использовал, для того чтобы в селекторах можно было писать свои регулярные выражения, а также любой текст, например для псевдо селектора ":contains()".
Хотел сделать быстрый разбор строки, а в JavaScript самый быстрый способ это сделать — использовать регулярное выражение.
Я не использовал обычных круглых скобок из-за того, что они работают медленней чем "(?: )". Об этом говорит Дж. Фридл. Сам же я не тестировал конечно.
Иногда, то что написано в фреймворке, далеко не есть идеалом. Поэтому существуют комюнити, которое конструктивно критикует результат и делает предложения по его улучшению.
Хотел сделать быстрый разбор строки, а в JavaScript самый быстрый способ это сделать — использовать регулярное выражение.
Я не использовал обычных круглых скобок из-за того, что они работают медленней чем "(?: )". Об этом говорит Дж. Фридл. Сам же я не тестировал конечно.
Иногда, то что написано в фреймворке, далеко не есть идеалом. Поэтому существуют комюнити, которое конструктивно критикует результат и делает предложения по его улучшению.
задача стояла написать эффективное регулярное выражение.
эх, е-мае! оно эффективно ЧТО должно делать? матчить все подряд, реплейсить, валидировать? Я вот всегда перед написанием какой-то фичи, почти как на физике 6-го класса, беру бумажку и пишу — «Дано» и «Что делает», иногда еще и пример накидываю, чтобы понять «готово-не готово».
Я не использовал обычных круглых скобок из-за того, что они работают медленней чем "(?: )".
Фридл невероятно прав, однако, если ты его повнимательнее почитаешь, то найдешь, что использование сохраняющей скобки И ссылки на нее в САМОМ выражении может оказаться дешевле, чем вилки из ТРЕХ альтернатив, потому что regex-машина унутрянне делает промежуточную запись бОльшего размера, чем твоя несчастная кавычка, из-за которой вилка лепится.
Конструкции вида "[^"]" — я использовал, для того чтобы в селекторах можно было писать свои регулярные выражения, а также любой текст, например для псевдо селектора ":contains()".
Еще раз. У любого выражения есть 2 проблемы — оно не совпадает с нужным и совпадает с ненужным. В твоем случае выражение вида "[^"]" имеет потенциальную возможность совпасть со всякой ересью, которая стандартом не допускается. У тебя сматчилось, а на клиенте не работает.
Вы безусловно правы. Но
такое чувство, что Вы говорите поверхностно, в общем, а не конкретно о моем выражении. Не знаю, что Вам еще сказать, но пример есть, что делает — написано.
Я поэтому и написал, чтобы мне указали на минусы конструкции, но я не вижу фактов. Попробуйте использовать круглые скобки для запоминания и посмотрим, что у Вас получится в регулярном выражении, которое применяется и глобально и в котором эти скобки могут совпасть через раз, что значит может быть сбита их индексация. Если получится и это будет лучше работать, я Вам трижды скажу спасибо.
Я уверен, что это:
работает быстро, так как ищется сначала первый символ или такая кавычка или такая, если нет — все до свиданье.
Фридл невероятно прав, однако, если ты его повнимательнее почитаешь, то найдешь, что использование сохраняющей скобки И ссылки на нее в САМОМ выражении может оказаться дешевле, чем вилки из ТРЕХ альтернатив, потому что regex-машина унутрянне делает промежуточную запись бОльшего размера, чем твоя несчастная кавычка, из-за которой вилка лепится.
такое чувство, что Вы говорите поверхностно, в общем, а не конкретно о моем выражении. Не знаю, что Вам еще сказать, но пример есть, что делает — написано.
Я поэтому и написал, чтобы мне указали на минусы конструкции, но я не вижу фактов. Попробуйте использовать круглые скобки для запоминания и посмотрим, что у Вас получится в регулярном выражении, которое применяется и глобально и в котором эти скобки могут совпасть через раз, что значит может быть сбита их индексация. Если получится и это будет лучше работать, я Вам трижды скажу спасибо.
Я уверен, что это:
"[^\\"]*(?:\\.[^"\\]*)*"
|
'[^\\']*(?:\\.[^'\\]*)*'
работает быстро, так как ищется сначала первый символ или такая кавычка или такая, если нет — все до свиданье.
> 280 кроказябл или взрывная мощь регулярных выражений
github.com/kakserpom/quicky/blob/master/Quicky_compiler.class.php#L1005 — ваше это цветочки. Кстати пример написан в блокноте без каких-либо подручных средств ;-)
Программировать регулярные выражения весьма интересно, подходите к вопросу именно с позиций программирования (представляя программируемый конечный автомат) и будет вам счастье!
github.com/kakserpom/quicky/blob/master/Quicky_compiler.class.php#L1005 — ваше это цветочки. Кстати пример написан в блокноте без каких-либо подручных средств ;-)
Программировать регулярные выражения весьма интересно, подходите к вопросу именно с позиций программирования (представляя программируемый конечный автомат) и будет вам счастье!
Все же помнят регулярку для проверки email`а на соответствие RFC 822?
www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
Для меня лично вообще открыт вопрос использования регулярных выражений в таких-вот сложных конструкциях. Все время остается осадок, что работает эта штука ну совсем не оптимальным образом.
Имхо как ни крути, но интерпритация таких-вот регулярок и прогон через них достаточно объемных данных это существенная нагрузка и тормоза, которые иногда сводят на нет саму целесообразность применения этого чуда :)
Вобщем я против маньяков с бензопилами :) все хорошо в меру…
Имхо как ни крути, но интерпритация таких-вот регулярок и прогон через них достаточно объемных данных это существенная нагрузка и тормоза, которые иногда сводят на нет саму целесообразность применения этого чуда :)
Вобщем я против маньяков с бензопилами :) все хорошо в меру…
Ну это наверное от реализации зависит, но по-моему вся соль регулярок в том и состоит что они компилируются целиком, а не интерпретируются по-операторно, и прогон по ним данных идет более чем оптимальным способом, который только можно придумать — все выражение на низком уровне, для ЯП с тёплым ламповым интерпретатором, вроде PHP, у которого простая итерация по символам строки уже будет в цать сотен/тысяч раз медленнее аналогичной на компилируемом C — это таки панацея для сложных правил обработки строк. К тому-же скомпилированные регулярки обычно интерпретатором кешируются, в частности в некоторых языках, в которых регулярка — объект — это можно делать явно, как например в javascript: RegExp.compile().
Да это понятно, что оно в теории должно быть написано «правильно». Но дело в том что рекурентные поиски по строкам это зачастую польба из пушки по воробьям :) Простой пример, возьмите HTML размером около 100кб и поищите в нем какую-нибудь простую и заранее известную конструкцию с помощью рекурентной регулярки и напряму, с помощью PHP, через strpos (понятно что про /i речь не идет)…
Ну и понятно что регулярка это именно абстрактное отношение к документу, но у меня на практике было довольно случаев, когда регулярки работали реально медленнее чем самописные функции поиска необходимых конструкций.
А когда кол-во обрабатываемых данных и потоков критическое, то использование регулярок это слишком дорогая цена за маленький размер кода.
А когда кол-во обрабатываемых данных и потоков критическое, то использование регулярок это слишком дорогая цена за маленький размер кода.
100%, что «indexOf» работает в несколько раз быстрее чем «match», но разбор строки поэлементно — в JavaScript гораздо медленней.
Ну безусловно таких случаев может быть масса, регулярка заведомо будет проигрывать strpos'у, который только и занимается тем, что ищет строку, и на тех объёмах текста, которые вы привели в пример этот проигрыш будет значительно весомее чем накладные расходы на выполнение опкодов при реализации алгоритма рекуррентного поиска через strpos, в то-же время на небольших строках, и с более сложными условиями поиска/замены регулярки будут в более выгодном положении.
в JavaScript — абсолютно уверен. Так как я реализовал такой парсер. И он на 10 мс быстрее чем jQuery, на 5мс — за yass в FF3.0 тестировал. Но статья не о том.
Я так и не понял, о чем ваша статья.
Если она про мозгодробительные регулярные выражения, то ей место в блоге crazydev.
Если она про selector engine — то отсутствие результатов тестов и голословные утверждения о превосходстве в скорости над другими смехотворны, учитывая, что:
1. Другие уже давно пользуются нативным querySelectorAll в поддерживающих браузерах.
2. Учитывая пункт 1, скорость следует измерять не в ФФ3, а в ИЕ6-8, именно скорость работы движка селекторов в ИЕ является сейчас самым важным фактором.
3. Я проводил собственные тесты, тестировал только в ИЕ (по вышеназванной причине) и пришел к выводу, что ВСЕ тестируемые движки лажают при определенных условиях (попробуйте используя Sizzle поискать элемент по id используя контекстный объект — и будете сильно удивлены, что он использует не document.getElementById, а document.getElementsByTagName), поэтому всегда можно подобрать выигрышный набор тестов для данного движка.
Нет, она именно о регулярном выражении. Оно очень простое. Я хотел всем показать пример, как достаточно простым (говорю простой, так как регулярка основана всего на одном шаблоне по сути) регулярным выражением можно проанализировать CSS селектор. Надеялся, что может кто-то выскажет критику по самому выражению и думал, что может кому-то будет интересно и получится еще более усовершенствовать его.
Статья не о том, но я скажу…
Да пользуются все «querySelectorAll», который почти соответствует стандарту (стандарт хорош — это точно), но что когда хочется написать свой псевдо селектор? Тогда используемый Вами фреймворк будет использовать собственную реализацию в лучшем случае, в худшем — просто вернется пустой результат.
Не думаете ли Вы, что я выглядел бы по идиотски, если бы тестировал это только в FF3.0, а потом заявлял бы всем, что это самое быстрое регулярное выражение? К тому же все эти действия происходили 1.5 года назад.
Статья не о том, но я скажу…
Да пользуются все «querySelectorAll», который почти соответствует стандарту (стандарт хорош — это точно), но что когда хочется написать свой псевдо селектор? Тогда используемый Вами фреймворк будет использовать собственную реализацию в лучшем случае, в худшем — просто вернется пустой результат.
Не думаете ли Вы, что я выглядел бы по идиотски, если бы тестировал это только в FF3.0, а потом заявлял бы всем, что это самое быстрое регулярное выражение? К тому же все эти действия происходили 1.5 года назад.
Я так и не понял что вы анализируете вашим выражением. Оно матчится на несуществующие селекторы так же хорошо, как и на существующие.
в этот вся суть! Идея была не следовать стандарту, а реализовать парсер конкретной конструкции, похожей на селектор. Ведь тогда это можно будет применять и в XML тоже и не только, мало ли какие идеи/задачи придут в голову в будущем.
Чем тогда ваше выражение лучше «.*»?
приведите пример пожалуйста. Почему Вы пишете, что-то не работает, но говори что? Как исправлять?
Это как бы Вам тестер сказал, что все пропало, система полностью не работает. А он не может в админку допустим зайти.
Скажите пожалуйста, конкретно — пример, ошибки
Это как бы Вам тестер сказал, что все пропало, система полностью не работает. А он не может в админку допустим зайти.
Скажите пожалуйста, конкретно — пример, ошибки
«+a» например.
но что когда хочется написать свой псевдо селектор?Лично мое мнение таково, что если человеку не хватает 3-х базовых селекторов (id, tag, class), значит он что-то делает не так. Все псевдоселекторы — это чуть-чуть от лукавого.
Надеялся, что может кто-то выскажет критику по самому выражению и думал, что может кому-то будет интересно и получится еще более усовершенствовать его.Чем длиннее и запутаннее становится регулярное выражение, тем сложнее его совершенствовать, т.к. при малейших изменениях импакт может быть очень большим и надо тестировать _все_ варианты использования.
Но в общем, дело ваше, если это вам помогло понять регулярные выражения и javascript — хорошо.
Лично мое мнение таково, что если человеку не хватает 3-х базовых селекторов (id, tag, class), значит он что-то делает не так. Все псевдоселекторы — это чуть-чуть от лукавого.То есть, чтобы сделать буквицу, вы будете к каждой первой букве строки лепить span? Чем вы замените :hover или :target? ЖабаСкриптом?
Человек говорит о селекторах, которые могут понадобится из JS, а не о css. Мне так показалось.
В данном конкретном случае, можно либо заключать первую букву в тег, либо использовать псевдоселектор :first-letter в css — в обоих случаях это будет гораздо правильнее, чем насиловать многострадальный недобраузер IE пользователя, используя монструозные скриптовые псевдоселекторы.
Про вторую часть вопроса я не понял, зачем вам эти селекторы? Приведите хоть один адекватный пример их использования в javascript.
Про вторую часть вопроса я не понял, зачем вам эти селекторы? Приведите хоть один адекватный пример их использования в javascript.
А как же
input[type="file"]?Если честно, не могу вспомнить, чтобы за 3.5 года я использовал подобный селектор, ну может от силы один-два раза. В любом случае, на уровне Sizzle в IE это делается простой фильтрацией результата getElementsByTagName, поэтому того же самого можно добиться и без использования таких селекторов, причем вполне возможно более оптимальным для данного конкретного случая методом.
PS: Я не спорю, так удобнее и меньше букв писать, но по факту, люди подключают монструозный jQuery на проект и используют 10% его возможностей.
PS: Я не спорю, так удобнее и меньше букв писать, но по факту, люди подключают монструозный jQuery на проект и используют 10% его возможностей.
Я вот только не понимаю, почему каждый считает своим долгом написать тестер регулярных выражений. Скажу по секрету есть полно многофункциональных средств для создания и тестирования регулярных выражений, причем есть достойные бесплатные, которые нормально подсвечивают и по-человечески объясняют regex'ы.
Расскажите пожалуйста по пунктам, как работает механизм поиска элементов с использование такого регекспа?
что ему кормят и что он возвращает?
что ему кормят и что он возвращает?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
280 кроказябл или взрывная мощь регулярных выражений