regex — PHP все еще необходимы шаблоны или filter_var заботится обо всем этом
Когда я читал статью этим утром, я наткнулся на это
Большинство людей склонны считать валидацию данных чрезвычайно утомительной
процесс, где один либо:Сравнивает данные, которые они хотят проверить, со всеми возможными
комбинация, о которой они могут думать. Пытается найти золотой Регулярный
Выражение, которое будет соответствовать каждой возможной комбинации.
Комбинация
из двух.
Есть очевидные проблемы с перечисленным выше:Это абсолютно отнимает много времени. Существует очень высокая вероятность ошибки.
К счастью, начиная с версии 5.2, PHP включил большой
функция с именем filter_var, которая снимает боль с данных
Проверка.
Шаблоны все еще необходимы или нет filter_var просто сделай все это.
Решение
Если под шаблонами вы подразумеваете регулярные выражения, то ответ на ваш вопрос да. Зачем? Встроенные фильтры не могут дезинфицировать или проверять ваши данные именно так, как вы хотите. Фильтры могут быть слишком широкими, или они могут слишком жестко соответствовать стандартам для ваших конкретных обстоятельств. Многие фильтры вообще не соответствуют стандартам.
Например, FILTER_SANITIZE_EMAIL а также FILTER_VALIDATE_EMAIL может разрешить использование странных адресов электронной почты, которые, хотя технически законно в смысле RFC, могут быть нежелательны в зависимости от ваших потребностей. Вы, как разработчик, создатель вашего приложения, должны решить, что вы действительно хотите принять за адрес электронной почты.
Создатели PHP-фильтра поняли, что один размер подходит всем — это непрактичное предложение. Следовательно, вы можете поставить свой собственный дезинфицирующий / проверочный фильтр с FILTER_CALLBACK и ваш собственный проверочный фильтр, использующий FILTER_VALIDATE_REGEXP, Мы вернулись на круги своя? Нам лучше?
Настоящий вопрос в том, готовы ли вы купить и принять «структура / методология фильтрации», установленная системой фильтров PHP. Я? Я использую их систему фильтров в качестве первого прохода, затем я использую свои собственные тщательно обработанные дезинфицирующие средства и средства проверки (да, я использую оба FILTER_CALLBACK а также FILTER_VALIDATE_REGEXP поверх универсальных дезинфицирующих средств / валидаторов). Это особенно актуально для меня при обработке HTML-форм, так как я больше не использую $ _POST и $ _GET. я использую filter_input_array() ,
Итак, мистер Смитый, не изобретайте велосипед, а думайте сами. Ключом к использованию системы фильтров PHP является создание системы, а для некоторых (таких как я) это означает обертывание функций фильтра в классе. Используя различные свойства класса, которые могут хранить предопределенные фильтры, можно представить систему, в которой различные методы, используя циклы, фильтруют все ваши данные, оставляя вас с окончательным выводом хорошего массива или плохого (с которым вы можете действовать, исходя из ваших конкретных обстоятельств). Но, как отмечает г-н Уолл из сообщества Perl, «есть несколько способов сделать это».
Другие решения
фильтры действительно очень полезны, и если вы можете избежать классического строкового подхода или регулярного выражения, не стесняйтесь использовать их.
К сожалению, предопределенный фильтр для каждого формата невозможен!
Вот почему есть два специальных фильтра: FILTER_VALIDATE_REGEXP а также FILTER_CALLBACK (этот последний на самом деле не является фильтром проверки, но ничто не запрещает функции обратного вызова возвращать логическое значение) построить все недостающие фильтры проверки. Но когда вам нужно использовать эти два специальных фильтра, ситуация на самом деле не отличается от той, что была до PHP 5.2.
На мой взгляд, главная цель filter_vars обеспечить максимально удобное, но особенно уникальный способ проверки и фильтрации задач. Я думаю, что аспект производительности совершенно вторичен.
об электронной почте и URL:
FILTER_VALIDATE_URL а также FILTER_VALIDATE_EMAIL невозможно проверить все возможные электронные письма или URL-адреса, но вы будете экспериментировать с той же проблемой (возможно, с другими ограничениями) с подходом регулярных выражений или другой самодельной проверкой строк.
Проверка URL и EMAIL страдает от одних и тех же заболеваний: существует несколько RFC (по разным причинам: обновление, интернационализация), которые описывают эти форматы, которые являются сложными, недостаточно известны и неравномерно распространяются и поддерживаются приложениями.
Точно так же сложно быстро создать код или шаблон для их проверки. Шаблоны, которые вы можете видеть для электронных писем или URL-адресов, в той или иной степени являются компромиссом между наиболее распространенными и наиболее экзотическими форматами.
Более того, нестабильность URL-адреса или электронной почты делает единственно надежным методом проверки достоверность подтверждения того, что он действительно существует. Таким образом, проверка формата является лишь шагом процесса проверки и должна быть релятивизирована.