Какие символы допускаются в адресе электронной почты?

Question

Какие символы допускаются в адресе электронной почты?

Я не спрашиваю о полной проверке электронной почты.

Я просто хочу знать, какие символы разрешены в user-name и server части адреса электронной почты. Это может быть упрощено, возможно, адреса электронной почты могут принимать другие формы, но мне все равно. Я спрашиваю только об этой простой форме: user-name@server (например wild.wezyr@best-server-ever.com) и разрешенные символы в обеих частях.

478

email email-address email-validation forms

автор: kevinarpe

18 ответов

автор: Anton Gogolev · Accepted Answer · 2017-05-23 12:26:32

посмотреть RFC 5322: формат интернет-сообщений и, в меньшей степени, RFC 5321: простой протокол передачи почты.

RFC 822 также охватывает адреса электронной почты, но имеет дело в основном с его структурой:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

и, как обычно, Википедия имеет приличный статья об адресах электронной почты:

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

прописные и строчные латинские буквы A to Z и a to z;

цифры 0 to 9;

специальные символы !#$%&'*+-/=?^_`{|}~;

точка ., при условии, что он не является первым или последним символом, если он не указан, а также при условии, что он не появляется последовательно, если он не указан (например,John..Doe@example.com не допускается "John..Doe"@example.com разрешена);

пространство и "(),:;<>@[\] символы разрешены с ограничения (они разрешены только внутри строки с кавычками, как описано в абзаце ниже, и кроме того, обратной косой черте или двойной кавычке должна предшествовать обратная косая черта);

комментарии разрешены с круглыми скобками на любом конце локальной части; например john.smith(comment)@example.com и (comment)john.smith@example.com оба эквивалентно john.smith@example.com.

в дополнение к символам ASCII,в 2012 году вы можете использовать international символы выше U+007F, закодированных как UTF-8.

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

на domain это следующим образом:

интернет-стандарты (запрос комментариев) для протоколов предписывают, что метки имени хоста компонента могут содержать только буквы ASCII a через z (без учета регистра), цифры 0 через 9, и дефис (-). Исходная спецификация имен хостов в RFC 952, предписано, что метки не могут начинаться с цифры или дефиса и не должны заканчиваться дефисом. Однако последующая спецификация (RFC 1123) разрешенные метки имен хостов начинаются с цифр. Допускаются никакие другие символы, знаки препинания или пробелы.

автор: Mason · Accepted Answer · 2016-06-10 15:22:25

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

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

суть в том, что теперь вы можете использовать такие адреса, как mason@日本.com и wildwezyr@fahrvergnügen.net - ... Нет, это еще не совместимо со всем, что там (как многие сетовали выше, даже простые qmail-style +ident-адреса часто ошибочно отклоняются). Но есть RFC, есть спецификация, теперь она поддерживается IETF и ICANN, и-что более важно-есть большое и растущее число реализации, поддерживающие это улучшение, которые в настоящее время находятся в эксплуатации.

Я сам мало знал об этом развитии, пока не вернулся в Японию и не начал видеть адреса электронной почты, такие как hei@やる.ca и Amazon URLs, как это:

http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e?ie=UTF8&node=3210981

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

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

после этого вы можете следовать (большинству) советов выше.

автор: kenorb · Accepted Answer · 2018-05-23 11:47:05

формате e-mail адрес: local-part@domain-part (макс. 64@255 символов, не более 256 в общей сложности).

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

в общем, локальная часть может иметь следующие символы ASCII:

строчные буквы латинского алфавита: abcdefghijklmnopqrstuvwxyz,
заглавные латинские буквы:ABCDEFGHIJKLMNOPQRSTUVWXYZ,
цифр: 0123456789,
специальные символы: !#$%&'*+-/=?^_`{|}~,
точка: . (не первый или последний символ или повторяется, если не указано),
пробел пунктуации, такие как:"(),:;<>@[\] (С некоторыми ограничениями),
комментарии: () (разрешено в скобках, например,(comment)john.smith@example.com).

домен входит:

строчные буквы латинского алфавита: abcdefghijklmnopqrstuvwxyz,
заглавные латинские буквы: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
цифры: 0123456789,
дефис: - (не первый и не последний символ),
может содержать IP-адрес в квадратные скобки: jsmith@[192.168.2.1] или jsmith@[IPv6:2001:db8::1].

эти адреса электронной почты действительны:

