что такое валидация формы
Что такое валидация
Основные определения
Это процесс проверки данных, введенных пользователем, на соответствие заданным критериям (например, на отсутствие ошибок в данных).
Это введенная пользователем информация, которая будет провалидирована (ФИО, адрес, город, номер телефона, ИНН и др.).
Требования, которым должны соответствовать введенные данные (номер мобильного телефона должен состоять из 11 цифр, имя должно быть написано латинскими буквами и т.д.)
Задача валидации
Основной задачей валидации является предоставление полнофункционального инструмента валидации форм в целом и отдельных контролов ввода. Валидация осуществляет проверку данных на их корректность.
Предмет валидации — данные, а не визуальные контролы. Логика в том, чтобы валидировать не контрол, а значение, которое будет записано в этот контрол. Валидация позволяет проверить данные до того, как они будут отправлены на сервер.
Виды валидации
В Wasaby существует три вида запуска валидации:
Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.
Соответственно, самый быстрый способ сообщить об ошибке — мгновенная валидация. Она возможна только в тех случаях, когда в процессе ввода понятно, что значение некорректное. Чаще всего, такие ошибки связаны с неправильной раскладкой клавиатуры или вводом букв в цифровое поле (ИНН, номер телефона и другие). Для этих случаев обычно используют поля с масками: ввод неподходящих символов в них заблокирован.
Валидация при потере фокуса — основной вид запуска валидации. Валидация срабатывает сразу после потери фокуса, если значение в поле заполнено.
Валидация при отправке формы — для тех случаев, когда запуск валидации по потере фокуса невозможен. Используйте этот вид запуска валидации, когда нельзя проверить поля по потере фокуса. Например, для проверки заполнения обязательных полей. Проверка происходит после того, как пользователь нажал кнопку отправки данных.
Валидация на клиенте и на сервере
Общий алгоритм валидации данных, введенных пользователем, можно представить следующим образом:
Даже если данные будут проверены на клиенте, на сервере они должны будут пройти повторную проверку.
| Преимущества | Недостатки | |
|---|---|---|
| Клиент | Валидация данных на клиенте позволяет произвести предварительную проверку данных без отправки их на сервер. Процесс проверки будет быстрым, пользователь моментально увидит результат. Такая валидация позволяет избежать «забивания» канала передачи данных. | У злоумышленников есть доступ к процессу валидации, соответственно, проверка данных на клиенте является небезопасной. |
| Сервер | Процесс валидации безопасен, поскольку доступа к валидации на сервере у злоумышленников нет. | Если валидировать данные только на сервере, канал передачи данных может быть перегружен лишними запросами, поскольку данные каждый раз будут перемещаться между клиентом и сервером. |
Итак, проверка на стороне клиента хороша для ускорения обратной связи с клиентами. Однако она недостаточна, поскольку ее объем действия очень ограничен. Проверка выполняется только в пользовательском интерфейсе браузера. Проверка на стороне сервера является обязательной, поскольку проверка на стороне клиента не гарантирует, что на сервер будут поступать неподтвержденные данные.
Контролы с внутренней валидацией
Часть контролов поддерживают внутреннюю валидацию. Например, Controls/date:BaseInput и Controls/dateRange:Input проверяют корректность введенных данных и показывают сообщение, если данные введены неправильно.
Такие контролы имеют внутри себя встроенный контейнер валидации и их можно не оборачивать внешним.
Валидаторы для Controls/date:BaseInput передаются во внутренний контейнер валидации с помощью опции valueValidators, которая содежит массив валидаторов. Валидаторы проверяют значение опции value.
У Controls/dateRange:Input есть две опции startValueValidators и endValueValidators, которые содержат массивы валидаторов. Валидаторы проверяют значение опций startValue и endValue соотвественно.
Валидация форм на стороне клиента
Перед отправкой данных на сервер важно убедиться, что все обязательные поля формы заполнены данными в корректном формате. Это называется валидацией на стороне клиента и помогает убедиться, что данные, введённые в каждый элемент формы, соответствуют требованиям. Данная статья проведёт вас через основные концепци и примеры валидации на стороне клиента.
| Начальные требования: | Владение компьютером, достаточное понимание HTML, CSS, и JavaScript. |
|---|---|
| Цель: | Понять, что такое валидация на стороне клиента, почему это важно и как применять различные техники для её реализации. |
Валидация на стороне клиента — это первичная проверка введённых данных, которая существенно улучшает удобство взаимодействия с интерфейсом; обнаружение некорректных данных на стороне клиента позволяет пользователю немедленно их исправить. Если же проверка происходит только на сервере, процесс заполнения может быть более трудоёмким, так как требует повторения одних и тех же действий отправки данных на сервер для получения обратного ответа с сообщением о том, что нужно исправить.
Однако, не следует рассматривать валидацию на стороне клиента как достаточную меру безопасности! Любые данные, отправляемые через форму, необходимо дополнительно проверять на безопасность и на стороне сервера, поскольку валидацию на стороне клиента достаточно просто обойти и она может не остановить злоумышленников. Чтобы лучше понимать потенциальные угрозы, рекомендуем ознакомиться с разделом Безопасность вебсайтов; валидация на стороне сервера выходит за рамки этого модуля, но о ней следует помнить.
Что такое валидация формы?
Зайдите на любой популярный сайт, имеющий форму регистрации. Вы заметите, что при вводе данных в неправильном формате, пользователя сразу уведомляют о наличии проблемы. Вы получите примерно такое сообщение:
Это называется валидацией формы. По мере ввода, браузер и/или сервер проверяют данные, чтобы определить, соответствуют ли они требуемому формату. Валидация, выполняемая в браузере, называется валидацией на стороне клиента, а выполняемая на сервере — валидацией на стороне сервера. В этом разделе мы сосредоточимся на валидации, выполняемой на стороне клиента.
Если формат корректен, приложение позволяет отправить данные на сервер и (обычно) сохранить в базу данных; в противном случае выводится сообщение с описанием того, что нужно исправить, позволяя ввести данные снова.
Мы хотим максимально упростить заполнение веб-форм. Тогда почему мы настаиваем валидации данных? На это есть три основные причины:
Предупреждение:: Никогда не доверяйте данным, передаваемым на сервер клиентской программой. Даже если ваша форма правильно валидируется и не допустит введение потенциально вредоносных данных на стороне клиента, злоумышленники по-прежнему могут изменить сетевой запрос.
Типы валидации на стороне клиента
Существует два типа валидации на стороне клиента, с которыми вы столкнётесь в Интернете:
Использование встроенной валидации форм
Одной из самых важных функций элементов форм HTML5 является способность валидировать бóльшую часть пользовательских данных без использования JavaScript. Это выполняется с помощью атрибутов валидации у элементов формы. Многие из них мы уже рассмотрели в этом курсе:
Если данные, введённые в поле формы, соответствуют правилам перечисленных выше атрибутов, они считаются валидными, если нет — не валидными
Когда элемент валиден, справедливы следующие утверждения:
Когда элемент не валиден, справедливы следующие утверждения:
Примеры встроенной валидации форм
В этом разделе мы протестируем некоторые из атрибутов, которые обсуждали выше.
Простой начальный файл
Для начала скопируйте файл fruit-start.html в новую папку на вашем жёстком диске.
Атрибут required
Обратите внимание на CSS, который включён в файл примера:
Данный CSS задаёт полю красную пунктирную рамку, когда оно не валидно, а когда валидно — сплошную чёрную. Мы также добавили фоновый градиент для обязательных не валидных полей. Проверьте новое поведение в примере ниже:
Примечание: Рабочий пример можно найти на GitHub по адресу fruit-validation.html (отдельно можно найти исходный код.)
Попробуйте отправить форму без введения значения. Обратите внимание, что не валидное поле получает фокус, появляется сообщение об ошибке («Заполните это поле») и блокируется отправка формы.
Примечание: Для повышения удобства взаимодействия указывайте пользователям, какие поля являются обязательными. К тому же, этого требует руководство по обеспечению доступности WCAG. Требуйте обязательного ввода только тех данных, которые вам действительно нужны: например, так ли важно знать пол или должность пользователя?
Валидация с помощью регулярного выражения
Регулярные выражения достаточно сложны и мы не подем подробно рассматривать эту тему в данной статье. Ниже приведены несколько примеров, чтобы дать вам представление о том, как они работают.
Есть еще много возможностей, которые мы не упомянули. Полный список со множеством примеров можно найти в документации по Регулярным выражениям
Давайте рассмотрим пример. Добавьте в атрибут pattern следующий шаблон:
Это даёт нам следующее обновление — опробуйте его:
Примечание: Рабочий пример можно найти на GitHub по адресу fruit-pattern.html (исходный код.)
В этом примере элемент принимает одно из четырёх возможных значений: строку «banana», «Banana», «cherry», или «Cherry». Регулярные выражения чувствительны к регистру, но с помощью шаблона «Aa», вложенного в квадратные скобки, мы сделали поддержку написания слова как с большой, так и с маленькой буквы.
Подставьте в атрибут pattern приведённые выше примеры регулярных выражений, и посмотрите, как это повлияет на валидацию введённого в поле значения. Попробуйте написать свои шаблоны проверки и посмотрите, что получится. По возможности, делайте их связанными с фруктами, чтобы примеры имели смысл.
Примечание: Элемент
Ограничение длины вводимых значений
Можно ограничить максимально допустимое количество символов для текстовых полей или
Ограничение допустимых значений
Давайте рассмотрим другой пример. Создайте новую копию файла fruit-start.html.
Содержимое элемента замените на:
Примечание: Рабочий пример можно найти на GitHub по адресу fruit-length.html (исходный код.)
Полный пример
Ниже представлен полный пример, демонстрирующий использование встроенного функционала валидации. Сначала немного HTML:
И немного CSS для стилизации HTML:
Примечание: Рабочий пример можно найти на GitHub по адресу full-example.html (исходный код.)
Валидация форм с помощью JavaScript
Если нужно управлять внешним видом встроенных сообщений об ошибке или работать с устаревшими браузерами, которые не поддерживают встроенную валидацию форм HTML, вам следует использовать JavaScript. В данном разделе мы рассмотрим различные способы делать это.
Constraint Validation API
Большинство браузеров поддерживают Constraint Validation API, который состоит из набора свойств и методов, доступных на DOM-интерфейсах следующих элементов форм:
Для перечисленных выше элементов Constraint Validation API делает доступными следующие свойства.
Также для перечисленных выше элементов Constraint Validation API делает доступными следующие методы.
Реализация кастомного сообщения об ошибке
Как вы видели в примерах HTML5-валидации выше, каждый раз, когда пользователь пытается отправить не валидную форму, браузер отображает сообщение об ошибке. Способ отображения сообщения зависит от браузера.
У этих автоматических сообщений есть два недостатка:
Настройка таких сообщений об ошибках является одной из наиболее распространённых причин использования Constraint Validation API. Давайте рассмотрим простой пример, как это делается.
Начнём с простого HTML (Не стесняйтесь поместить это в пустой HTML-файл. Вы можете взять за основу свежую копию fruit-start.html, если хотите):
Добавьте на страницу следующий JavaScript:
Здесь мы сохраняем ссылку на поле email, а затем добавляем к нему обработчик события, который запускает код обработчика каждый раз, когда в поле меняется значение.
Попробовать пример можно ниже:
Примечание:: Данный пример можно найти на GitHub по адресу custom-error-message.html (отдельно можно найти исходный код.)
Более подробный пример
Теперь, когда мы разобрали простой пример, давайте посмотрим, как можно использовать данный API для создания более сложной валидацию.
Во-первых, HTML. Опять же, не стесняйтесь писать его вместе с нами:
Примечание: Ключевым моментом здесь является то, что добавление к форме атрибута novalidate отключает отображение встроенных сообщений об ошибке и позволяет вместо этого добавлять в DOM кастомные сообщения.
Перейдём к базовому CSS, чтобы немного улучшить внешний вид формы и обеспечить визуальную обратную связь при введении не валидных данных:
Теперь давайте рассмотрим JavaScript, который реализует кастомную валидацию.
Комментарии объясняют логику хорошо, но кратко:
Примечание: Рабочий пример можно найти на GitHub по адресу detailed-custom-validation.html (отдельно можно найти исходный код.)
Constraint Validation API явяется мощным инструментом валидации форм, позволяющим получить контроль над пользовательским интерфейсом, существенно превосходящий возможности HTML и CSS.
Примечание: Для получения дополнительной информации смотрите руководства Constraint validation guide и Constraint Validation API.
Проверка форм без встроенного API
В некоторых случаях, например, при необходимости поддержки устаревших браузеров или кастомных элементов формы, вы не сможете или не захотите использовать Constraint Validation API. Вы по-прежнему сможете использовать JavaScript для валидации форм, но для этого всё нужно будет писать самостоятельно.
Для создания своего валидатора формы, задайте себе несколько вопросов:
Пример без использования Constraint Validation API
Чтобы проиллюстрировать это дальше приводится упрощённая версия предыдущего примера, которая работает с устаревшими браузерами.
HTML почти тот такой же; мы только удалили функционал валидации HTML5.
CSS также не требует особых изменений; мы только заменили CSS-псевдокласс :invalid на реальный класс и не использовали селектор по атрибутам, так как он не работает в Internet Explorer 6.
Существенно изменился только JavaScript-код, который теперь должен выполнять гораздо больше работы.
Результат выглядит следующим образом:
Как вы можете видеть, сделать собственную валидацию не так уж и сложно. Сложность состоит лишь в том, чтобы сделать его кроссплатформенным и работающим с любой формой, которую можно создать. Для проверки формы доступно множество библиотек, например Validate.js.
Проверьте свои навыки!
Вы дошли до конца этой статьи, но можете ли вы вспомнить самую важную информацию? Вы можете найти дополнительные тесты, чтобы убедиться, что вы сохранили эту информацию, прежде чем двигаться дальше — Test your skills: Form validation.
Заключение
Для проверки формы на стороне клиента иногда требуется JavaScript, если вы хотите настроить стилизацию и сообщения об ошибках, но это всегда требует от вас внимательного отношения к пользователю. Всегда помните о необходимости помогать пользователям исправлять данные, которые они вводят. Для этого обязательно нужно:
После того, как вы убедились, что форма заполнена правильно, ее можно отправлять. Дальше мы рассмотрим отправку данных формы.
Валидация формы с HTML5 и регулярными выражениями
Дата публикации: 2019-05-08
От автора: валидация ввода формы в HTML5 — это то, к чему следует относиться серьезно. Без надлежащей валидации, если повезет, вы получите только много ненужных и несоответствующих вводимых данных. Однако существует также вероятность того, что хакеры смогут заполучить личные данные пользователей, которые доверили вам свою информацию.
Поскольку валидация важна, имеет смысл использовать инструменты и библиотек для проверки и очистки данных как для front-end, так и для back-end.
В этом руководстве основное внимание будет уделено использованию встроенных функций HTML5 для проверки различных типов ввода без каких-либо внешних библиотек. Очевидно, что вам не следует останавливаться только на проверке на основе HTML5, но это было бы хорошим началом для повышения безопасности форм на вашем веб-сайте.
Элемент ввода формы
Всякий раз, когда вы хотите получить какую-то информацию от своих пользователей, вы, скорее всего, будете использовать HTML-элемент input. Неважно, хотите ли вы получить имя пользователя, его фамилию, адрес электронной почты, город, в котором они в настоящее время живут, номер телефона или любимую спортивную команду. Элемент input является очень удобным способом получения информации от посетителей.
Тем не менее, некоторые злоумышленники хотели бы воспользоваться тем, что они могут вводить в элемент ввода и отправлять через форму практически любую строку. Точно так же могут быть пользователи, которые просто не знали, что вводят данные в неправильном формате.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Обе эти проблемы можно легко решить, используя с элементами формы некоторые атрибуты HTML5.
Атрибут type
Атрибут type определяет, какой тип ввода считается действительным для данного элемента. Если для атрибута type не указано значение, по умолчанию устанавливается тип text. Это в основном означает, что все виды вводимого текста будут считаться действительными для этого конкретного элемента.
Это полезно, когда вы хотите, чтобы пользователи вводили свои имена. Однако, когда вы хотите, чтобы они ввели адрес электронной почты или числа, такие как их возраст и вес, гораздо лучше установить для атрибута type что-то подходящее. Вот несколько значений, которые вы можете выбрать:
email: Пользователю будет предложено ввести адрес электронной почты в корректном формате. Например, они не могут просто написать myemail.com или что-то@ или @кое-что. Им нужно будет ввести значение, аналогичное myemail@domain.tld. Конечно, они все равно могут вводить несуществующие адреса электронной почты, но это другая проблема!
number: Позволяет обеспечить, чтобы допустимыми являлись только цифры. Например, когда вы в форме спрашиваете кого-то о его возрасте, он не сможет предоставить данные в формате «картофель» или «тридцать шесть». Ему нужно будет написать фактическое число, например, 36 или 15.
url: Вы можете установить для атрибута type url, чтобы пользователи вводили действительный URL-адрес. В этом случае они не смогут ввести что-то вроде tutsplus. Кроме того, tutsplus.com также будет считаться недействительным — пользователям необходимо будет ввести полный URL-адрес, например //tutsplus.com.
tel: Использование этого значения не так полезно, как другие, потому что формат телефонного номера варьируется во всем мире. Просто нет стандартного шаблона, который браузеры могли бы сопоставить с элементом ввода, чтобы определить, является ли число действительным. Тем не менее, установка типа tel может быть полезна на более позднем этапе, когда вы выполняете собственную пользовательскую валидацию.
Существует много других значений атрибута type, которые можно использовать для указания типа ввода, действительного для определенного элемента. Вы можете прочитать обо всех этих значениях на странице документации MDN по элементам ввода.
Следующая демо-версия на CodePen показывает, как мы можем использовать атрибут type для управления тем, что разрешено для различных полей ввода.
Атрибуты минимальной и максимальной длины
Еще один способ ограничить то, что является валидным вводом для элемента — использовать атрибуты minlength и maxlength. Они устанавливают минимальное и максимальное количество символов, которые необходимо ввести в элемент ввода, чтобы сделать его действительным.
Необходимое значения для обоих этих атрибутов будут варьироваться в зависимости от конкретного случая. Например, некоторые веб-сайты могут требовать, чтобы имя пользователя было длиной от 4 до 15 символов, в то время как другие могут ограничивать максимальную длину до 12 символов. Аналогично, люди в некоторых странах будут иметь необычно короткие или длинные имена по сравнению с другими.
Использование регулярных выражений для валидации формы
Установка значения атрибута type, безусловно, помогает ограничить то, что считается допустимым вводом. Однако вы можете пойти еще дальше и указать шаблон, которому должны следовать имя пользователя или адрес электронной почты, чтобы считаться действительными.
Допустим, вы хотите убедиться, что имена пользователей — это только буквенно-цифровые значения. Это можно легко реализовать с помощью атрибута pattern. Вам просто нужно установить для него регулярное выражение, которое будет действовать как ориентир, чтобы определить, какие входные данные будут действительными, а какие нет.
Вот несколько примеров использования регулярных выражений с атрибутом pattern.
Простая валидация формы без JS
В данной статье я бы хотел поделиться методом быстрой валидации полей с помощью разметки и стилей. Данный метод не является кроссбраузерным и рекомендуется к использованию только как дополнительная фича. По ходу статьи мы будем уменьшать наши шансы на кроссбраузерность, но повышать функциональность.
Давайте попробуем собрать стандартную форму, которая будет включать в себя: Имя, E-Mail, Телефон, Ссылку на сайт и допустим Ваш рост, чтобы поэксперементировать с числовым полем.
HTML5
Сейчас уже никого не удивить атрибутами валидации input полей, которое принес нам стандарт HTML5. Однако, обходить стороной мы его не станем — этот метод валидации является наиболее поддерживаемым в современных браузерах.
Самый простой путь валидации — это определить тип input поля и расставить атрибуты required которые отвечают за обязательность заполнения.
Применение этих двух атрибутов позволит гораздо эффективнее валидировать вводимую информацию нативными методами. Ну и конечно же поддержка этих свойств браузерами наиболее широка.
Отдельно хотелось бы сказать про тип поля tel. Ожидается что браузер будет валидировать телефонные номера, но нет, поле с типом tel используется сейчас только для автозаполнения. Дело в том, что валидация телефонных номеров очень неоднозначная задача из-за слишком большого количества различных форматов телефонных номеров в разных странах, которые просто никак не получится унифицировать и записать в одно правило.
Однако, нам на помощь приходит атрибут pattern. Этот атрибут принимает в себя значение регулярного выражения. В нашем случае рассмотрим вариант паттерна для ввода мобильного телефона в РФ: +7 (123) 456-78-91. Для этого добавим простое регулярное выражение в наше поле с телефоном, а также ограничим минимальное и максимальное количество символов:
Обычно я использую данный паттерн в связке с маской для ввода номера, но тут к сожалению без JS пока что не обойтись. Если вы не используете маску, то я бы не стал использовать паттерны на вводе телефона, поскольку это в большинстве случаев вызовет больше неудобств для пользователя.
Поддержка браузерами атрибута pattern на данный момент очень хорошая. iOS начиная с версии 10.3 полностью поддерживает данное свойство, до этого наблюдалось отсутствие подсказок о неправильном вводе данных.
Стоит также учитывать, что атрибут minlength до сих пор не поддерживается в браузерах IE, EDGE и только с версии 10.3 появился в iOS. Однако maxlength поддерживается везде и очень давно. Нам в целом хватит и этого.
Давайте также поставим ограничение для поля с ростом. Допустим мы предполагаем, что пользователь нашего сайта определенно не может быть ниже 100 см и выше 250 см. Так и напишем:
С поддержкой этих атрибутов в браузерах, все хорошо.
Перейдем к стилизации!
Для того чтобы кастомно стилизовать нашу валидацию, воспользуемся псевдоклассами :invalid и :valid. Поддержка этих псевдоклассов в браузерах позволяет использовать их максимально широко на данный момент.
Казалось бы, берем полученные знания и применяем! Но не все так просто как кажется, давайте проверим как это работает. В результате мы получим, что все наши поля изначально пустые и обязательные будут считаться не валидными, а все остальные валидными. Совсем не красиво и непонятно для пользователя, что от него хотят.
Мы можем пойти на небольшую хитрость и использовать псевдокласс :placeholder-shown. С помощью этого псевдокласса мы можем определить отображается ли сейчас значение placeholder в нашем поле ввода. Атрибут placeholder отображается только тогда, когда в наше поле ничего не введено. Соответственно, чтобы применить этот псевдокласс нам просто нужно обратить его свойство с помощью :not. В итоге получаем вот такую конструкцию:
Если прочитать дословно: окрасить красным цветом границу инпута, когда наше поле не валидно и когда в нем не отображается значение атрибута placeholder. Если ваше поле не имеет атрибута placeholder, можно просто поставить внутри пробел:
У данного метода есть только один минус: поддержка. Псевдоэлемент :placeholder-shown поддерживается во всех браузерах кроме IE и EDGE. К счастью :not не обладает таким недостатком.
Для примера я набросал все вышесказанное в CodePen и добавил еще немного возможностей: