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

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

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

Коротко: регулярное выражение описывает шаблон текста; тест — проверяет, соответствует ли строка этому шаблону.

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

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

Важно: regex — мощный инструмент, но не всегда идеален (см. раздел Когда регулярные выражения не подходят).

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

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

/abc/

Это выражение найдёт последовательность символов “abc” в строке (например, “abcdef”).

Некоторые ключевые элементы:

• . — любой одиночный символ, кроме перевода строки.
• • — предыдущий элемент может повторяться 0 или более раз.
• • — предыдущий элемент должен встречаться 1 или более раз.
• ? — предыдущий элемент опционален (0 или 1 раз).
• {n,m} — повторение от n до m раз.
• ^ и $ — начало и конец строки (якоря).
• [] — класс символов (например, [a-zA-Z]).
• \d — любая цифра (эквивалент [0-9]).
• \w — буква/цифра/_ (в ASCII).
• (?:…) — негруппирующая скобка.
• u-флаг и \p{L} — Unicode-совместимые проверки букв (в новых движках JS).

Пример с модификаторами:

const re = /^.{3,7}$/; // строка длиной от 3 до 7 символов

Совет: при работе с Unicode-символами используйте флаг u и управляющие символьные классы (например, /^\p{L}+$/u для букв любых алфавитов).

Как валидировать в JavaScript — простой рабочий пример

Шаги для базовой валидации:

1. Получить значение поля.
2. Составить регулярное выражение или выбрать уже готовый.
3. Проверить значение с помощью re.test(value) или value.match(re).
4. Показать пользователю сообщение об ошибке при несоответствии.

Пример реализации с обработчиком отправки формы:

  
  Отправить
  

Пояснение: используем preventDefault, показываем доступное сообщение и помечаем поле aria-invalid для вспомогательных технологий.

Валидация через HTML: атрибут pattern

Для простых случаев можно использовать HTML-атрибут pattern на input. Он полезен, когда логика проверки тривиальна и достаточно нативного поведения браузера.

Важно: в атрибуте pattern само выражение пишется без внешних слешей, но с якорями при необходимости. Пример корректного использования:

  
  Отправить

Если значение не соответствует шаблону, браузер покажет стандартное сообщение об ошибке (его можно переопределить через setCustomValidity в JS). Если регулярное выражение некорректно, браузер просто проигнорирует атрибут.

Совет: всё ещё добавьте серверную проверку — HTML-валидация легко обходится.

Частые шаблоны в один взгляд (шпаргалка)

Ниже — набор часто используемых regex для валидации. Примеры ориентированы на JavaScript (литералы между /…/):

• Строка фиксированной длины 7:

/^.{7}$/

• Строка длиной 3–7:

/^.{3,7}$/

• Минимум 3 символа (без ограничения сверху):

/^.{3,}$/

• Только буквы английского алфавита:

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

• Буквы любых алфавитов (Unicode), требуется поддержка флага u:

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

• Только цифры:

/^\d+$/

• Буквы и цифры (алфавит ASCII):

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

• Логин: буквы, цифры, подчёркивание, дефис:

/^[\w-]+$/

• Телефон: только цифры, длина 9–15 (общая проверка международного номера):

/^\d{9,15}$/

• Телефон с форматом ###-###-#### (из MDN):

/^(?:\d{3}|\(\d{3}\))([-\/\.])\d{3}\1\d{4}$/

• Дата формата DD-MM-YYYY (простейшая проверка формата):

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

Примечание: многие из этих выражений проверяют только формат, но не корректность (например, 31-02-2020 пройдёт проверку формата). Для полной проверки даты используйте парсинг и бизнес-логику.

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

• Валидация сложных дат (учёт високосных годов, длины месяцев) — лучше парсить и проверять объект Date.
• Проверка корректности e‑mail на 100% — RFC-совместимые regex чрезвычайно длинные и хрупкие; валидация по значению домена и отправка подтверждения надежнее.
• Форматы, зависящие от локали (адреса, имена) — regex часто блокируют допустимые варианты.
• Валидация логики (например, взаимосвязанные поля) — нужна программная логика, а не один regex.

Альтернативы регулярным выражениям

• Нативные функции парсинга (Date, URL).
• Библиотеки: validator.js, yup, joi — дают читаемую схему и валидаторы.
• HTML-валидация (pattern, type=email и т.д.) для простых случаев.

Методика создания и тестирования регулярных выражений

1. Определите требования: набор допустимых символов, минимальная и максимальная длина, формат.
2. Составьте минимальное выражение и проверьте на позитивных и негативных примерах.
3. Добавьте якоря ^ и $ чтобы избежать частичных совпадений.
4. Используйте инструменты: Regex101, браузерную консоль, unit-тесты.
5. Покройте тестами: позитивные примеры, негативные, граничные условия.