prettyandsimple@example.com
very.common@example.com
disposable.style.email.with+symbol@example.com
other.email-with-dash@example.com
x@example.com (одну букву местные часть)
"much.more unusual"@example.com
"very.unusual.@.unusual.com"@example.com
"very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
example-indeed@strange-example.com
admin@mailserver1 (локальное доменное имя без домена верхнего уровня)
#!$%&'*+-/=?^_`{}|~@example.org
"()<>[]:,;@\"!#$%&'-/=?^_`{}| ~.a"@example.org
" "@example.org (пробел между кавычками)
example@localhost (отправлено из localhost)
example@s.solutions (см. список интернет верхнего уровня Домены)
user@com
user@localserver
user@[IPv6:2001:db8::1]

и эти примеры некорректны:

Abc.example.com (не @ символ)
A@b@c@example.com (одна @ допускается за пределами кавычек)
a"b(c)d,e:f;gi[j\k]l@example.com (ни один из специальных символов в этой локальной части не допускается вне кавычек)
just"not"right@example.com (строки с кавычками должны быть разделены точкой или единственный элемент, составляющий локальную часть)
this is"not\allowed@example.com (пробелы, кавычки и обратные косые черты могут существовать только в кавычках и перед обратной косой чертой)
this\ still\"not\allowed@example.com (даже если экранировано (предшествует обратной косой чертой), пробелы, кавычки и обратные косые черты должны по-прежнему содержаться кавычками)
john..doe@example.com (две точки перед @); (С оговоркой: Gmail позволяет это через)
john.doe@example..com (две точки после @)
a действительно адрес с ведущим пробелом
действительный адрес с конечным пробелом

источник: адрес электронной почты в Википедии

регулярное выражение RFC2822 Perl для проверки электронной почты:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\".\[\] 0-1]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\".\[\] 
0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|
\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"
(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\
".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[
\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\".\[\] 0-
1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([
^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\"
.\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\
]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\
[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\
r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 
0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]
|\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\".\[\] 
00-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?
:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".
\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]
]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\
".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\
]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\
".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".
\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

полное регулярное выражение для адресов RFC2822 было всего лишь 3.7 k.

Читайте также: парсер адресов электронной почты RFC 822 в PHP.

официальное определения адресов электронной почты находятся в:

RFC 5322 (разделы 3.2.3 и 3.4.1, устаревшие RFC 2822), RFC 5321, RFC 3696,
RFC 6531 (разрешенные символы).

по теме:

истинная сила регулярных выражений

автор: Mike Weller · Accepted Answer · 2017-08-23 11:36:39

Википедия имеет хорошую статью об этом и официальная спецификация здесь. Из Wikipdia:

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

заглавные и строчные английские буквы (a-z, A-Z)

цифры от 0 до 9

символы ! # $ % & ' * + - / = ? ^ _ ' { / } ~

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

кроме того, строки с кавычками (т. е. "John Doe" @example.com) разрешены, таким образом, разрешены символы, которые в противном случае были бы запрещены, однако они не появляются в обычной практике. RFC 5321 также предупреждает, что"хост, который ожидает получать почту, должен избегать определения почтовых ящиков, где локальная часть требует (или использует) форму с кавычками".

автор: ThinkingStiff · Accepted Answer · 2012-07-27 17:34:53

название:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

сервер:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

автор: Vladimir · Accepted Answer · 2010-01-12 14:20:10

вы можете начать с статья в Википедии:

заглавные и строчные английские буквы (a-z, A-Z)
цифры от 0 до 9
символы ! # $ % & ' * + - / = ? ^ _ ' { / } ~
символ . (точка, точка, точка) при условии, что это не первый или последний символ, а также при условии, что он не появляется два или более раз подряд.

автор: Angel Koh · Accepted Answer · 2014-03-21 12:01:40

Google делает интересную вещь со своими gmail.com адреса. gmail.com адреса разрешают только буквы (a-z), цифры и точки(которые игнорируются).

например, pikachu@gmail.com это то же самое, что pi.kachu@gmail.com, и оба адреса электронной почты будут отправлены в один и тот же почтовый ящик. PIKACHU@gmail.com также доставляется в тот же почтовый ящик.

поэтому, чтобы ответить на вопрос, иногда это зависит от исполнителя от того, сколько стандартов RFC они хотят следовать. Гугла gmail.com стиль адреса совместим со стандартами. Они делают это таким образом, чтобы избежать путаницы, когда разные люди будут принимать аналогичные адреса электронной почты, например

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

ссылка Википедии является хорошей ссылкой на то, что адреса электронной почты обычно позволяют. http://en.wikipedia.org/wiki/Email_address

автор: Richard Maxwell · Accepted Answer · 2013-06-11 19:28:39

проверьте наличие @ and . а затем отправьте им электронное письмо для проверки.

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

автор: Michael JAMES · Accepted Answer · 2012-03-01 01:50:28

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

