filter_var против preg_match

Утро все

Я конвертирую сайт, над которым я работаю, чтобы быть совместимым с последней версией PHP, поэтому я просматриваю и заменяю все экземпляры ereg на их неоцениваемый эквивалент. Однако мне рассказали о удобной встроенной функции с PHP, называемой filter_var.

Каков мой вопрос, есть ли смысл идти с filter_var над preg_match? Как и в случае повышения производительности или каких-либо других преимуществ для выбора одного над другим, и если да, то каковы они?

filter_var – Фильтрует переменную с заданным фильтром
preg_match – выполнить регулярное выражение

Я думаю, использование может использовать filter_var для фильтрации переменных, но в качестве замены для preg_match. Я не думаю, что это хорошая идея для обновления с ereg, поскольку filter_var не использует регулярное выражение, и вам придется переписать много функциональности / логики, чтобы сделать это.

Прежде всего, страница PHP Manual по фильтрации: https://php.net/manual/en/book.filter.php

Во-вторых , контекст является ключевым. Вообще говоря, функции фильтра предназначены для использования внешнего входа (скаляры или массивы) или внутреннего входа . Внешний вход поступает из источников, таких как HTTP-запрос / механизм PHP, или представление формы.

Функции фильтра с префиксом filter_input позволяют полностью обходить суперглобальные блоки $ _SERVER, $ _COOKIE, $ _POST и $ _GET. Хотя вы обычно указываете «где» вы хотите, данные, функции фильтра явно не используют $ _POST, $ _GET, $ _COOKIE и $ _SERVER. Изменения, внесенные в элементы переменной / массива , не будут отображаться в $ _GET, $ _POST или $ _SERVER, поэтому использование фильтра таким образом является сдвигом парадигмы и может существенно изменить поток вашего приложения. Другими словами, вы должны сами отслеживать внешний вход. Я делаю это для первоначальной дезинфекции (снятия, замены, изменения и т. Д.) Внешнего входа. Я больше не использую $ _POST, $ _GET или $ _SERVER. Хотя, я все еще использую $ _FILES.

Функции с префиксом filter_var предназначены для фильтрации любого общего массива, который уже существует в вашей программе. Я использую это после использования filter_input . В обоих случаях есть много фильтров, но ваш вопрос касается производительности .

Если вы решили использовать фильтр FILTER_VALIDATE_REGEXP с любой из фильтрующих функций, я не могу представить, что этот косвенный подход более эффективен, чем непосредственно с помощью preg_match() . Что касается других фильтров, если они просто «n» количество методов / функций, удаленных из вызова регулярного выражения, я также не вижу улучшения в эффективности .

Я вижу, что функции фильтра – это что-то, что было разработано, чтобы улучшить согласованность для фильтрации задач, которые происходят во многих приложениях. Вероятно, они не предназначены для повышения эффективности , но они определенно предназначены для того, чтобы быть более доступными, чем регулярные выражения (хотя я очень хорош с регулярными выражениями). Я предпочитаю иметь непосредственное знание о том, что происходит, но некоторые люди не заботятся об этом или не хотят. Однако функции фильтра открывают дверь для фильтрации строк тем, кто не понимает регулярные выражения и другие основные процессы безопасности веб-приложений.

Конечно, можно жить без использования фильтрующих функций.

Более того, я использую функции фильтра вместе со своими собственными дезинфицирующими и валидаторными классами. Итак, я не прошу PHP думать обо мне, я просто использую его, чтобы увеличить то, что я уже знаю, как это сделать (на случай, если их функции получат что-то, что я пропустил). Оборона в глубину.

В общем, лучше всего использовать preg_match() , если вы не намерены изменять поток ( filter_input функции) ввода в ваше приложение. Даже тогда повышения производительности не будет, но вы можете обойти $ _SERVER, $ _POST и $ _GET. Кроме того, вы можете использовать более простые, структурированные, последовательные, фильтрующие функции с возможностью использования функции обратного вызова ( FILTER_CALLBACK ) для вызова пользовательских, внутри дома, методов / функций (что также и я). Кроме того, вы все равно можете использовать свои собственные регулярные выражения с функциями фильтра, используя фильтр FILTER_VALIDATE_REGEXP , но опять же, я не вижу оснований полагать, что производительность вашего приложения будет улучшаться, если вы это сделаете. Ремонтопригодность? Может быть. Это зависит от человека, написавшего код.

Переключение на использование filter_var() было бы отличной идеей. Вы не сможете использовать существующие регулярные выражения, однако вы сможете полностью их устранить. Часто регулярное выражение, которое мы используем в наших приложениях, просто используется для простой проверки и фильтрации, что и есть функция filter_var() .

Например, в вашем коде у вас может быть:

 if (eregi('\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[AZ]{2,4}\b', $_POST['email'])) { echo "valid"; } 

Это может быть заменено более красивой версией (не полагаясь на пользовательские регулярные выражения):

 if (filter_var($_POST['email'], FILTER_VALIDATE_EMAIL)) { echo "valid"; } 

Функция filter_var() также имеет возможность деактивировать символы, которые не нужны конкретным данным, которые вы изучаете, и возвращать очищенную строку (вместо логического):

 $clean = filter_var($_POST['email'], FILTER_SANITIZE_EMAIL); 

Этот вид использования с filter_var() заменит ereg_replace() типа ereg_replace() .

Однако для простейшего обновления вы можете просто «префикс» семейства функций ereg * () с «p», что делает их совместимыми с PCRE (и, следовательно, больше не устаревает в PHP 5.3+).