Невалидные данные что это
Что означает термин «валидный/невалидный»?
Невалидный емейл-адрес
Невалидное задание
Невалидное название
Последнее время эти понятия стали очень популярны.
Такие термины можно встретить в интернете. Я эти термины понимаю так:
Валидный.
Это значит действующий, соответствующий определённым требованиям, нормам, правилам, стандартам.
Например, для вёрстки сайтов существуют правила и нормы, разработанные Консоциумом Всемирной Паутины.
Проверить сайт на соответствие данным правилам можно здесь.
Если ошибок найдено не будет, то можно сказать, что исходный код вашего сайта является валидным.
Невалидный.
Это понятие является противоположным понятию «валидный».
Если сертификат электронной подписи является невалидным, то он может быть просрочен, или у вас не установлены необходимые корневые сертификаты.
Также добавлю, что понятия «валидный» и «невалидный» имеют иностранные корни.
Переводятся они так: «действительный», «допустимый».
Валидный и невалидный это прилагательные:
Пример использования слова: «Если параметр не указан, то создается невалидный объект, который ни на что не указывает.»
Обычной электронные почтовые сервисы сразу укажут вам на невалидность e-mail адреса, написав, что такой не может быть использован. Они имеют встроенные валидаторы, эти валидаторы-то и проверят автоматически ваш адрес, валиден он или нет.
В английском, кстати, невалидный звучит, как инвалид invalid, что и без перевода понятно. Что значит инвалид знают все.
Что не так с валидацией данных и при чем тут принцип подстановки Лисков?
Если вы иногда задаете себе вопрос: «а всё ли хорошо мне в этот метод приходит?» и выбираете между «а вдруг пронесет» и «лучше на всякий случай проверить», то добро пожаловать под кат…
Поправка: Как заметили lorc и 0xd34df00d, то, о чем ниже идет речь, называется зависимыми типами. Почитать о них можно тут. Ну а ниже исходный текст с моими соображениями по этому поводу.
При разработке часто возникает потребность проверки валидности данных для некоторого алгоритма. Формально это можно описать следующим образом: пусть мы получаем некоторую структуру данных, проверяем ее значение на соответствие некоторой области допустимых значений (ОДЗ) и передаем ее дальше. Впоследствии эта же структура данных может быть подвергнута такой же проверке. В случае неизменяемости структуры, повторная проверка ее валидности – очевидно лишнее действие.
Хотя валидация может действительно быть долгой, проблема тут не только в производительности. Гораздо неприятнее лишняя ответственность. У разработчика нет уверенности нужно ли проверять структуру на валидность еще раз. Кроме лишней проверки, можно наоборот допустить отсутствие всякой проверки, неверно предполагая, что структура была проверена ранее.
Таким образом, допускаются неисправности в методах, которые ожидают проверенную структуру и работают некорректно со структурой, чье значение выходит за некоторую область допустимых значений.
В этом таится неочевидная более глубокая проблема. На самом деле, валидная структура данных представляет собой подтип исходной структуры. С этой точки зрения, проблема с методом, принимающим только валидные объекты, эквивалентна следующему коду на вымышленном языке:
Согласитесь, что теперь проблема гораздо яснее. Перед нами каноничное нарушение принципа подстановки Лисков. Почитать почему нарушать принцип подстановки плохо можно, например, тут.
Решить проблему передачи невалидных объектов можно с помощью создания подтипа для исходной структуры данных. Например, можно создавать объекты через фабрику, которая по исходной структуре возвращает либо валидный объект подтипа, либо null. Если мы изменим сигнатуру методов, ожидающих валидную структуру так, что они станут принимать только подтип, то проблема исчезнет. Так же помимо уверенности в том, что система точно работает, уменьшится количество валидаций на квадратный сантиметр кода. Еще одним плюсом является то, что такими действиями мы перекладываем ответственность валидации данных с разработчика на компилятор.
В Swift’е, на уровне синтаксиса, решается проблема проверки на null. Идея состоит в том, чтобы разделить типы на допускающие значение null и не допускающие. При этом сделано это в виде сахара таким образом, что программисту не требуется объявлять новый тип. При объявлении типа переменной ClassName гарантируется, что в переменной ненулевое значение, а при объявлении ClassName? переменная допускает значение null. При этом между типами существует коваринтность, то есть в методы, принимающие ClassName?, можно передать и объект типа ClassName.
Эту идею можно расширить до задаваемых пользователем ОДЗ. Снабжение объектов метаданными, содержащими ОДЗ, хранящимися в типе, устранит описанные выше проблемы. Хорошо бы получить поддержку такого средства в языке, но такое поведение реализуемо и в «обычных» ОО-языках, таких как Java или C# с помощью наследования и фабрики.
Ситуация с валидацией данных это очередное подтверждение того, что в ООП сущности берутся не из реального мира, а из инженерных потребностей.
UPD: Как правильно подметили в комментариях, подтипы создавать стоит только в том случае, если мы получим дополнительную надежность и уменьшим количество одинаковых валидаций.
Так же в статье не хватает примера. Пусть на вход к нам поступают некоторые пути файлов. Наша система в некоторых случаях работает со всеми файлами, а в некоторых случаях только с файлами, к которым мы имеем доступ. Далее мы хотим передать их в разные подсистемы, которые так же работают как с доступными, так и с недоступными файлами. Далее эти подсистемы передают файлы еще дальше, где опять не понятно файл доступен или нет. Таким образом во всяком сомнительном месте появится проверка доступа или может напротив забудется. Из-за этого система усложнится в силу повсеместной неоднозначности и проверок. А проверки эти грузят диск и вообще тяжелые. Можно эту проверку кешировать в булевом поле, но это нас не избавит от самого факта необходимости проверки. Я предлагаю ответственность проверки переложить с разработчика на компилятор.
Эссе о валидации данных
Зачем нужна валидация данных?
Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.
Где и когда выполнять валидацию данных?
Как уже было сказано выше, с точки зрения уменьшения нагрузки лучше всего вообще не выполнять валидацию данных.
Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.
Как выполнять валидацию данных?
Какой способ валидации следует применять на практике в том или ином случае? Чаще всего одним способом ограничиться не удаётся, да и не нужно. Валидацию данных можно и нужно выполнять в несколько этапов, усложняя проверки.
Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.
После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.
Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.
Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.
Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.
Тестирование валидаторов
Завершим статью демонстрацией различных видов валидаторов, а также некоторыми рекомендациями относительно того, как при тестировании проверять правильность их работы.
Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:
Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:
Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:
Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:
А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:
Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:
Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.
Тестировщику необходимо все эти ситуации отрабатывать. Во-первых, нужно проверять валидацию на всех уровнях. Во-вторых, нужно проверять согласованность валидаторов на разных уровнях. В-третьих, надо искать пути обхода валидаторов, пытаясь добраться до следующего уровня без предварительных проверок.
Заключение
Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.
Валидность
Добавлено в закладки: 0
Валидность – это
1) мера соответствия, которая показывает насколько соответствуют поставленным задачам полученные результаты и разработанная методика исследования;
2) фундаментальное понятие в экспериментальной психологии и психодиагностике. Различают такие типы валидности: валидность по содержанию, конструктивная валидность, прогностическая валидность, валидность по критерию. Безупречную валидность имеет только теоретический безупречный эксперимент: эксперимент, при котором получаемый эффект вызывает независимую переменную, соответствует полностью реальности, а его итоги поддаются без дополнительных ограничений обобщению.
Как в статистике, так и в психологии, валидное измерение — такое измерение, которое измеряет то, что оно обязано измерять (эта узкая трактовка “валидности” – наиболее популярная, она по факту соответствует понятию “конструктная валидность”). То есть, например, при валидном измерении интеллекта измеряют именно интеллект, а не что-то другое. Безупречный эксперимент (возможный только в теории) будет иметь безупречную валидность: он точно будет показывать, что экспериментальный эффект вызван изменением независимой переменной, он будет соответствовать полностью реальности, его итоги можно без ограничений обобщить.
Когда говорят о степени валидности, рассматривают то, насколько итоги исследования соответствуют поставленным задачам (но при этом валидность не измеряется в каких-нибудь условных единицах).
Важная особенность валидности – её невозможно единожды установить и использовать это доказательство в качестве финального аргумента “за” качество определенной методики или эксперимента. Валидность нужно постоянно обосновывать новыми данными, в независимых исследованиях перепроверять.
Способы установления валидности методики
Зачастую понятие “валидность” обсуждают в контексте конкретных экспериментов или методик. Может быть при этом поставлен вопрос и о валидности в целом определенного метода (к примеру, ассессмент центра или метода тестирования). Подобные исследования проводят при помощи мета-анализа.
Существуют три главных метода установления валидности методики.
I. Оценка содержательной валидности
Содержательная валидность – степень соответствия содержания заданий методики реальной деятельности, в которой проявляют свойство, измеряемое в методике. Частным случаем содержательной валидности является так называемая очевидная (фейс или лицевая) валидность – степень соответствия методики ожиданиям оцениваемых. Для большей части методик считают важным, чтобы для участника оценки очевидна связь меж содержанием процедуры оценки и реальной деятельностью, которая является объектом оценки (семейная, профессиональная, учебная и так далее.).
II. Оценка конструктной валидности
Конструктная валидность – степень обоснованности того, что методика измеряет действительно заданные и при этом обоснованные научно конструкты. Есть, как минимум, две стратегии установления конструктной валидности.
Подход первый — «конвергентная валидизация» — проверка ожидаемой связи итогов конкретной методики с показателями прочих методик, которые измеряют сходные характеристики. К примеру, если для измерения какой-нибудь черты есть несколько методик, было бы целесообразным провести эксперименты по хотя бы двум, и тогда при выявлении высокой позитивной корреляции их итогов меж собой можно говорить о валидности. Главная цель конвергентной валидизации — определение того, будут ли оценки теста варьироваться соответственно с ожиданиями.
Подход второй — «дивергентная валидизация». Проверка валидности тут заключается в том, что тест не может измерять никакой черты, с которой он и не должен быть связан теоретически.
III. Оценка критериальной валидности
Критериальная валидность – степень соответствия внешних критериев, определенных заранее, и результатов методики, определенная статистическими методами. Подобными критериями могут быть:
Одним из типов критериальной валидности является так называемая “прогностическая” валидность. Этот тип валидности применяется, когда методика призывается давать определенный прогноз поведения человека. Соответственно, когда прогноз с течением времени оправдывается, это говорит о том, что методика является валидной прогностически.
Профессиональные разработчики методик должны обосновывать все перечисленные типы валидности и проводить постоянный сбор свидетельств в пользу валидности их инструментов.
Типы валидности
В разных источниках упоминают различные названия, что может создать определенную путаницу. В экспериментальной психологии ключевые понятия:
Для организационной психологии и психодиагностики более традиционной является классификация из трех главных типов валидности:
Мы коротко рассмотрели валидность: типы и способы установления. Оставляйте свои комментарии или дополнения к материалу.
Валидация: что это такое, зачем нужна и как проводить гигиену базы
Email-маркетинг — это не только красивые письма, но и грамотная работа с базой подписчиков. Рассказываем, как работать с «живыми» адресами и получать высокие показатели OR и CTR и зачем вообще проверять имейлы.
Что такое валидация и с чем её едят
Валидация в email-маркетинге — это процесс проверки адресов электронной почты на пригодность для рассылок. Валидными считаются существующие и правильно написанные адреса, не замеченные в подозрительных действиях. То есть те, которые могут получать рассылки.
Невалидные — адреса, которые написаны с ошибками в домене (@mail.ru) или префиксе (name@). Невалидными также называют несуществующие адреса, дубликаты, временные и одноразовые ящики, спам-ловушки.
Условно валидные — существующие хорошие адреса, которые по той или иной причине сейчас не могут получать рассылки. Например, когда ящик получателя переполнен. После того, как адрес снова будет доступен для получения новых рассылок — он снова станет валидным.
Такие адреса в базе могут появиться, если контакты собирались в офлайне — через анкеты, опросы или, например, флаеры. Ещё одна явная причина этому — если в форме регистрации не был настроен Double Opt In (двойное подтверждение подписки).
Невалидной также может оказаться устаревшая база подписчиков: пользователи могли удалить свою почту или вовсе забыть о том, кто вы, и отписаться от рассылки.
Превалидация и стандартизация базы
Чтобы в базу попадали только корректные адреса, можно подключить проверку данных на этапе заполнения формы. Превалидация позволяет снизить количество ошибок при заполнении формы или сразу исправить их.
По сути, это скрипт, который проверяет в режиме реального времени заполнение формы подписки. Он заранее отсеивает «неликвидную» информацию: подставлен ли знак @ (явно обязательная часть имейл-адреса) и правильно ли написан домен (gmail вместо gamil).
Есть ещё такое понятие, как стандартизация базы — отдельная проверка базы на соответствие стандартам и исправление возможных ошибок.
Пример: есть список правильного написания распространённых имён, и если человек ошибся при регистрации и написал «Алксей», скрипт проверит его имя, соотнесёт с базой, исправит на «Алексей» и занесёт его в базу платформы. Это позволит отправлять хорошие письма, даже если человек ошибся при вводе.
Прогрев базы
Прогрев базы — это отправка писем частями с постепенным наращиванием количества единовременных отправок. Важно начинать отправки с активных сегментов базы, которые ранее уже получали и открывали письма. Если таких нет (email-маркетинг на стадии внедрения), то просто отправлять по проверенным адресам.
Пример прогрева базы в 100 000 подписчиков:
5 000 — 10 000 — 15 000 — 30 000 — 50 000 — 80 000 — 100 000
Прогревать базу необходимо не только на старте, но и если по ней давно не запускали рассылок. Первая отправка даст самую большую очистку и может показать высокий процент ошибок на доставки. Это нормально.
Ориентируйтесь на статистику и смотрите за доставляемостью. Если ошибок мало — можно увеличивать количество единовременных отправок. Нормальный показатель ошибок и жалоб при отправке рассылок — до 1%. Значит, проблем с базой нет. Если 2–5%, значит, часть адресов невалидна и необходимо реанимировать базу контактов.
Проверка базы на валидность
Рассылка по ненадёжной базе — это бесполезная трата денег, риск оказаться в чёрных списках почтовиков, блокировка в ESP-платформах и просто испорченная репутация отправителя. Вам же всё это не нужно?
Чтобы проверить список контактов на валидность, используют валидаторы — специальные сервисы (например, mailvalidator.ru). Они проверяют почту в три этапа:
Вот так выглядит полная проверка адреса:
А так — экспресс-проверка базы:
Конечно, проверить базу можно и вручную, но это не самая эффективная история: так вы сможете поправить лишь очевидно плохие имейлы и удалить дубликаты. Поэтому лучше проверять базу автоматически в платформе рассылок или через специальные сервисы.
Сервисы для проверки адресов
Для проверки одного почтового ящика существуют бесплатные сайты. Для массовой проверки используют как отдельные независимые сервисы проверки, так и программное обеспечение для ПК (ePochta Verifier) или инструменты, встроенные прямо в сервис рассылки. Рекомендуем несколько онлайн-валидаторов, которые помогут работать с базой.
Mailvalidator
Онлайн-платформа для контроля качества контактной базы. Список имейлов может загружаться в неё файлом, кроме того, возможно подключение непосредственно к сервису по API. В диагностику входит:
Чем хорош: двумя видами проверки. Экспресс для имейл-адресов с доступной почтовой историей и полная проверка для всех остальных. Визуализированные отчёты в виде графиков, персональные рекомендации по улучшению качества контактной базы, русскоязычный интерфейс.
Mailvalidator как встроенный инструмент используют и сами ESP-платформы. Например, Mailganer.
Цена за одну проверку зависит от количества имейлов. Чем их больше — тем выгоднее.
Zero Bounce
Онлайн-верификатор, который принимает файлы в формате TXT и CSV.
Чем хорош: сервис находит недостающую информацию по имейлам (имя, фамилию, пол, город, страну, IP), круглосуточная поддержка.
Есть бесплатный тариф, если адресов немного. Дальше — уже по подписке + можно настроить кастомно в зависимости от нужд бизнеса (вплоть до Enterprise с безлимитным тестированием за 999$).
Snov.io
Предлагает безопасную очистку списков email-адресов в режиме реального времени и помогает удалить все catch-all и невалидные адреса. Можно загрузить список адресов файлом, воспользоваться веб-приложением или подключить Email Verifier к CRM по API. Помимо этого можно добавлять и верифицировать адреса посредством расширения Email Verifier для Chrome.
Чем хорош: индивидуальная проверка, импорт списков адресов для верификации и экспорт результатов проверки в удобном формате, интеграция через API с CRM-платформами, большой выбор тарифов.
Прайсинг разный: пять тарифов на выбор, а также два месяца бесплатно при оформлении годовой подписки.
Проверяйте базы контактов перед отправкой, и тогда ваши письма попадут только в папку «Входящие». Да, на выходе количество адресов сократится, зато это будут активные подписчики, которые заинтересованы в вашей рассылке.
Вам может быть интересно
Посмотрите вебинар, в котором наш технический директор Александр Каринцев сравнивает между собой ТОП‑5 платформ для рассылок.
ПОЛУЧИЛОСЬ!
Скоро вы начнете получать нашу рассылку