для хорошего руководства по адресам, которые вы создаете; см.: http://www.remote.org/jochen/mail/info/chars.html

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

автор: Luke Madhanga · Accepted Answer · 2016-08-06 09:46:01

хорошее чтение на вопрос.

выдержка:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

автор: Mac · Accepted Answer · 2018-01-29 16:50:46

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

IETF RFC 3696 авторитет по этому вопросу, и следует обращаться в раздел 3. Ограничения на адреса электронной почты на странице 5:

современные адреса электронной почты состоят из "локальной части" отделился от "доменная часть" (полностью квалифицированная доменное имя) по знаку at ("@"). Синтаксис доменной части соответствует синтаксису предыдущей части раздел. Проблемы, выявленные в этом разделе относительно фильтрации и списки имен применяются к доменным именам, используемым в контексте электронной почты как что ж. Доменное имя также может быть заменено IP-адресом в квадратные скобки, но эта форма сильно не рекомендуется, за исключением тестирование и устранение неполадок.

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

точное правило заключается в том, что любой символ ASCII, включая элемент управления символы, могут отображаться в кавычках или в строке с кавычками. Когда цитирование необходимо, символ обратной косой черты используется для выражения следующих характер. Например
  Abc\@def@example.com
является действительным адресом электронной почты. Также могут появляться пробелы, как в
  Fred\ Bloggs@example.com
символ обратной косой черты также может использоваться для цитирования себя, например,
  Joe.\Blow@example.com
в дополнение к цитированию с использованием символа обратной косой черты, обычный символы двойной кавычки могут использоваться для окружения строк. Например
  "Abc@def"@example.com

  "Fred Bloggs"@example.com
являются альтернативными формами первых двух примеров выше. Эти процитировал формы редко рекомендуются, и являются необычными на практике, но, как рассмотренные выше, должны поддерживаться приложениями, которые обрабатываются адрес электронной почты. В частности, цитируемые формы часто появляются в контекст адресов, связанных с переходами из других систем и контексты; эти переходные требования все еще возникают и, поскольку система, принимающая предоставленный пользователем адрес электронной почты, не может "знать", связан ли этот адрес с устаревшей системой, адрес формы должны быть приняты и переданы в среду электронной почты.

без кавычек, local-parts может состоять из любой комбинации
алфавитные символы, цифры или любой из специальных символов
  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~
точка (".") может также появиться, но не может использоваться для начала или конца локальная часть, а также не может появляться два или более последовательных периода. Указано иначе, любой графический (печатный) символ ASCII, кроме знак at ( " @ " ), обратная косая черта, двойной кавычка, запятая, или квадратные скобки может появиться без цитирования. Если какой-либо из этого списка исключен символы должны появиться, они должны быть процитированы. Такие формы, как
  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com
действительны и видны довольно регулярно, но любой из символов перечисленные выше разрешены.

как и другие, я отправляю регулярное выражение, которое работает как для PHP, так и для JavaScript для проверки адресов электронной почты:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

автор: Yash Patel · Accepted Answer · 2017-06-05 23:14:36

как можно найти в это ссылка на Википедию

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

прописные и строчные латинские буквы A до Z и a to z;

цифры 0 до 9;

специальные символы !#$%&'*+-/=?^_`{|}~;

точка ., при условии что это не первый или последний символ, если он не указан, а также при условии, что он не появляется последовательно, если он не указан (например,John..Doe@example.com не допускается "John..Doe"@example.com разрешена);

космос и "(),:;<>@[\] символы разрешены с ограничениями (они разрешены только внутри строки с кавычками, как описано в абзаце ниже, и, кроме того, обратной косой чертой или двойной кавычкой должна предшествовать обратная косая черта);

комментарии разрешено с круглыми скобками на любом конце локальной части; например john.smith(comment)@example.com и (comment)john.smith@example.com оба эквивалентно john.smith@example.com.

в дополнение к вышеуказанным символам ASCII, международные символы выше U + 007F, закодированные как UTF-8, разрешены RFC 6531, хотя почтовые системы могут ограничить, какие символы использовать при назначении локальной части.

