Валидация форм с помощью регулярных выражений

Кратко

Регулярные выражения — компактный и быстрый способ проверять значения полей формы на стороне клиента и сервера. Они подходят для многих простых правил (длина, цифры, буквы), но имеют ограничения: для сложных форматов лучше использовать специализированные библиотеки и всегда дублировать проверки на сервере.

Каждый веб-разработчик знаком с чувством, когда понятно — форму уже сделал, а теперь надо валидировать каждое поле. К счастью, валидация форм не обязательно должна быть болезненной. Часто регулярные выражения (regex) покрывают большую часть типичных требований.

Что такое регулярные выражения?

Регулярные выражения описывают шаблоны, которым соответствуют комбинации символов в строках. Проще говоря: regex — это компактный способ задать правило того, какие символы и в каком порядке допустимы.

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

Применения:

• Быстрый поиск и замена по шаблону.
• Валидация полей формы.
• Сложные фильтры поиска.
• Утилиты командной строки (например, grep).

Почему использовать регулярные выражения для валидации?

Регулярные выражения просты, компактны и встроены в JavaScript. В большинстве браузеров и на сервере (Node.js) поддержка native, поэтому вы не тянете внешние зависимости и не увеличиваете размер сборки.

Преимущества:

• Лаконичность для простых правил (длина, допустимые символы, простой формат).
• Производительность — проверка выполняется на уровне движка.
• Универсальность — одинаковый синтаксис на клиенте и на сервере (с незначительными отличиями).

Ограничения:

• Сложные форматы (корректные email по RFC, номера телефонов по стандарту E.164, сложные даты) лучше проверять специальными библиотеками.
• Неправильные или очень «жадные» выражения могут привести к ReDoS (регулярным выражениям, вызывающим долговременные вычисления).

Важно: никогда не полагайтесь только на клиентскую валидацию — сервер обязан проверять входные данные.

Основы регулярных выражений в JavaScript

В JavaScript регулярное выражение можно задать двумя способами:

1. Литерал между слешами:

/abc/

2. Через конструктор RegExp:

new RegExp('abc')

Простейший пример: /abc/ соответствует любой строке, где подряд встречаются символы “a”, “b”, “c”.

Анкоры начала и конца строки:

• ^ — начало строки
• $ — конец строки

Специальные символы:

• . — любой символ, кроме перевода строки (если не включён флаг s)
• * — предыдущий элемент 0 и более раз
• + — предыдущий элемент 1 и более раз
• ? — предыдущий элемент 0 или 1 раз (делает часть шаблона необязательной)
• {m,n} — диапазон повторений от m до n
• \d — любая цифра (эквивалент [0-9])
• \w — буквы, цифры и _ (в ASCII)
• \s — пробельные символы
• [...] — символьный класс
• (?:...) — не сохраняющая группа
• (?=...) — позитивный просмотр вперёд (lookahead)
• (?<=...) — позитивный просмотр назад (lookbehind, поддерживается не во всех средах)

Пример повторения:

/abc*/

Здесь шаблон abc* соответствует строкам “ab”, “abc”, “abccccc” и т. д., потому что c* означает любое количество символов c, включая ноль.

Флаги регулярных выражений (чаще используемые):

• i — регистронезависимый поиск
• g — глобальный поиск (несколько совпадений)
• m — многострочный режим
• u — Unicode-режим (позволяет использовать \p{...})
• s — dotAll: . соответствует также переводу строки

Перед использованием сложных конструкций проверьте поддержку в целевой среде (браузеры, Node.js).

Валидация форм с регулярными выражениями

Общие шаги при валидации с помощью JavaScript:

1. Получить значение поля.
2. Проверить соответствие регулярному выражению.
3. При несоответствии показать пользователю понятное сообщение об ошибке.

Пример из исходного текста: простая строка ввода и функция валидации.

function validate() {  
    let value = document.querySelector("input").value;  
    const regEx = /^.{3,7}$/;  
    return regEx.test(value);  
}

