Тестер регулярных выражений

Зачем тестеру регулярных выражений нужен воркер

Почти вся механика этой страницы существует ради одного сценария отказа. Возьмите /(a+)+b/ и тридцать букв a без b. Движку надо решить, как поделить эти тридцать символов между внутренним и внешним квантификатором, а способов сделать это 2³⁰. Каждый будет опробован, прежде чем совпадение объявят невозможным.

Важно вот что: выполняющееся регулярное выражение нельзя прервать. JavaScript однопоточен, поэтому сторож на setTimeout не сработает, пока выражение не вернётся, — а для такого ввода это где-то за тепловой смертью Вселенной. Вкладки больше нет.

Поэтому шаблон исполняется в Web Worker, в своём потоке, а главная страница держит таймер. Когда таймер побеждает, worker.terminate() попросту убивает поток. Это единственный работающий механизм, и именно поэтому тестер сообщает вам, что шаблон опасен, вместо того чтобы превратиться в зависшую вкладку.

Это стоит усвоить, потому что тот же шаблон в боевом коде — это отказ в обслуживании: пользовательский ввод сопоставляется с уязвимым выражением, и один запрос занимает ядро процессора на неопределённый срок. Этот класс ошибок называют ReDoS.

Каких конструкций избегать

Общий знаменатель — неоднозначность: у шаблона больше одного способа поглотить одни и те же символы. Класс символов делает работу альтернативы, не создавая неоднозначности, — поэтому в колонке «безопаснее» в основном просто | заменена на [].

Жадность, лень и ошибка, которую пишет однажды каждый

Квантификаторы по умолчанию жадны: .+ забирает всё, что может, и отдаёт символы обратно только по принуждению. На строке <b>bold</b>:

Тянуться следует именно к третьей форме. Отрицаемый класс символов не может проскочить лишнего, поэтому и откатывать нечего: он и яснее выражает намерение, и дешевле в исполнении, чем ленивый вариант.

lastIndex, и почему исчезает каждое второе совпадение

Объект RegExp с флагом g хранит состояние. Он держит lastIndex, который сдвигается после каждого exec или test, поэтому повторное использование одного объекта в разных вызовах продолжает поиск оттуда, где он остановился:

const re = /\d+/g;
re.test('123');  // true,  lastIndex is now 3
re.test('123');  // false! it resumed from index 3

Создавайте выражение внутри цикла, сбрасывайте lastIndex = 0 либо используйте matchAll, который сам этим управляет. Тестер выше создаёт новый объект на каждый запуск, так что здесь вы видите поведение первого вызова.

Чем регулярные выражения JavaScript отличаются

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

• Нет атомарных групп и захватывающих квантификаторов. В PCRE есть (?>...) и a++, полностью запрещающие откат; в JavaScript нет ни того, ни другого, отчего ReDoS здесь и пишется легче.
• Нет рекурсии. Сбалансированные скобки регулярным выражением JavaScript не разобрать. Если задача в этом, вам нужен парсер.
• Ретроспективная проверка появилась поздно. (?<=...) поддерживается в современных браузерах, но не в старом Safari, так что сверьтесь со своими целевыми платформами.
• RE2 в Go — другая машина. Гарантированное линейное время, ни обратных ссылок, ни просмотров. Если вы когда-нибудь недоумевали, зачем Go отказался от возможностей, — вот вам причина.

Смежное

Если текст, по которому вы ищете, — это JSON, то сначала отформатировать его обычно делает шаблон ненужным: на структурированных данных парсер выигрывает у регулярного выражения всегда. Если вам нужно расписание, а не поиск, соседний инструмент — разборщик cron.