Какое простейшее регулярное выражение позволяет проверять электронные письма, чтобы они не принимали их вслепую? [закрыто]


80

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

Я пришлю подтверждение, чтобы провести проверку рукопожатия .

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

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

Какое регулярное выражение я могу использовать для этого?


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

Если вы выполняете проверку регулярного выражения, зачем ограничивать выражение чем-то простым? Давайте воспользуемся чем-нибудь хорошим, это не повлияет на ваш код и даст лучшие результаты.
twk

Где в вашем приложении будет эта проверка? По почте? Что вы делаете для очистки ввода?
Braiam

^ (? i) [A-Z0-9 + _.-] + @ (?:. *). (?:. *) $, ^ означает начало, $ означает конец, (? i) совпадение без учета регистра. перед @ разрешать только буквенно-цифровые символы, '+', '_', '-'. этот,?: без формирования подгрупп частичного матча, только 1 полный матч
P Satish Patro

Ответы:


99
^\S+@\S+$

3
Это будет соответствовать недопустимым адресам. Подойдет любое регулярное выражение, но это будет соответствовать распространенным ошибкам написания, таким как test @ stackoverflow..com (обратите внимание на двойные точки). Приведите лучший пример.
Михай Лимбэцан,

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

2
+1. В любом случае это субъективный вопрос, и это просто.
Джейсон Коэн,

2
Да, если вы не хотите использовать полное проверяющее регулярное выражение, это хорошее простое приближение
rampion

8
+1 Пытаться «подтвердить» адрес электронной почты полностью с помощью регулярного выражения - глупая затея. Это помогает отловить простейшие неверные типы; остальное можно найти, попробовав отправить по почте. Вышеупомянутое также позволяет использовать домены Unicode (-> Punycode), где большинство «умных» регулярных выражений не работают.
bob с

239

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

Вот несколько простых регулярных выражений для базовой проверки:

Содержит символ @:

@

Содержит @ и точку где-то после него:

@.*?\.

Имеет хотя бы один символ перед @, до точки и после нее:

.+@.+\..+

Имеет только один @, по крайней мере, один символ перед @, до точки и после нее:

^[^@]+@[^@]+\.[^@]+$

Пользователь AmoebaMan17 предлагает эту модификацию для устранения пробелов:

^[^@\s]+@[^@\s]+\.[^@\s]+$

И для принятия только одного периода:

^[^@\s]+@[^@\s\.]+\.[^@\.\s]+$

7
ЕСЛИ вы посмотрите на то, что происходит с RFC 6531, и если вы внимательно посмотрите на RFC 3696, вы, вероятно, придете к выводу, что единственный способ проверить электронное письмо - это отправить электронное письмо с подтверждением. Я думаю, что реальное внимание при использовании регулярных выражений в адресах электронной почты должно быть направлено на то, чтобы помочь пользователю предотвратить опечатки, и именно здесь в игру вступают простые регулярные выражения, подобные этому.
Боб Баркер

Отлично, @ AmoebaMan17. RegEx может проверить формат адреса электронной почты, но не может проверить содержимое адреса электронной почты. Тем не менее, ваш формат полностью проверяет. Отправка электронного письма - единственный способ проверить содержимое.
Craig

не будет работать test@test.com?
Abdul Hameed

1
Чтобы строка не оканчивалась точкой, я сделал следующее изменение: ^ [^ @ \ s] + @ [^ @ \ s] + \. [^ @ \. \ S] + $
fyrite

1
Да, не используйте последнюю. Он не соответствует многим допустимым вариантам. me@provider.co.uk, например.
s.meijer

7

^ [a-zA-Z0-9 _. + -] + @ [a-zA-Z0-9 -] +. [a-zA-Z0-9 -.] + $

  • Только 1 @
  • Несколько доменов и поддоменов

3

Я думаю, что эта небольшая настройка выражения AmoebaMan17 должна остановить адрес от начала / окончания точки, а также остановить несколько точек рядом друг с другом. Попытка не усложнять снова, устраняя при этом общую проблему.

(?!.*\.\.)(^[^\.][^@\s]+@[^@\s]+\.[^@\s\.]+$)

Кажется, он работает (но я не RegEx-pert). Устраняет мою проблему с пользователями, копирующими и вставляющими адреса электронной почты с конца предложений, заканчивающихся точкой.

то есть: Вот мой новый адрес электронной почты tabby@coolforcats.com.


Это не работает для одного персонажа до @
Andy Hoyle

<script> alert ('hello') </script> @ hello.com действителен в соответствии с этим регулярным выражением. Не кажется нормальным.
dudedev

1

Сделайте ваш выбор.

Вот тот, который соответствует RFC 2822, раздел 3.4.1 ...

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

На всякий случай, если вам интересно. :)


7
Просто примечание для тех, кто сейчас это видит: это не соответствует RFC 2822.
porges

11
И это тоже не просто :)
Дэн Дипло

2
Он также заблокирует множество действительных адресов электронной почты. Особенно с использованием международных символов / языков.
Боб Баркер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.