Что означает термин «валидный/невалидный»?
Невалидный емейл-адрес
Невалидное задание
Невалидное название
Последнее время эти понятия стали очень популярны.
Такие термины можно встретить в интернете. Я эти термины понимаю так:
Валидный.
Это значит действующий, соответствующий определённым требованиям, нормам, правилам, стандартам.
Например, для вёрстки сайтов существуют правила и нормы, разработанные Консоциумом Всемирной Паутины.
Проверить сайт на соответствие данным правилам можно здесь.
Если ошибок найдено не будет, то можно сказать, что исходный код вашего сайта является валидным.
Невалидный.
Это понятие является противоположным понятию «валидный».
Если сертификат электронной подписи является невалидным, то он может быть просрочен, или у вас не установлены необходимые корневые сертификаты.
Также добавлю, что понятия «валидный» и «невалидный» имеют иностранные корни.
Переводятся они так: «действительный», «допустимый».
Валидный и невалидный это прилагательные:
Пример использования слова: «Если параметр не указан, то создается невалидный объект, который ни на что не указывает.»
Обычной электронные почтовые сервисы сразу укажут вам на невалидность e-mail адреса, написав, что такой не может быть использован. Они имеют встроенные валидаторы, эти валидаторы-то и проверят автоматически ваш адрес, валиден он или нет.
В английском, кстати, невалидный звучит, как инвалид invalid, что и без перевода понятно. Что значит инвалид знают все.
Эссе о валидации данных
Зачем нужна валидация данных?
Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.
Где и когда выполнять валидацию данных?
Как уже было сказано выше, с точки зрения уменьшения нагрузки лучше всего вообще не выполнять валидацию данных.
Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.
Как выполнять валидацию данных?
Какой способ валидации следует применять на практике в том или ином случае? Чаще всего одним способом ограничиться не удаётся, да и не нужно. Валидацию данных можно и нужно выполнять в несколько этапов, усложняя проверки.
Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.
После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.
Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.
Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.
Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.
Тестирование валидаторов
Завершим статью демонстрацией различных видов валидаторов, а также некоторыми рекомендациями относительно того, как при тестировании проверять правильность их работы.
Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:
Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:
Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:
Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:
А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:
Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:
Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.
Тестировщику необходимо все эти ситуации отрабатывать. Во-первых, нужно проверять валидацию на всех уровнях. Во-вторых, нужно проверять согласованность валидаторов на разных уровнях. В-третьих, надо искать пути обхода валидаторов, пытаясь добраться до следующего уровня без предварительных проверок.
Заключение
Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.
Что не так с валидацией данных и при чем тут принцип подстановки Лисков?
Если вы иногда задаете себе вопрос: «а всё ли хорошо мне в этот метод приходит?» и выбираете между «а вдруг пронесет» и «лучше на всякий случай проверить», то добро пожаловать под кат…
Поправка: Как заметили lorc и 0xd34df00d, то, о чем ниже идет речь, называется зависимыми типами. Почитать о них можно тут. Ну а ниже исходный текст с моими соображениями по этому поводу.
При разработке часто возникает потребность проверки валидности данных для некоторого алгоритма. Формально это можно описать следующим образом: пусть мы получаем некоторую структуру данных, проверяем ее значение на соответствие некоторой области допустимых значений (ОДЗ) и передаем ее дальше. Впоследствии эта же структура данных может быть подвергнута такой же проверке. В случае неизменяемости структуры, повторная проверка ее валидности – очевидно лишнее действие.
Хотя валидация может действительно быть долгой, проблема тут не только в производительности. Гораздо неприятнее лишняя ответственность. У разработчика нет уверенности нужно ли проверять структуру на валидность еще раз. Кроме лишней проверки, можно наоборот допустить отсутствие всякой проверки, неверно предполагая, что структура была проверена ранее.
Таким образом, допускаются неисправности в методах, которые ожидают проверенную структуру и работают некорректно со структурой, чье значение выходит за некоторую область допустимых значений.
В этом таится неочевидная более глубокая проблема. На самом деле, валидная структура данных представляет собой подтип исходной структуры. С этой точки зрения, проблема с методом, принимающим только валидные объекты, эквивалентна следующему коду на вымышленном языке:
Согласитесь, что теперь проблема гораздо яснее. Перед нами каноничное нарушение принципа подстановки Лисков. Почитать почему нарушать принцип подстановки плохо можно, например, тут.
Решить проблему передачи невалидных объектов можно с помощью создания подтипа для исходной структуры данных. Например, можно создавать объекты через фабрику, которая по исходной структуре возвращает либо валидный объект подтипа, либо null. Если мы изменим сигнатуру методов, ожидающих валидную структуру так, что они станут принимать только подтип, то проблема исчезнет. Так же помимо уверенности в том, что система точно работает, уменьшится количество валидаций на квадратный сантиметр кода. Еще одним плюсом является то, что такими действиями мы перекладываем ответственность валидации данных с разработчика на компилятор.
В Swift’е, на уровне синтаксиса, решается проблема проверки на null. Идея состоит в том, чтобы разделить типы на допускающие значение null и не допускающие. При этом сделано это в виде сахара таким образом, что программисту не требуется объявлять новый тип. При объявлении типа переменной ClassName гарантируется, что в переменной ненулевое значение, а при объявлении ClassName? переменная допускает значение null. При этом между типами существует коваринтность, то есть в методы, принимающие ClassName?, можно передать и объект типа ClassName.
Эту идею можно расширить до задаваемых пользователем ОДЗ. Снабжение объектов метаданными, содержащими ОДЗ, хранящимися в типе, устранит описанные выше проблемы. Хорошо бы получить поддержку такого средства в языке, но такое поведение реализуемо и в «обычных» ОО-языках, таких как Java или C# с помощью наследования и фабрики.
Ситуация с валидацией данных это очередное подтверждение того, что в ООП сущности берутся не из реального мира, а из инженерных потребностей.
UPD: Как правильно подметили в комментариях, подтипы создавать стоит только в том случае, если мы получим дополнительную надежность и уменьшим количество одинаковых валидаций.
Так же в статье не хватает примера. Пусть на вход к нам поступают некоторые пути файлов. Наша система в некоторых случаях работает со всеми файлами, а в некоторых случаях только с файлами, к которым мы имеем доступ. Далее мы хотим передать их в разные подсистемы, которые так же работают как с доступными, так и с недоступными файлами. Далее эти подсистемы передают файлы еще дальше, где опять не понятно файл доступен или нет. Таким образом во всяком сомнительном месте появится проверка доступа или может напротив забудется. Из-за этого система усложнится в силу повсеместной неоднозначности и проверок. А проверки эти грузят диск и вообще тяжелые. Можно эту проверку кешировать в булевом поле, но это нас не избавит от самого факта необходимости проверки. Я предлагаю ответственность проверки переложить с разработчика на компилятор.
Так ли важен валидный код на сайте по мнению Google?
Валидность html и css по мнению Google
Весьма часто приходится слышать, что не очень валидный код веб-страниц препятствует продвижению сайта в поисковых системах. Как раз недавно в Google опубликовали хорошее видео по данной теме (о нём далее).
Знаю, что некоторые начинающие вебмастера особенно переживают: они проверяют свой ресурс в т.н. валидаторах, видят кучу ошибок и думают, что нормального ранжирования у них не будет.
Однако в большинстве случаев это совсем не так. Но сначала следует рассказать об этой «валидности».
Что такое валидный код на сайте?
Также для справки можно глянуть заметку из Википедии.
В сайтостроении есть разнообразные стандарты, по которым пишутся HTML и CSS коды. Что-то вроде ГОСТа. Например:
Указанием на стандарт, используемый на данной веб-странице, является первая строчка HTML-кода. Например, что-нибудь такое:
или — для HTML5 — такое:
Но всё дело в том, что нормальные красивые сайты можно делать без соблюдения всех этих стандартов. Более того, современный сайт практически невозможно сделать с полностью валидным кодом.
К примеру, установив какие-нибудь кнопки социальных сетей для сайта или виджет Facebook’а, мы уже (как правило) «теряем» эту валидность.
Поэтому и не стоит добиваться полной валидности (разве что из-за перфекционизма..).
Конечно, по-возможности, ошибки следует исправить. Но, например, правка CSS-файлов из-за того, что валидатор «ругается» не даст преимуществ при поисковом продвижении.
Гораздо важнее исправить ошибки, которые напрямую влияют на индексацию — почитайте, почему Яндекс или Гугл могут не индексировать сайт:
Как проверить валидность кода?
Самый известный способ — зайти на главные сервисы для этого:
— нужно просто ввести URL-адрес страницы своего сайта, нажать Enter и узнать об ошибках (они, скорей всего, есть):
Узнать валидность HTML-кода
Также есть неплохие плагины для браузеров. Например, «HTML VALIDATOR» для Firefox.
Валидный код и поисковое продвижение
Ну и наконец о том, ради чего начиналась эта статья. Если нет грубых ошибок в коде — то и не о чем беспокоиться. На продвижение в ПС это не повлияет.
Тем более, нет смысла делать абсолютно валидным CSS (отвечающий за внешний вид сайта): какая разница, что «внутри», если «снаружи» посетителю всё нравится — ведь в конце концов в ранжировании всё решают поведенческие факторы.
Ну а если не нравится — то валидность тут не поможет.
Валидный код и Google:
» alt=»»> В видео разбирается вопрос
Does the crawler really care about valid HTML? (Действительно ли роботу Гугла важна валидность HTML кода?)
На что получен однозначный ответ: валидный код — это хорошо, но если б стали учитывать его при ранжировании сайтов, то начали бы выходить в ТОП те сайты, у которых код чище, а не контент полезнее.
В общем, как обычно: главное — полезный контент.
С Яндексом ситуация аналогичная — здесь можно просто проанализировать его выдачу.
Кроме того, внедрение в сайты, например, семантической разметки (которая у Яндекса немного своя) сделает большинство документов неправильными с точки зрения валидаторов. В таком случае совсем не логичным бы было ухудшать их ранжирование из-за невалидного кода.
Сообщать мне о новых комментариях к этой статье
Боремся с невалидными телефонами и емейлами. Сохраняем конверсию
Привет! Я Лена из команды продукта Carrot quest.
Мы ввели автоматическую проверку данных в стандартных свойствах Email и Телефон. Теперь, когда пользователь попытается оставить почту без @ или пишет вместо телефона “купить самовар”, мы не записываем эти данные в карточку, а просим ввести корректные данные. Так сервис валидирует контакты перед отправкой в базу лидов.
Проверку проходят ответы пользователей, отправленные через инструменты Carrot quest, а именно:
Я расскажу, по каким правилам работает проверка, а также поделюсь кейсом, как это обновление повлияет на конверсию и улучшит процессы в командах маркетинга и продаж.
Зачем нужна проверка контактных данных
Каждый собранный с сайта контакт — это потенциальный клиент. Поэтому маркетологи бьются за то, чтобы собирать как можно больше лидов. Проблема в том, что часто маркетинг в погоне за лидами приводит некачественных лидов, до 70% которых потом отсеивают продажи.
В Carrot quest можно собирать лидов с помощью поп-апов, чат-ботов и даже чата, а потом передавать их в продажи через интеграции с CRM-системами.
Но до этого времени не все лиды по-настоящему были лидами. Расскажу, что это значит и как мы это исправили.
Раньше все формы Carrot quest принимали от пользователей любой ответ, без проверки на соответствие формату данных. Например, могло быть так:
Теперь мы проверяем корректность данных в стандартных свойствах Email и Телефон, если пользователь отправил их через поп-ап, автоответ или чат-бота.
По сути, это валидация, но не с помощью отправки смс или письма на почту, а еще до того как пользователь отправил данные. То есть ответ не запишется до тех пор, пока не пройдёт проверку на соответствие нашим правилам.
Чат-бот запрашивает номер телефона
В Carrot quest уже давно предусмотрена защита от отправки ручных и триггерных рассылок по невалидным адресам. Если вы загружаете в сервис уже собранную базу, мы автоматически проверим ее на несуществующие адреса. Почему это важно и как осуществляется наша пятиступенчатая проверка, вы можете прочитать в этой статье.
По каким правилам мы проверяем емейлы и телефоны
Наши правила проверки несложные и направлены, в первую очередь, на отсев мусорной информации.
Вы не можете ввести буквы и символы, кроме +,-,(), если вас просят оставить телефон, а в емейле есть обязательная проверка на наличие @ и точки. Подробнее о правилах валидации читайте в нашей базе знаний.
Важно также не путать проверку с маской: мы подсказываем в полях ввода и не приводим записываемый телефон к какому-то конкретному виду.
Слева маска, которая подсказывает, что необходимо ввести, а справа — проверка, которая не даёт отправить данные неподходящего формата
Carrot quest проверяет данные, которые записываются только в стандартные свойства Email и Телефон. Если вы записываете информацию в другие свойства — например, дополнительный телефон или рабочий емейл — то введённая информация проверяться не будет.
Проверка данных работает в:
Проверка данных НЕ работает при:
Почему дополнительные проверки в полях на самом деле не снижают конверсию
Если кратко: конверсия в ответ может упасть, но количество реальных лидов останется тем же.
А теперь давайте разберёмся.
Первый эффект, который вы можете заметить, — снижение конверсии в лида из ваших триггерных сообщений и ботов. Но не стоит паниковать. Мы провели эксперимент и доказали, что снижение конверсии в ответ не уменьшает количество реальных контактов.
Это чат-бот на сайте одного интернет-магазина. Последовательно задавая вопросы, бот определяет, какой товар лучше подойдёт пользователю, а потом просит оставить телефон, чтобы менеджер мог позвонить и оформить заказ. Мы замерили результаты до введения проверки, когда пользователь мог ввести в поле всё, что угодно, и после.
Результаты до введения проверки и после
Как видите, конверсия из начала диалога с чат-ботом на сайте в оставленный телефон упала. Но давайте копнём глубже и посмотрим на всех лидов, которых мы собрали в первом и втором случае:
Собранные лиды
Как видите, без валидации мы засчитывали в лидов людей, которые задавали вопросы боту или писали ответы текстом. Таким образом в аналитике завышалось реальное количество контактов. После валидации перед нами чистый список телефонов.
Если посчитать только валидные телефоны в первом случае, то и конверсия, и абсолютное количество лидов останутся на том же уровне, что и после валидации.
Конверсия в валидный телефон
Если вы заметите падение конверсии в триггерных сообщениях и чат-ботах, то вероятнее всего это связано с тем, что в аналитике больше не учитываются ненастоящие контакты, которые невозможно использовать. А значит, ваши данные стали точнее.
Налаживаем связь между маркетингом и продажами и ускоряем команду
Что еще даёт проверка вводимых данных?
Мы с вами только что провели достаточно много работы вручную: посмотрели на каждого лида и оценили, похожи ли данные, что он оставил, на телефон. То же самое приходилось делать менеджерам по продажам. Сейчаc валидация происходит автоматически. Это значит, что менеджеры получают очищенный список контактов и могут сфокусироваться на своей работе.
Это одно из обновлений, которое поможет наладить взаимодействие между маркетингом и продажами и адекватно оценивать количество собранных и обработанных лидов. Убирая лишнее, мы сохраняем время вашей команде.
Собирайте лидов с помощью инструментов Carrot quest, а мы позаботимся о валидности данных.
Больше о том, как лид-бот Carrot quest помогает онлайн-бизнесам
И подсказка напоследок. Чат-бот на сайте поможет не только собрать контакты, но и квалифицировать лидов: с помощью дополнительных вопросов вы сможете определить, насколько лид готов к покупке и автоматически передавать в продажи только горячих лидов, а остальным отправить подогревающую рассылку. Это еще больше сэкономит время менеджерам по продажам.