Использование HTML-атрибута pattern позволяет делегировать валидацию браузеру. Но важно знать нюансы — атрибут pattern принимает регулярное выражение без ограничивающих слешей и без флагов. Например:

    
    Submit

Если значение не соответствует шаблону, браузер показывает стандартное сообщение об ошибке.

Если атрибут pattern содержит недопустимое регулярное выражение, браузер проигнорирует его.

Частые ошибки при использовании pattern

• Помещать слеши-разделители (/…/) в значение pattern — это неверно.
• Ожидание поддержки флагов (например, i) прямо в pattern — в HTML это не поддерживается; используйте JavaScript для более гибкой логики или управляйте регистром через inputmode/toLowerCase().
• Полагаясь только на UI браузера, забывают про серверную валидацию.

Общие шаблоны регулярных выражений

Ниже — шаблоны, которые часто встречаются в форме. Каждый шаблон сопровождается пояснениями и расширениями для локализации.

Валидировать длину строки

Точное количество символов (7):

/^.{7}$/

Диапазон от 3 до 7:

/^.{3,7}$/

Минимум 3 символа, без верхней границы:

/^.{3,}$/

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

Только буквы

ASCII-буквы (латиница):

/^[a-zA-Z]+$/

Если нужно поддерживать буквы всех языков (Unicode), используйте Unicode-символьные свойства и флаг u (ES2018+):

/^[\p{L}]+$/u

Где \p{L} обозначает любой буквенный символ в Юникоде.

Только цифры

/^\d+$/

Буквы и цифры

/^[a-zA-Z\d]+$/

Unicode-версия (включая буквы из других алфавитов):

/^[\p{L}\p{Nd}]+$/u

Здесь \p{Nd} — десятичные цифры в Unicode.

Юзернейм (буквы, цифры, подчёркивание, дефис)

/^[a-zA-Z\d_-]+$

Или с использованием \w, помните, что \w включает подчёркивание, цифры и латинские буквы, но не все юникодные буквы:

/^([\w-])+$/

Номера телефонов

Телефоны — одна из наиболее сложных тем, потому что формат сильно различается по странам. Общий и безопасный вариант — проверять только цифры и длину:

/^\d{9,15}$/

Если вы хотите поддержать международный формат с опциональным плюсом (E.164-подобно):

/^\+?\d{9,15}$/

Для корректной валидации по реальным правилам номера лучше использовать библиотеку libphonenumber.

Даты

Простой шаблон для формата DD-MM-YYYY (не проверяет корректность даты, только формат):

/^\d{2}-\d{2}-\d{4}$/

Для проверки реальной даты (учёт февраля, високосных годов и т. д.) применяйте парсинг с помощью библиотек date-fns, Luxon или собственной логики.

Email

Email кажется очевидным, но полная проверка по RFC сложна. Для большинства приложений достаточно упрощённого шаблона, но помните — единственный надёжный способ проверить почтовый ящик — отправить подтверждение.

Простой пример (не полный):

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

Если приложение критично к корректности email (бизнес-процессы, безопасность), комбинируйте локальную валидацию с проверкой на сервере и подтверждением адреса.

Когда регулярные выражения не подходят

• Нестандартные или очень сложные форматы (например, правильно валидировать email по RFC 5322).
• Сложная логика последовательных условий (больше читабельности даст код или грамматика).
• Строки очень больших размеров с «жадными» паттернами — риск ReDoS.
• Парсинг вложенных структур (XML, HTML) — для этого есть парсеры.

Альтернатива: схемные валидаторы (Yup, Joi), библиотеки для телефонов/дат и встроенная серверная валидация.

Рекомендации по безопасности и производительности

• Всегда повторяйте валидацию на сервере.
• Избегайте неоптимизированных шаблонов, которые легко приводят к экспоненциальному времени (категория ReDoS).
• Для старых/неизвестных пользовательских данных ограничьте длину строки перед применением сложного regex.
• Локализуйте сообщения об ошибках; формируйте дружелюбный UX.

Пример опасного шаблона (упрощённый демонстрационный):

/(a+)+b/

Он может потребовать много времени для строки вида “aaaaaaaaaaaa…” — это классический пример уязвимости ReDoS.