Краткая последовательность тестов (минимум):

• Позитивные: 5–10 валидных значений.
• Негативные: 5–10 недопустимых (пустая строка, короткая/длинная, запрещённые символы).
• Граничные: длины = min, min-1, max, max+1.

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

• Для каждого поля есть тест-кейсы с ожидаемым результатом.
• При ошибке пользователю показывается понятное сообщение (не «invalid»).
• Серверная валидация повторяет основные проверки.
• Проверка доступности: сообщения доступны экранным читалкам (aria-live, role=”alert” или aria-describedby).

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

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

• Использует якоря ^ и $ где нужно.
• Тестирует выражение в консоли/инструменте.
• Добавляет сообщения об ошибках с aria-атрибутами.
• Дублирует важные проверки на сервере.

QA:

• Проверил положительные/отрицательные примеры.
• Отловил граничные случаи (min/max).
• Проверил поведение при пустых значениях и при копировании/вставке.

Продуктовый менеджер:

• Установил приемлемые ограничения (сколько символов, какие символы).
• Решил, какие поля проверяются на клиенте, какие — только на сервере.

Шпаргалка по безопасности и приватности

• Никогда не полагайтесь только на клиентскую валидацию — всегда проверяйте данные на сервере.
• Не включайте в регулярные выражения чувствительные правила, которые раскрывают внутреннюю логику (например, строгие ошибки по формату, которые помогают злоумышленникам угадывать структуру).
• Для полей с персональными данными (телефоны, email) соблюдайте правила хранения и передачи данных согласно локальным законам (например, GDPR при работе с данными ЕС).

Совместимость и советы по миграции

• Некоторые синтаксические конструкции (например, Unicode property escapes \p{L}) требуют современного движка JS и флага u. Если поддержка старых браузеров критична — используйте более простые классы или полифиллы.
• HTML-атрибут pattern поддерживается во всех современных браузерах, но поведение сообщений может различаться — для единообразия используйте собственные сообщения через setCustomValidity.

Примеры тест-кейсов (приёмочные сценарии)

Пример для логина /^[a-zA-Z\d_-]{3,16}$/:

• Успех: “user_1” → валиден
• Неуспех: “ab” → слишком короткий
• Неуспех: “user!” → запрещённый символ
• Граница: “abc” → валиден
• Граница: 16 символов → валиден, 17 → не валиден

Потенциальные ошибки и распространённые паттерны (галерея краевых случаев)

• Забытые якоря ^ и $ — выражение может найти совпадение внутри строки, а не проверить всю строку.
• Неправильное использование флага g при тестировании: re.test при g-флаге меняет lastIndex, что может привести к непредсказуемым результатам при последовательных вызовах.
• Unicode-задержки: \w и \d основаны на ASCII и могут не включать символы других языков.

Важно: если используете re.test несколько раз с одним и тем же объектом Regex и флагом g, создавайте новый объект или сбрасывайте lastIndex = 0.

Decision flowchart — выбрать между HTML pattern и JavaScript

flowchart TD
  A[Нужна валидация поля?] --> B{Требования просты?}
  B -- Да --> C[Использовать HTML pattern]
  B -- Нет --> D{Нужна логика/асинхрон?}
  D -- Да --> E[Использовать JavaScript на клиенте]
  D -- Нет --> F[Можно комбинировать: pattern + JS для UX]
  C --> G[Не забыть серверную проверку]
  E --> G
  F --> G

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

1. Минимизируйте выражение: начните с простой части и постепенно добавляйте условия.
2. Используйте онлайн-инструменты (Regex101) — они показывают группы и совпадения.
3. Покройте unit-тестами ключевые сценарии.
4. Проверьте поведение с флагами (i, g, m, u).

Резюме

Регулярные выражения — удобный инструмент для валидации форм: они компактны и быстры. Для простых форм хватит HTML-атрибута pattern и минимального JS, для сложных случаев — используйте JS и сопровождающие проверки на сервере. Всегда тестируйте выражения на позитивных и негативных примерах, учитывайте Unicode и доступность.

Полезные действия на будущее:

• Соберите набор шаблонов, которые повторяются в проекте.
• Покройте валидацию unit-тестами и интеграционными тестами.
• Документируйте ограничения для продуктовой команды.

Ключевые ссылки для продолжения обучения: MDN JavaScript guide (регулярные выражения), Regex101 (интерактивный тестировщик), документация по HTML-атрибуту pattern.