Разница в проверке электронной почты регулярных выражений между плагином jQuery и org.springmodules.validation

Question

Привет! У меня есть приложение Spring и форма для проверки на задней и передней части. В конце я использую проверку на основе аннотаций для поля EMAIL с помощью org.springmodules.validation. Пока все хорошо.

На внешнем интерфейсе я решил использовать плагин jQuery Form Validation и обнаружил, что передняя и задняя проверки не синхронизированы друг с другом.

Например: a@b.c с проверкой JQuery, но не с Spring. Я посмотрел на обоих re-gex'ов и посмотрел мне в глаза.

Будет ли кто-нибудь достаточно любезен, чтобы прокомментировать компромиссы, преимущества / недостатки использования любого из них?

Вот они:

Плагин проверки jQuery регулярное выражение: (первоисточник здесь)

^(([A-Za-z0-9]+_+)|([A-Za-z0-9]+\-+)|([A-Za-z0-9]+\.+)|([A-Za-z0-9]+\++))*[A-Za-z0-9]+@((\w+\-+)|(\w+\.))*\w{1,63}\.[a-zA-Z]{2,6}$

org.springmodules.validation регулярное выражение:

^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$

Заранее большое спасибо!

Answer 1

Не говоря уже о том, что китайские / арабские доменные имена должны быть разрешены в ближайшем будущем . Каждый должен изменить используемое регулярное выражение электронной почты, потому что эти символы наверняка не будут охвачены ни [a-z]/i, ни \w. Все они потерпят неудачу.

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

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

^([^.@]+)(\.[^.@]+)*@([^.@]+\.)+([^.@]+)$

Все просто. С какой стати вы заботитесь о символах, используемых в имени и домене? Ответственность за ввод действительного адреса электронной почты лежит на клиенте, а не на сервере.

Answer 2

Есть миллион возможных решений, но мне нравится:

^[^<>\s\@]+(\@[^<>\s\@]+(\.[^<>\s\@]+)+)$

По сути, вот что он делает:

1. Соответствует всем символам, кроме левого и правого шевронов, пробелов и @
2. Соответствует символу @
3. Повтор # 1
4. Совпадение с точкой (.)
5. Повтор # 1

Это означает, что разрешено использование иностранных символов, когда имена доменов на китайском / арабском должны быть разрешены, как упоминалось в BalusC. Но он поймает грубые ошибки, такие как отсутствующий символ @, точка для имени домена, пробел и т. Д. Кроме того, в Javascript он будет вести себя так же, как и в любом другом языке регулярных выражений на основе Perl. знать о. Так что это хороший кандидат для проверки как на стороне клиента, так и на стороне сервера.

Я создал тестовые примеры для этого здесь:

http://regexhero.net/tester/?id=4a1f18cf-3dc0-4157-ab74-489a69e184ee

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

Так что лично меня больше всего беспокоит ловушка наиболее распространенных ошибок при разрешении ВСЕХ потенциально действительных адресов электронной почты. Если кто-то может найти действительный адрес электронной почты, который не будет соответствовать этому регулярному выражению , , я хотел бы знать об этом. До тех пор, это то, что я собираюсь использовать. ;)

Answer 3

Сопоставление писем с помощью регулярных выражений является сложной задачей. И регулярное выражение проверки JQuery - путь (!) К простому. Это так просто, что даже для многих электронных адресов, которые действительно действительны, произойдет сбой. Еще раз случай «Эй, есть только ASCII, поскольку действительные персонажи просто забывают об остальном мире»

например. действительный адрес электронной почты с немецким символом умлаут

föobar@example.com

Мой совет - просто проверить электронную почту с помощью Spring-Backend и пропустить этот шаг на стороне клиента. После этого вам все равно нужно отправить тестовое электронное письмо, чтобы проверить, действительно ли оно действительно, активно, ...

Answer 4

Еще одно регулярное выражение:

/^[a-z0-9\._-]+@[a-z0-9\._-]+\.(xn--)?[a-z0-9]{2,}$/i

Он поддерживает IDN (интернационализированные доменные имена), если он записан в ASCII (например, xn--lvaro-wqa.es ). В противном случае вам потребуется реализовать кодировку Punycode.

Мне это нравится, потому что это очень просто. Он ищет только очевидные опечатки. Как уже упоминалось, это лучший подход. Чем сложнее становится ваше выражение, тем больше действительных писем вы будете отклонять. Реальная проверка электронной почты может быть выполнена только при фактическом отправке сообщения электронной почты.

Answer 5

Почему бы не воспользоваться уже реализованным решением: http://commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/EmailValidator.html