RegExp.escape() — новый стандартный способ безопасно превращать произвольную строку в литеральный шаблон для регулярного выражения. Он закрывает типичный класс ошибок, когда пользовательский ввод ломает поиск, меняет смысл паттерна или вообще делает RegExp невалидным, а главное — делает это точнее, чем большинство самодельных replaceAll.
После многих лет, когда разработчики писали собственные функции экранирования для регулярных выражений, JavaScript получил встроенный метод RegExp.escape(). Это не «ещё один маленький хелпер», а стандартизированный ответ на очень практичную проблему: как безопасно вставить обычный текст в динамически создаваемый regex так, чтобы этот текст точно воспринимался как текст, а не как набор спецсимволов.
Что именно решает RegExp.escape() и почему это полезно сразу на практике
Если приложение строит регулярное выражение из строки, введённой пользователем, возникает предсказуемый риск. Символы вроде ., *, ?, (, ), [, ], |, ^, $ и / имеют специальный смысл в regex. Если вставить их «как есть», поиск начнёт работать не так, как ожидалось.
Типичный пример проблемы:
const userInput = "file(1).js";
const re = new RegExp(userInput, "g");Здесь строка "file(1).js" будет интерпретирована не как буквальный текст, а как regex-паттерн. Скобки станут группой, точка — «любым символом». В результате поиск найдёт не только точное совпадение file(1).js, а гораздо более широкий набор строк.
С RegExp.escape() идея другая: перед созданием RegExp входная строка превращается в безопасный литеральный фрагмент.
const userInput = "file(1).js";
const re = new RegExp(RegExp.escape(userInput), "g");Теперь regex ищет именно текст file(1).js.
Это поведение описано в спецификации ECMAScript и в документации MDN, где метод прямо предназначен для экранирования текста перед использованием в конструкторе RegExp (MDN).
Почему старые самодельные функции часто были недостаточны
Долгое время стандартного API не было, поэтому разработчики использовали что-то вроде:
str.replace(/[.*+?^${}()|[\]\\]/g, "\\$&")Такой подход действительно экранирует многие «классические» метасимволы. Но проблема в том, что корректное встраивание текста в regex зависит не только от этого набора.
Стандартный RegExp.escape() делает больше:
- экранирует символы, которые действительно синтаксически значимы;
- учитывает случаи, когда обычное добавление обратного слэша недостаточно или вообще неверно;
- обрабатывает ведущий ASCII-символ особым образом, чтобы избежать неоднозначности рядом с escape-последовательностями;
- использует hex- и unicode-экранирование там, где это безопаснее по правилам синтаксиса regex.
Это важно, потому что функция экранирования должна быть корректной не «в большинстве бытовых случаев», а при любом допустимом пользовательском вводе. Именно поэтому решение было стандартизировано в TC39 и вошло в ECMAScript: задача оказалась сложнее, чем выглядит на первый взгляд (ECMAScript specification).
Как работает RegExp.escape() на уровне правил
Смысл метода — вернуть строку, которую можно безопасно использовать как буквальный паттерн в new RegExp(...).
1. Первый буквенно-цифровой ASCII-символ может кодироваться как \xNN
Одна из неочевидных частей алгоритма: если строка начинается, например, с латинской буквы или цифры, этот символ может быть преобразован в hex-escape.
Зачем это нужно? Чтобы при встраивании escaped-строки рядом с уже существующей escape-последовательностью не возникала двусмысленность. Например, если разработчик собирает более сложный шаблон из частей, первый символ вставленного фрагмента не должен случайно «прилипнуть» к предыдущему \1, \x0 или подобной конструкции.
Именно здесь стандартный метод выигрывает у большинства самописных решений: он учитывает не только сами спецсимволы, но и контекст безопасного склеивания фрагментов.
2. Синтаксические метасимволы regex экранируются
К символам, значимым для regex-синтаксиса, относятся, в частности:
^$\.*+?()[]{}|/
Они экранируются так, чтобы потерять специальный смысл и интерпретироваться буквально.
3. Часть прочих символов экранируется не обратным слэшем, а через \x
Это ещё одна важная деталь. Не любой символ можно просто безопасно превратить в \символ в любом regex-контексте. Для некоторых знаков препинания стандарт использует hex-escape, потому что это надёжнее и синтаксически универсальнее.
4. Пробелы, управляющие символы и юникод тоже учитываются
Алгоритм работает не только с «видимыми» ASCII-символами. Он определяет безопасное представление и для пробелов, переводов строк, табуляций, других whitespace-символов и Unicode-кода. Это особенно важно для приложений, которые принимают произвольный текст, а не только короткие поисковые запросы на латинице.
Чем RegExp.escape() отличается от «экранирования regex»
Здесь легко запутаться. RegExp.escape() не делает из строки «умный regex» и не помогает писать паттерны. Он делает обратное: гарантирует, что строка станет буквальным фрагментом regex.
То есть:
- если вам нужно найти точный текст, введённый пользователем, — это правильный инструмент;
- если вам нужно дать пользователю язык шаблонов, где
.*или[a-z]должны работать как regex, —RegExp.escape()использовать нельзя, потому что он как раз отключит этот синтаксис.
Проще говоря:
| Сценарий | Нужен RegExp.escape() |
| Поиск точного текста по пользовательскому вводу | Да |
| Подсветка совпадений введённой строки в тексте | Да |
| Фильтр по имени файла, тега, логина, URL-фрагмента | Да |
| Конструктор regex для разработчика вручную | Нет |
| Пользовательский mini-language на regex | Нет |
Где эта функция реально спасает от багов
Поиск по сайту или в интерфейсе
Обычный кейс: пользователь вводит C++, (test), a.b, [id], ?debug=true. Без экранирования поиск либо даст лишние совпадения, либо сломается с ошибкой синтаксиса регулярного выражения.
Подсветка найденного текста
Часто интерфейс делает так: берёт поисковый запрос, собирает regex с флагом gi, потом оборачивает совпадения в <mark>. Если ввести строку со спецсимволами, подсветка ломается. RegExp.escape() устраняет именно этот класс ошибок.
Фильтрация логов, путей, имён файлов и технических идентификаторов
Технические строки регулярно содержат точки, слэши, скобки, плюсы, дефисы и другие символы с особыми значениями. Если искать их как regex без экранирования, результат становится непредсказуемым.
Корректный способ использования
Надёжный сценарий выглядит так:
const query = "file(1).js";
const pattern = RegExp.escape(query);
const re = new RegExp(pattern, "gu");Здесь:
query— произвольный текст;pattern— уже безопасная литеральная форма;re— готовое регулярное выражение для точного поиска текста.
Важно понимать: экранировать нужно только ту часть шаблона, которая пришла извне и должна трактоваться буквально. Если вы строите составной regex, статические фрагменты и regex-логику нужно оставлять отдельно.
Концептуально:
const prefix = "^";
const user = RegExp.escape(input);
const suffix = "$";
const re = new RegExp(prefix + user + suffix, "u");Такой подход безопасен: якоря ^ и $ сохраняют своё значение, а пользовательский ввод остаётся буквальным.
Где легко ошибиться даже с RegExp.escape()
Ошибка 1. Экранировать весь готовый паттерн
Если взять полноценный regex и прогнать через RegExp.escape(), он перестанет быть regex и станет просто строкой для буквального поиска.
Ошибка 2. Думать, что это защита от всех инъекций вообще
RegExp.escape() решает конкретную задачу: безопасное включение текста в regex. Он не санитизирует HTML, не защищает SQL, не заменяет валидацию ввода и не решает вопросы производительности плохо спроектированных регулярных выражений.
Ошибка 3. Считать, что любой старый polyfill эквивалентен стандарту
Многие старые утилиты покрывают только популярные метасимволы. Но стандартный алгоритм тоньше. Если нужна именно предсказуемость по спецификации, лучше ориентироваться на нативную реализацию или polyfill, повторяющий стандартный алгоритм.
Совместимость и текущий статус
RegExp.escape() — стандартизированная функция ECMAScript. MDN отмечает её как Baseline 2025, то есть как возможность, ставшую доступной в актуальных версиях современных браузеров, начиная с 2025 года. Это означает важную практическую вещь: в новом фронтенд- и серверном JavaScript на современных рантаймах метод уже можно рассматривать как реальный инструмент, но для старых окружений совместимость нужно проверять отдельно (MDN).
Если проект поддерживает старые браузеры или старые версии движков, нужно заранее убедиться, что:
- целевой runtime уже содержит
RegExp.escape(), или - в сборке есть совместимая реализация, повторяющая стандартное поведение.
Дополнительный практический ориентир даёт совместимость в справочниках экосистемы, например Can I use, но в продуктовой документации всё равно лучше фиксировать минимальные версии поддерживаемых окружений явно.
Почему появление этой функции важно для экосистемы
У RegExp.escape() есть редкое свойство: это маленькое API, которое убирает огромный слой повторяющихся пользовательских ошибок.
До стандартизации:
- каждая команда писала свой helper;
- helper почти всегда выглядел «примерно правильно»;
- никто не был до конца уверен, что он корректен во всех случаях;
- пограничные входные данные обнаруживались уже в продакшене.
После стандартизации:
- поведение описано в спецификации;
- один и тот же код работает единообразно;
- исчезает необходимость поддерживать домашние реализации;
- снижается число багов в поиске, подсветке, фильтрации и обработке строк.
Это хороший пример того, как небольшая языковая возможность закрывает реальную массовую боль разработчиков.
Итог
RegExp.escape() нужен не для «красоты кода», а для надёжности. Если вы строите регулярное выражение из текста, который должен трактоваться буквально, использовать этот метод — правильное и теперь уже стандартное решение. Он точнее самодельных helpers, учитывает сложные случаи спецификации и помогает избежать класса багов, которые обычно проявляются в самый неудобный момент: на пользовательском вводе, в поиске и в динамически собираемых шаблонах.
