Используя регулярное выражение для проверки данных корректно или нет?
Я находил некоторые статьи и сообщение, которые предлагают не использовать регулярное выражение для проверки пользовательских данных. Я не уверен во всех вещах, но я обычно нахожу его в случае проверки адреса электронной почты.
Таким образом, я хочу быть ясным, хорошо ли использование регулярного выражения для проверки ввода данных пользователем или нет? если хорошо затем, что плохо с ним для проверки адреса электронной почты?
Править:
Так можем мы говорить, что для основной основной проверки типов данных мы можем использовать regex, и это хорошо, и для полной проверки мы должны объединить его с другим синтаксическим анализатором.
И для второй части для почтовой проверки в общем использовании мы можем использовать его, но согласно стандарту это не является соответствующим. Это?
Теперь беспорядок в выборе корректного один ответ
8 ответов
Это хорошо, потому что вы можете использовать регулярные выражения для простого выражения и тестирования сложных шаблонов.
Это плохо, потому что регулярные выражения могут быть сложными и многое можно сделать неправильно.
Править Ну ладно.Вот реальный совет: сначала убедитесь, что ожидаемые допустимые значения вообще могут быть выражены с помощью регулярного выражения. Это когда языком допустимых значений является обычный язык . В противном случае вы просто не сможете использовать регулярные выражения (или, по крайней мере, только регулярные выражения)!
Теперь, когда мы знаем, что можно проверить с помощью регулярных выражений, мы должны обсудить, что можно проверить с помощью регулярных выражений. Если мы возьмем в качестве примера адрес электронной почты (как и многие другие), мы должны знать, как может выглядеть действительный адрес электронной почты (см. RFC 5322):
addr-spec = local-part "@" домен локальная часть = точка-атом / строка в кавычках / obs-local-part домен = точка-атом / домен-литерал / obs-домен domain-literal = [CFWS] "[" * ([FWS] dtext) [FWS] "]" [CFWS] dtext =% d33-90 /; Версия для печати US-ASCII % d94-126 /; символы не включая obs-dtext; "[", "]", или "\"
Здесь мы видим, что локальная часть может состоять из строки в кавычках , которая может содержать любой печатаемый символ US-ASCII (за исключением \ и "", но включая @ ). Таким образом, недостаточно проверить, содержит ли адрес электронной почты только один @ , если мы хотим разрешить адреса в соответствии с RFC 5322.
С другой стороны, если мы хотим разрешить любой действительный электронный адрес -mail адрес в соответствии с RFC 5322, мы также разрешили бы адреса, которые, вероятно, не существуют или просто бессмысленны в большинстве случаев (например, "" @ localhost ).
Регулярные выражения могут быть плохими по трем причинам:
- Они могут стать очень сложными и, в конечном счете, не поддерживаемыми. Очень легко допустить ошибки.
- Есть определенные типы текста, которые вообще не могут быть разобраны с помощью регулярных выражений (например, HTML). В принципе, все, что содержит вложенные шаблоны, не может быть разобрано с помощью регулярных выражений. Например, вы не сможете разобрать язык программирования с помощью regex.
- В зависимости от того, с каким текстом вы работаете, может быть проще и понятнее, если вы просто напишете свой собственный код для его разбора.
Но если ни то, ни другое не является проблемой для того, с чем вы работаете, то нет ничего плохого в использовании регулярных выражений. Я бы сказал, что проверка адресов электронной почты - это хорошее применение regex.
Регулярные выражения - это такой же инструмент, как и любой другой, хотя и очень мощный.
Они настолько мощны, что люди, использующие их, часто страдают от проблемы, заключающейся в том, что все выглядит как гвоздь (когда у вас есть молоток). Это приводит к их использованию в ситуациях, когда другой метод будет более подробным, но более эффективным и более удобным в обслуживании.
В конкретном случае адресов электронной почты основная проблема заключается в том, что существует очень большое количество регулярных выражений, которые утверждают, что проверяют синтаксис адреса электронной почты, но загружены проблемами, вызывающими ложноотрицательные результаты.
Основные проблемы с ними включают:
- Запрещение плюсов в первой половине адреса (несмотря на то, что они относительно распространены)
- Ограничение TLD тремя символами (это блокирует TLD .museum)
- Ограничение TLD двумя символами кода страны TLD или списком конкретных TLD (таким образом, вынуждая его обновлять каждый раз, когда появляется новый TLD - угадайте, что никогда не произойдет?)
Адреса электронной почты настолько сложны, что регулярное выражение не должно я действительно пытаюсь сделать что-то большее, тогда:
- Что-то, что не включает
@ - An
@ - Что-то, что не включает
@ - A
. - Что-то, что не включает
@
Кажется, ваш вопрос состоит из двух частей: (1) используется регулярный выражения для проверки данных плохо, и (2) использует ли их для проверки адресов электронной почты плохо?
Re (1), это действительно зависит от ситуации. Во многих ситуациях регулярного выражения будет более чем достаточно для проверки пользовательского ввода; например, проверка того, что имя пользователя состоит только из буквенно-цифровых символов. Там, где набор регулярных выражений, вероятно, будет неадекватным, - это когда входные данные могут быть переданы чему-то вроде запроса к базе данных или инструкции eval (). В этих случаях могут быть языковые конструкции, такие как рекурсия, которые не могут быть обработаны с помощью регулярных выражений, и, в более общем плане, вам понадобится что-то, что хорошо знает целевой язык, для выполнения проверки (и очистки).
В большинстве случаев вы захотите избежать ввода, чтобы это была безобидная строка на целевом языке.
Если вы проверяете правильность кода, вам понадобится для этого полноценный синтаксический анализатор. Парсер может использовать регулярные выражения, но обычно парсеры используют другие вещи для выполнения тяжелой работы.
Для адресов электронной почты хорошо использовать регулярные выражения. Это будет работать в большинстве случаев.
В целом: вы должны проверять с помощью регулярных выражений все, что может быть выражено как регулярный язык
Если шаблон данных, которые вы проверяете, можно полностью и правильно выразить с помощью регулярных выражений, вы можете безопасно использовать их, не беспокоясь. Однако не все текстовые шаблоны можно выразить с помощью регулярных выражений (например, контекстно-свободных грамматик). В таких случаях вам может потребоваться написать синтаксический анализатор или собственный метод для проверки данных.
Беспокойство, вероятно, связано с тем, что часто используемые регулярные выражения не охватывают все возможные (допустимые) входные данные и / или ограничивают пользователю многое из того, что он может ввести.
Я не вижу другого способа проверить, соответствует ли ввод пользователя определенной схеме (я имею в виду, что регулярные выражения нужны именно для этого), поэтому они необходимы (imo) для проверки ввода пользователем. Но вам определенно нужно потратить некоторое время на разработку выражения, чтобы убедиться, что оно действительно работает, даже в крайних случаях.
Возьмите номера кредитных карт. Вы должны подумать о том, как пользователь может их ввести:
1234-5678
// or
1234 5678
// or
1234 - 5678
И теперь у вас есть две возможности:
- Вы ограничиваете ввод первым случаем, что приведет к более легкому выражению, но ограничит (и, возможно, раздражает) пользователя большинство.
- Вы создаете выражение, которое принимает любую из этих возможностей, что делает выражение более сложным (следовательно, его труднее поддерживать), но более удобным для использования.
Это компромисс.
Регексы неплохо подходят для проверки большинства данных, если это регулярный язык.
Но, как уже отмечалось, иногда их бывает трудно поддерживать, и программисты вносят ошибки.
Самый простой способ смягчить ситуацию - это тесты/TDD. Эти тесты должны вызывать метод, который использует регулярное выражение для проверки адресов электронной почты (в настоящее время я использую этот regex /^[A-Z0-9._%+-]+@(?:[A-Z0-9-]+\.)+[A-Z]{2,4}$/i, который работает достаточно хорошо. Таким образом, когда вы получаете ложноположительный или ложноотрицательный результат, вы можете добавить еще один тест для этого случая, скорректировать ваше регулярное выражение и убедиться, что вы не нарушили какое-то другое условие.
Если TDD кажется слишком сложным, то такой инструмент, как Expresso, позволяет сохранять регулярные выражения с тестовыми данными, что может помочь в отслеживании значений, которые должны пройти/не пройти, а также помочь в создании и понимании вашего регулярного выражения.
ПРЕДУПРЕЖДЕНИЕ:
Будьте осторожны при построении регулярных выражений. Существует вероятность появления уязвимостей ReDos
См: http://msdn.microsoft.com/en-us/magazine/ff646973.aspx
Короче говоря, плохо построенный regex, при правильном вводе, может занять часы на выполнение, эффективно убивая производительность вашего сервера.