Почему люди используют regexp для электронной почты и другие сложные проверки?

Существует ряд email regexp questions popping вверх, и я честно озадачен тем, почему люди используют эти безумно тупые сопоставляющие выражения, а не очень простой парсер, который разделяет электронную почту а затем проверяет их на допустимые символы, разрешенные для имени (нет дополнительной проверки, которая может быть сделана на этой части) и действительных символов для домена (и я полагаю, вы могли бы добавить проверку всех мировые TLD, а затем еще один уровень доменов второго уровня для стран с такими (например, com.uk)).

Реальная проблема заключается в том, что tlds и slds продолжают меняться (вопреки распространенному мнению), поэтому вам нужно постоянно обновлять regexp, если вы планируете выполнять все эти проверки высокого уровня, когда серверы корневых имен отправляют изменения.

Почему бы не иметь модуль, который просто проверяет домены, которые извлекаются из базы данных или плоского файла, и, возможно, проверяет DNS для соответствия записей?

Я серьезно здесь, почему все так любят изобретать идеальное регулярное выражение для этого? Это не похоже на подходящее решение проблемы...

Убедите меня, что это возможно не только в regexp (и удовлетворить всех), а в том, что это лучшее решение, чем пользовательский синтаксический анализатор/валидатор.

-Adam

Ответ 1

Они делают это, потому что они видят: "Я хочу проверить, соответствует ли этот текст спецификации", и сразу подумайте: "Я знаю, я буду использовать регулярное выражение!" без полного понимания сложности спецификации или ограничений регулярных выражений. Регулярные выражения - замечательный, мощный инструмент для обработки самых разных задач, связанных с текстовым сопоставлением, но они не идеальный инструмент для каждой такой задачи, и кажется, что многие люди, которые их используют, упускают из виду этот факт.

Ответ 2

Регулярные выражения, которые улавливают большую (но не все) общую ошибку, относительно просты в настройке и развертывании. Занимает больше времени, чтобы написать собственный парсер.

Ответ 3

Искушение использования RegExp, как только вы освоили основы, очень велико. На самом деле RegExp кажется настолько мощным, что люди, естественно, хотят начать использовать его повсюду. Я действительно подозреваю, что здесь много психологии, о чем свидетельствует Randall XKCD comic (и да, это полезно).

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

Ответ 4

Использование регулярных выражений для этого не является хорошей идеей, как было продемонстрировано подробно в этих других сообщениях.

Я полагаю, что люди продолжают это делать, потому что они не знают ничего лучше или не заботятся.

Будет ли парсер лучше? Может быть, может и нет.

Я утверждаю, что отправка электронной почты для проверки является наилучшим способом ее проверки. Если вы хотите проверить что-нибудь из JavaScript, проверьте, есть ли у него знак "@" и что-то до и после него. Если вы сделаете все более строгим, вы рискуете столкнуться с некоторым синтаксисом, о котором вы не знали, и ваш валидатор станет чрезмерно ограничительным.

Кроме того, будьте осторожны с этой схемой валидации TLD, вы можете обнаружить, что вы предполагаете слишком много о том, что разрешено в TLD.

Ответ 5

Люди делают это, потому что на большинстве языков проще писать regexp, чем писать и использовать парсер в вашем коде (или, по крайней мере, кажется).

Если вы решите отказаться от регулярных выражений, вам придется либо вручную писать парсеры, либо прибегать к внешним инструментам (например, yacc) для генерации lexer/parser. Это сложнее, чем однострочное регулярное выражение.

Нужно иметь библиотеку, которая упрощает запись парсеров непосредственно на языке X (где "X" - это C, С++, С#, Java), чтобы иметь возможность создавать настраиваемые парсеры с такой же легкостью, как и регулярные выражения,

Такие библиотеки возникли на функциональной земле (Haskell и ML), но в настоящее время существуют библиотеки комбинаторных комбинаторов для Java, С++, С#, Scala и других основных языков.

Ответ 6

Люди используют регулярные выражения для адресов электронной почты, HTML, XML и т.д., потому что:

Похоже, они должны работать, и они часто работают над очевидные случаи.
Они "знают" регулярные выражения. Когда все, что у вас есть, это молот ваши проблемы выглядят как гвозди.
Написание парсера сложнее (или кажется сложнее), чем писать регулярные выражение. В частности, писать парсер сложнее, чем писать регулярное выражение, которое обрабатывает очевидные случаи в # 1.
Они не понимают всю сложность задачи.
Они не понимают ограничений регулярных выражений.
Они начинаются с регулярного выражения, которое обрабатывает очевидные случаи, а затем пытается чтобы распространить его на другие. Они блокируются одним подходом.
Они не знают, что существует (возможно) библиотека, доступная для этого работа для них.

Ответ 7

а затем проверяет те, которые допустимые символы, разрешенные для имени (нет никакой дополнительной проверки, которая может быть сделано на этой части)

Это неверно. Например, "ben..doom @gmail.com" содержит только допустимые символы в разделе имен, но недействителен.

В языках, на которых нет библиотек для проверки подлинности электронной почты, я обычно использую regex becasue

Я знаю регулярное выражение и считаю его простым в использовании.
У меня много друзей, которые знакомы с регулярным выражением, и я могу сотрудничать с
Быстро для меня кодировать, а мне-время дороже процессорного времени для большинства приложений.
Для большинства адресов электронной почты он работает.

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

Ответ 8

Я не верю, что правильная проверка электронной почты может быть выполнена с помощью одного регулярного выражения (теперь есть проблема!). Одна из проблем заключается в том, что комментарии могут быть вложены в произвольную глубину как в локальной части, так и в домене.

Если вы хотите проверить адрес по RFC 5322 и 5321 (текущие стандарты), вам понадобится процедурная функция.

К счастью, это проблема с товаром. Каждый хочет получить тот же результат: соответствие RFC. Нет необходимости кому-либо писать этот код когда-либо снова, как только он будет разрешен функцией с открытым исходным кодом.

Ознакомьтесь с некоторыми из альтернатив здесь: http://www.dominicsayers.com/isemail/

Если вы знаете другую функцию, которую я могу добавить в голову, дайте мне знать.

Ответ 9

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

Ответ 10

Люди пишут регулярные выражения, потому что большинство таких разработчиков решают простую проблему в самом "крутом" en "эффективном" способе (что означает, что она должна быть как можно нечитабельной).

В Java есть библиотеки, проверяющие, соответствует ли String адрес электронной почты, если вы не знаете ничего о регулярных выражениях. Эти библиотеки должны быть доступны для других языков.

Как сказал в 1997 году Джейми Завински: "Некоторые люди, столкнувшись с проблемой, думают:" Я знаю, я буду использовать регулярные выражения ". Теперь у них две проблемы.

Ответ 11

По коэффициенту: набор людей, которые понимают, как писать регулярное выражение, намного больше, чем набор людей, которые понимают формальные ограничения на обычных языках. То же самое касается нерегулярных "регулярных выражений".

Ответ 12

Regexps гораздо быстрее используются, и они только подтверждают то, что указано в RFC. Напишите собственный парсер? Какие? Для использования регулярного выражения требуется 10 секунд.