Как проверить допустимые символы в полях формы?

Что проверяют

Умеете ли вы превратить «допустимые символы» в набор классов и тестовых данных, а не ограничиться парой букв и цифр. Следом обычно спрашивают, как проверить серверную валидацию, если клиент не даёт ввести лишнее.

Как отвечать

Сначала требования: белый список символов для каждого поля, длина, обрезаются ли пробелы, что происходит с недопустимым вводом. Потом классы тестовых данных:

• допустимые: буквы нужных алфавитов, цифры, разрешённые спецсимволы. Для имени это дефис и апостроф: Анна-Мария, O'Connor;
• кириллица целиком: обязательно ё и Ё, они не входят в диапазон [А-Яа-я], и такой регулярки хватает, чтобы Алёна не смогла зарегистрироваться;
• пробельные: пробел в начале и конце, два пробела подряд, табуляция, перевод строки, неразрывный пробел;
• Unicode: эмодзи, символы нулевой ширины, латинская «a», похожая на кириллическую;
• опасные для разметки и SQL: <script>, кавычки, &, ;, --. Данные должны сохраниться как есть и отобразиться экранированными, без двойного &.

Затем способы ввода. Фильтр на нажатие клавиш часто обходится вставкой из буфера, перетаскиванием и автозаполнением браузера. HTML-атрибут pattern проверяет значение целиком, но не срабатывает на пустом поле без required.

Главное: клиентская валидация это удобство, а защита живёт на сервере. Поэтому тот же набор отправляют прямо в API через Postman, curl или тестом с requests, в обход формы. Сервер обязан вернуть 400 или 422 с понятной ошибкой, а не 500.

Для автоматизации набор оформляют таблицей данных и прогоняют через параметризованный тест.

Где спотыкаются

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

Забывают, что длину считают по-разному. maxlength считает единицы UTF-16, эмодзи занимает две и больше, а сервер может считать байты или символы по-своему.

Ставят латинский [A-Za-z] на поля, где люди вводят имена по-русски, или теряют ё в кириллическом диапазоне.