Comments 32
Коротко: не используйте RegEx там, где достаточно String.prototype.indexOf()
Вот один из отличных on-line reg-exp редакторов: https://regex101.com/, в нем отлично реализована как подсветка групп, так и в целом cook-book имеется. + Поддерживаются различные популярные реализации.
Мило. Бегло пробежал по тексту и подумал, что у меня опять ГПУ ускорение в бразузере глючит.
Я в своей работе использовал парсинг HTML с помощью регулярных выражений, но мы парсили HTML, который сами и генерировали. Наверное, здесь имеется ввиду, что нельзя так парсить пользовательский ввод.
В HTML возможна закрывающая треугольная скобка внутри значения атрибута. То есть простой вариант поиска тега уже разваливается. Ещё там возможны комментарии и вставки js и css (где могут быть любые расклады по скобкам и кавычкам). Вероятно, это всё можно запихнуть в регекс, но обезболить такой регекс уже не получится.
3 - использовать билдер регулярок: Да хватит уже писать эти регулярки
Есть миф, что регулярные выражения более производительные, чем работа через встроенные методы классов вроде String
Если нужно найти одно вхождение - да, будет медленнее.
Когда задача найти несколько разных строк, или более сложных условий - всё становится гораздо лучше.
Это как использовать StringBuilder вместо конкатенации 2х строк.
И да, вы же не забыли что у регулярок конечные автоматы
под капотом?
А разве регекс не должен компилироваться? Я понимаю, если бы его создавали в цикле, но в цикле только использование, непонятно, почему в десятки раз медленнее, чем поиск по строке.
Потому что алгоритм идет по каждому символу в строке по порядку, применяя к нему все возможные вычисления. А работа со строкой будет оптимизирована. Я попытался найти алгоритм поиска по строке, но не получилось (возможно, кто-то может подсказать из читателей). Насколько я знаю, есть только некоторые требования к подобным алгоритмам, а как его реализовать - это решают разработчики JS движка.
Мемасик топ!
В целом согласен с выводом, да и сам придерживаюсь подобных практик при использовании регулярок.
Кому-нибудь будет полезно.
Суть регулярок в том что они рантайм. Если формат известен на этапе компиляции, то да, всегда есть вариант обойтись без них и написать парсер под конкретную строку. Но если формат определяется во время работы приложения, из каких нибудь прилетающих конфигов, то тут уже сложнее, и нужно динамически строить алгоритм под формат, что и делают регулярки
RegExp-- Regular Expressions -- правильно переводить -- "УПРАВЛЯЮЩИЕ Выражения".
RegExp-- это микропрограмма, которая компилируется в высокоскоростной конечный автомат, заточенный под обработку строк. Изначально предназначен на работу исключительно со строками из символов диапазона ASCII-7. Цель -- выполнять несколько операций поиска дополнительно используя ещё и математические выборки за один вызов.в настоящее время в движке V8 (Chromium, Node), в редакторах SublimeText, VisualStudio Code и много где ещё используется расширенная реализация основанная на Си-шной библиотеке Boost, которую модифицируют под нужды приложений (того же V8, например), и в качестве расширений добавляют модификаторы якорей, поддержку Unicode/UTF8, дополнительные проверки контекста. Хотя, на мой взгляд, она сама хорошо оптимизирована и имеет арсенал богаче, чем изначальный ставший популярным вариант на Perl, который кое-где называют
PCRE- Perl Compatible Regular Expressions.
На сегодняшний день, лично я рекомендую использовать одиночные операции со строками (IndexOf, например) исключительно для читаемости кода.
Но если важна производительность или краткость исходника (при минификации и/или оптимизации обработанный код получается компактнее, меньше внутренних переходов и вызовов), то РегЕксп предпочтительней даже для простейших операций.
Дополнительно это может дать единый формат ответа функции обработки, что крайне важно при конвеерной обработке, где данные меняются от шага к шагу (про микроконвеер самих РегЕкспов уже всё все поняли)
Если много операций со строками, то разница в размере бандла и скорости работы:
Вас приятно удивит на
JavaScriptиGo,
ничего не скажет на
Python2, будет заметна наPython3,и разочарует на чистом
C.
Причина разочарования -- С компилируется в процессорный, а не промежуточный байт-код или собирается в бандл.
Дело в том, что реализация одиночных вызовов (о, чудо!) в современных реализациях ВСЕХ языков программирования использует тот же подход, который был в основе РегЕксп-ов
Ну, а чтобы легче понимать Регулярки, точнее их основу, не поленитесь, найдите документацию по JScript5 от Microsoft, которая шла в поставе Office"95, Office"97 и Office"2003, шла в комплекте с WScript, была в составе официальной поставки Windows XP и Windows Vista. Название файла JSCRIPT5.CHM
На мой взгляд -- лучшая документация по регуляркам. Книжка Фидла толщиной в 400 страниц курит в сторонке по сравнению с 3 страницами из доки от MS.
Всем успеха в понимании и изучении!
Обезболиваем RegEx