Практическая методология внедрения валидации (мини-процесс)

1. Соберите требования к полю (формат, длина, локализация).
2. Выберите стратегию: простая regex-валидация vs библиотека.
3. Напишите regex и комментарии к нему.
4. Подготовьте набор тестов (валидные/невалидные примеры).
5. Интегрируйте в UI: inline-ошибки, aria-атрибуты для доступности.
6. Дублируйте проверку на сервере.
7. Мониторьте реальные ошибки от пользователей и корректируйте шаблоны.

Чек-листы по ролям

Разработчик:

• Определил требования и форматы.
• Выбрал правильный инструмент (regex vs библиотека).
• Написал читаемый regex с комментариями.
• Написал unit-тесты и включил их в CI.
• Убедился, что сервер валидирует те же правила.

QA:

• Покрыл тесты граничными значениями.
• Проверил поведение при длинных строках.
• Оценил сообщения об ошибках в UI и доступность.
• Тестировал локализацию форматов (даты, телефоны).

Дизайнер/PM:

• Согласовал текст ошибок.
• Проверил, что UX не блокирует пользователя без необходимости.
• Учёл доступность и локализацию.

Критерии приёмки

• Все обязательные поля блокируют отправку при несоответствии требованиям.
• Сообщения об ошибках понятны и локализованы.
• Сервер повторяет все проверки клиента.
• Нет уязвимостей ReDoS при тестировании длинных входных строк.

Примеры тест-кейсов

Для поля “username” с правилом: латиница/цифры/_/- и длина 3–16:

• Валидные: “user_1”, “john-doe”, “abc123”
• Невалидные: “ab” (слишком коротко), “this-is-a-very-long-username” (слишком длинно), “name!” (запрещённый символ)

Для телефонного поля с правилом ^\+?\d{9,15}$:

• Валидные: “+74951234567”, “74951234567”, “+123456789012”
• Невалидные: “12345”, “phone123”, “+12 3456789” (пробелы)

Decision flowchart

flowchart TD
  A[Есть требования к формату?] --> B{Формат простой?}
  B -- Да --> C[Использовать regex]
  B -- Нет --> D[Использовать библиотеку]
  C --> E{Проверить ReDoS риск}
  E -- Высокий --> D
  E -- Низкий --> F[Добавить тесты и CI]
  D --> F

Совместимость и примечания по платформам

• Lookbehind ((?<=...)) и некоторые Unicode-конструкции доступны в современных движках (Chrome, Node 8+ для некоторых фич), но не во всех старых браузерах.
• \p{...} требует флага u и поддержки ES2018+. Проверьте цель браузера/Node.
• HTML pattern не поддерживает флаги и не принимает ограничители //.

Альтернативные подходы

• Схемные валидаторы (Yup, Joi) — удобны для комплексной валидации и читаемости.
• libphonenumber — для точной валидации и форматирования телефонов.
• date-fns/Luxon — для парсинга и проверки даты/времени.
• Серверная валидация как «источник истины» и защита от манипуляций.

Итог

Регулярные выражения — мощный инструмент для большинства повседневных задач валидации форм. Они компактны, быстры и встроены в JavaScript. Однако важно знать границы их применимости: для сложных форматов, для вопросов безопасности и для локализации лучше выбирать специализированные библиотеки. И всегда повторяйте проверки на сервере.

Важно

• Не используйте regex для парсинга сложных языков или вложенных структур.
• Ограничьте длину входных данных перед применением тяжёлых выражений.
• Тестируйте и мониторьте реальные данные пользователей.

Краткий план внедрения

1. Описать правила и примеры валидных/невалидных значений.
2. Реализовать клиентскую проверку (регулярные выражения или библиотека).
3. Реализовать серверную проверку в соответствии с той же логикой.
4. Написать автоматические тесты и покрыть edge-case’ы.

Список полезных ресурсов

• MDN Web Docs — руководство по регулярным выражениям в JavaScript.
• libphonenumber — международная валидация телефонов.
• date-fns и Luxon — для корректного парсинга дат.

Конец статьи.