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

Question

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

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

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

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

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

-Adam

Answer 1

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

1. Это выглядит как будто они должны работать, и они часто делают работают на очевидные случаи.
2. Они "знают" регулярные выражения. Когда все у вас есть молоток все ваши проблемы выглядят как гвозди.
3. Написание парсера сложнее (или кажется сложнее), чем написание обычного выражение. В частности, написание парсера сложнее, чем написание регулярное выражение, которое обрабатывает очевидные случаи в # 1.
4. Они не понимают всей сложности задачи.
5. Они не понимают ограничений регулярных выражений.
6. Они начинают с регулярного выражения, которое обрабатывает очевидные случаи, а затем пытаются расширить его, чтобы справиться с другими. Они заперты в одном подходе.
7. Они не знают, что есть (возможно) библиотека, доступная для работа для них.

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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