Проверка регулярных выражений онлайн

Считает движок JavaScript вашего браузера. Это ровно тот движок, который работает в коде фронтенда. Если шаблон поедет в Python, Java, Go, PostgreSQL или в конфиг nginx — там другой движок, и совпадать он может иначе. Три расхождения с Python проверены на обоих движках и стоят того, чтобы их знать.

Первое: \d здесь — это ровно цифры 0–9, и флаг u этого не меняет. В Python \d по умолчанию ловит и арабо-индийскую ٣, и полноширинную ３. То есть шаблон, признанный здесь строгим, на бэкенде пропустит то, чего вы не ждали, — а выглядеть в логе это будет как обычные цифры. На их стороне лечится флагом re.ASCII; здесь такой же расширенный набор даёт \p{Nd} с флагом u.

Второе: именованные группы пишутся по-разному — здесь (?<имя>…), в Python (?P<имя>…). Это не «одна форма предпочтительнее»: чужая запись не собирается вовсе, оба движка падают с синтаксической ошибкой. Русские имена при этом законны и здесь, и там.

Третье: $ без флага m здесь означает самый конец текста. В Python он совпадает ещё и перед завершающим переводом строки: b$ находится в ab\n у них и не находится у нас. Перед двумя переводами подряд не совпадает уже нигде — послабление ровно на один. Отсюда и берётся «на бэкенде проверка проходит, на фронте нет» у поля, куда прилетел лишний перенос.

Шаблон для проверки берут из валидации формы на фронте, из атрибута pattern у поля ввода, из поля pattern в схеме OpenAPI, из правил маршрутизации в nginx, из фильтров в CI и в системах сбора логов. Отдельная тонкость про pattern у поля ввода: по спецификации HTML браузер оборачивает его как ^(?:…)$ и включает флаг v, то есть шаблон обязан совпасть со ВСЕМ значением целиком. Якоря ^ и $ там поэтому не нужны — а вот здесь, при проверке, их придётся дописать самому, иначе шаблон найдёт совпадение в середине, и вы решите, что валидация пройдёт.

Кнопка «Пример» подставляет учебную пару: шаблон и строки.

Без флага g ищется только первое совпадение. Это не упрощение инструмента, а поведение движка: exec без g всегда стартует с начала. Ровно на этом ломается замена, которая «сработала один раз».

Совпадение нулевой длины — не поломка. Шаблон вроде \d* совпадает и с пустотой, поэтому на строке из трёх букв он найдёт четыре совпадения нулевой длины. В подсветке они показаны засечкой: подсвечивать в них нечего. Если число совпадений выглядит бессмысленно большим — почти всегда дело в этом, и лечится заменой * на +.

Точка не совпадает с переводом строки, пока не включён флаг s. Поэтому .* не дотягивается до следующей строки, и разбор многострочного лога молча обрывается на первой.

Жадность. .* берёт как можно больше и откатывается назад, .*? — как можно меньше и растёт по необходимости. Для «вытащить содержимое первого тега» нужен второй вариант, иначе совпадение растянется до последнего тега в тексте.

Почему инструмент может сдаться. Вложенные квантификаторы вроде (a+)+$ на длинной строке заставляют движок перебирать варианты экспоненциально: это называется катастрофическим бэктрекингом. Остановить уже запущенную регулярку в JavaScript нельзя ничем, поэтому счёт идёт в отдельном потоке, и через две секунды мы этот поток просто убиваем. Вкладка при этом живёт, а вы получаете важный ответ: такой шаблон нельзя выпускать на бэкенд — там ровно он и положит запрос.

Обычное лекарство от бэктрекинга здесь недоступно, и это важно знать заранее. Атомарные группы (?>…) и притяжательные квантификаторы a++, a*+ — то, чем этот перебор обрубают в других движках, — в JavaScript отсутствуют: любая из этих записей не собирается вовсе. В Python они появились в версии 3.11, в PCRE2 есть давно. Поэтому совет «поставь плюс после плюса», справедливый для бэкенда, на фронте не сработает: сужать придётся сам шаблон, чтобы соседние части перестали претендовать на одни и те же символы.