строка с кавычками может существовать как объект, разделенный точкой в локальной части, или может существуют, когда самые внешние кавычки являются самыми внешними символами локальной части (например,abc."defghi".xyz@example.com или "abcdefghixyz"@example.com разрешено. И наоборот, abc"defghi"xyz@example.com нет, ни abc\"def\"ghi@example.com). Однако кавычки и символы обычно не используются. RFC 5321 также предупреждает ,что"хост, который ожидает получать почту, должен избегать определения почтовых ящиков, где локальная часть требует (или использует) форму с кавычками".

местная часть postmaster обработано специально-оно регистр не учитывается и должен быть перенаправлен администратору электронной почты домена. Технически все остальные локальные части чувствительны к регистру, поэтому jsmith@example.com и JSmith@example.com укажите разные почтовые ящики; однако многие организации рассматривают заглавные и строчные буквы как эквивалентные.

несмотря на широкий спектр специальных символов, которые технически действительны; организации, почтовые службы, почтовые серверы и почтовые клиенты на практике часто не принимают их все. Например, Windows Live Hotmail позволяет создавать адреса электронной почты только с помощью буквенно-цифровых символов, dot (.), подчеркивание (_) и дефис (-). Общие рекомендации избегать использования некоторых специальных символов, чтобы избежать риска отклоненных писем.

автор: · Accepted Answer · 2015-06-21 04:56:14

ответ (почти) ALL (7-битный ASCII).
Если правила включения"...допускается при некоторых/любых/никаких условиях..."

просто взглянув на одно из нескольких возможных правил включения для разрешенного текста в части "текст домена" в RFC 5322 в верхней части страницы 17 мы находим:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

только три недостающих символа в этом описании используются в domain-literal [], чтобы сформировать цитируемую пару \ и Пробел (%d32). При этом используется весь диапазон 32-126 (десятичный). Аналогичное требование отображается как "qtext"и " ctext". Многие управляющие символы также разрешены / используются. Один список таких символов управления отображается на стр. 31 раздел 4.1 RFC 5322 как obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

все эти управляющие символы разрешены, как указано в начале раздела 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

и поэтому такое правило включения является "слишком широким". Или, в другом смысле, ожидаемое правило "слишком упрощенно".

автор: Yevgeniy Afanasyev · Accepted Answer · 2015-07-23 02:00:19

в моем PHP я использую эту проверку

<?php
if (preg_match(
'/^(?:[\w\!\#$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

попробуйте сами http://phpfiddle.org/main/code/9av6-d10r

автор: Mau · Accepted Answer · 2017-05-19 20:26:45

Я создал это регулярное выражение в соответствии с рекомендациями RFC:

^[\w\.\!_\%#\$\&\'=\?\*\+\-\/\^\`\{\|\}\~]+@(?:\w+\.(?:\w+\-?)*)+$

автор: Sha · Accepted Answer · 2017-06-11 02:00:54

для тех, кто заинтересован в проверке международных доменов, здесь доступен инструмент .NET (не связанный с компанией):

http://cobisi.com/email-validation/.net-component - совместимый с длинным списком RFCs:

стандарты IETF (RFC 1123, RFC 2821, RFC 2822, RFC 3490, RFC 3696, RFC 4291, RFC 5321, RFC 5322 и RFC 5336), с поддержкой цитируемых слов, литералы домена, не-ASCII доменные имена (IDNA) и почтовые ящики, и комментарии

автор: BradChesney79 · Accepted Answer · 2018-02-26 18:31:10

для простоты Я дезинфицирую представление, удаляя весь текст в двойных кавычках и связанные с ними двойные кавычки перед проверкой, помещая кибош на отправку адресов электронной почты на основе того, что запрещено. Просто потому, что у кого-то может быть Джон.. "The * $hizzle * Bizzle" ..Doe@whatever.com адрес не означает, что я должен разрешить это в моей системе. Мы живем в будущем, где, возможно, требуется меньше времени, чтобы получить бесплатный адрес электронной почты, чем сделать хорошую работу торец. И это не так, как если бы критерии электронной почты не были оштукатурены рядом с входом, говорящим, что разрешено, а что нет.

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

запрещены:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

в приведенном примере:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

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

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

Я не разрешаю вонючие письма в моей системе, возможно, это просто выбрасывание денег. Но в 99,9% случаев люди просто делают правильные вещи и имеют электронную почту, которая не подталкивает пределы соответствия к краю, используя сценарии совместимости edge case. Будьте осторожны с regex Ддос, это место, где вы можете попасть в беду. И это связано с третьей вещью, которую я делаю, я устанавливаю ограничение на то, как долго я готов обрабатывать любое письмо. Если ему нужно замедлить мою машину, чтобы получить проверку-это не проходит мимо моей логики конечной точки API входящих данных.

Edit: этот ответ продолжал получать dinged за то, что он "плохой", и, возможно, он этого заслуживал. Может, все еще плохо, а может, и нет.

автор: Mohammed · Accepted Answer · 2014-09-17 18:22:36

Gmail позволит только + знак как специальный символ и в некоторых случаях (.), но и любые другие специальные символы не допускаются в Gmail. RFC говорит, что вы можете использовать специальные символы, но вы должны избегать отправки почты в Gmail со специальными символами.