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

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

Я просто хочу знать, какие символы разрешены в user-name и server частях электронного адреса. Это может быть упрощено, возможно, адреса электронной почты могут принимать другие формы, но мне все равно. Я прошу только об этой простой форме: [email protected] (например, [email protected]) и разрешенные символы в обеих частях.

Ответ 1

См. 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 Z и к a z;

цифры от 0 до 9;

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

точка . при условии, что он не является первым или последним символом, если он не заключен в кавычки, и при условии, что он не появляется последовательно, если не [email protected] кавычки (например, [email protected] не допускается, но "John..Doe"@example.com is позволил);

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

комментарии допускаются с круглыми скобками в любом конце локальной части; например, john.smith(comment)@example.com и (comment)[email protected] оба эквивалентны [email protected].

В дополнение к символам ASCII, U+007F с 2012 года, вы можете использовать международные символы выше U+007F, закодированные как UTF-8, как описано в спецификации RFC 6532 и объяснено в Википедии. Обратите внимание, что по состоянию на 2019 г. эти стандарты все еще помечены как предлагаемые, но постепенно внедряются. Изменения в этой спецификации по существу добавили международные символы в качестве допустимых буквенно-цифровых символов (atext), не затрагивая правила для разрешенных и запрещенных специальных символов, таких как !# И @:

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

domain часть определяется следующим образом:

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

Ответ 2

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

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

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

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

http://www.amazon.co.jp/エレクトロニクス - デジタルカメラ - ポータブルオーディオ/б/исх = topnav_storetab_e т.е. = UTF-8 & амп;? узел = 3210981

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

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

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

Ответ 3

Формат адреса электронной почты: [email protected] (макс. 64 @255 символов, всего не более 256).

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

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

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

Доменная часть:

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

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

[email protected]
[email protected]
[email protected]
[email protected]
[email protected] (однобуквенная локальная часть)
"much.more unusual"@example.com
"[email protected]"@example.com
"very.(),:;<>[]\".VERY.\"[email protected]\ \"very\".unusual"@strange.example.com
[email protected]
[email protected] (локальное имя домена без домена верхнего уровня)
#!$%&'*+-/=?^_'{}|[email protected]
"()<>[]:,;@\\"!#$%&'-/=?^_'{}| ~.a"@example.org
" "@example.org (пробел между кавычками)
[email protected] (отправлено с localhost)
[email protected] (см. список интернет-доменов верхнего уровня)
[email protected]
[email protected]
[email protected][IPv6:2001:db8::1]

И эти примеры недействительны:

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

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

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

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

Полное регулярное выражение для адресов RFC2822 составило всего 3.7k.

Смотрите также: RFC 822 Email Address Parser в PHP.

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

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

Связанные с:

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

Ответ 4

В Википедии есть хорошая статья об этом, а официальный spec здесь. Материал из Википедии:

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

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

Цифры от 0 до 9

Персонажи! # $% и '* + -/=? ^ _ `{| } ~

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

Ответ 5

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

например, [email protected] - это то же самое, что и [email protected], и оба адреса электронной почты будут отправлены в тот же почтовый ящик. [email protected] также доставляется в тот же почтовый ящик.

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

*** gmail.com accepting rules ***
[email protected]   (accepted)
[email protected]   (bounce and account can never be created)
[email protected]     (accepted)
D.Oy'[email protected]   (bounce and account can never be created)

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

Ответ 6

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

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

Ответ 7

Имя:

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

Сервер:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

Хорошо читать в вопрос.

Выдержки:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"[email protected]"@example.com
customer/[email protected]
\[email protected]
!def!xyz%[email protected]
[email protected]

Ответ 11

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

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

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

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

Точное правило заключается в том, что любой символ ASCII, включая управление символы, могут отображаться в кавычках или в строке с кавычками. При цитировании необходимо, символ обратной косой черты используется для указания следующего персонаж. Например
  Abc\@[email protected]
является действительной формой адреса электронной почты. Также могут появляться пробелы, как в
  Fred\ [email protected]
Символ обратной косой черты также может использоваться для процитирования, например,
  Joe.\\[email protected]
В дополнение к цитированию с использованием символа обратной косой черты, обычный символы двойной кавычки могут использоваться для окружения строк. Например
  "[email protected]"@example.com

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

Без кавычек локальные части могут состоять из любой комбинации алфавитные символы, цифры или любые специальные символы
  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~
period ( "." ) также может появляться, но не может использоваться для запуска или завершения локальная часть, а также не может появиться два или более последовательных периода. Иными словами, любой графический (печатный) символ ASCII, кроме знак "at" ( "@" ), обратная косая черта, двойная кавычка, запятая или квадратные скобки могут появляться без кавычек. Если какой-либо из этих исключенных символы должны появляться, они должны быть указаны. Формы, такие как
  [email protected]

  customer/[email protected]

  [email protected]

  !def!xyz%[email protected]

  [email protected]
действительны и рассматриваются довольно регулярно, но любой из символов перечисленные выше.

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

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

Ответ 12

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

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

латинские буквы в верхнем и нижнем регистре A до Z и A до Z;

цифры 0 до 9;

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

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

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

комментарии допускаются с круглыми скобками на обоих концах локальной части; например john.smith(comment)@example.com и (comment)[email protected] оба эквивалентны [email protected].
В дополнение к вышеуказанным символам ASCII международные символы выше U + 007F, закодированные как UTF-8, разрешены RFC 6531, хотя почтовые системы могут ограничивать использование символов при назначении локальных частей.

Кавычка может существовать как объект, разделенный точками в локальной части, или может существовать, когда крайние кавычки являются внешними символами локальной части (например, abc."defghi"[email protected] или "abcdefghixyz"@example.com)., abc"defghi"[email protected] не является, ни abc\"def\"[email protected]). Цитированные строки и символы, однако, обычно не используются. RFC 5321 также предупреждает, что "хост, который ожидает получать почту, ДОЛЖЕН избегать определения почтовых ящиков, где Локальная часть требует (или использует) строка формы".

Локальная часть postmaster обрабатывается специально - она нечувствительна к регистру и должна быть отправлена администратору электронной почты домена. Технически все остальные локальные части чувствительны к регистру, поэтому [email protected] и [email protected] указывают разные почтовые ящики; однако многие организации рассматривают прописные и строчные буквы как эквивалентные.

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

Ответ 13

Ответ (почти) 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 ....

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

Ответ 14

Для простоты я дезинфицирую отправку, удаляя весь текст в двойных кавычках и связанные с ними двойные кавычки перед проверкой, добавляя кибошу при отправке адресов электронной почты на основании того, что запрещено. Тот факт, что кто-то может иметь Джона... "* $ hizzle * Bizzle".. Адрес [email protected] не означает, что я должен разрешить его в моей системе. Мы живем в будущем, где, возможно, потребуется меньше времени, чтобы получить бесплатный адрес электронной почты, чем делать хорошую работу, вытирая задницу. И это не так, как если бы критерии электронной почты не были намазаны прямо рядом со входом, говоря, что есть, а что нельзя.

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

Недопустимое:

    local part starts with a period ( [email protected] )
    local part ends with a period   ( [email protected] )
    two or more periods in series   ( [email protected] )
    &'*|/                          ( some&thing'[email protected] )
    more than one @                 ( [email protected]@host.com )
    :%                              ( mo:characters%mo:[email protected] )

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

John.."The*$hizzle*Bizzle"[email protected] --> [email protected]

[email protected] --> [email protected]

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

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

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

Редактировать: Этот ответ продолжал быть темным за то, что он был "плохим", и, возможно, он это заслужил. Может быть, это все еще плохо, а может и нет.

Ответ 15

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

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~][email protected](?:(?:(?:[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'[email protected]"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

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

Ответ 16

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

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

Ответ 17

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

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

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

Ответ 18

Я не знаю ни о ком другом, но мы выделяем любые символы, используемые в сценариях из всех представленных полей. У вас могут быть все нужные адреса электронной почты, но это не значит, что мы их примем. Когда основной разработчик ОС сталкивается с рисками представленного script в полях простым в использовании способом, мы будем более терпимы, но пока Microsoft еще не охватила все базы. У нас есть преимущество только в обслуживании 1 города, хотя проблема международного текста еще не имеет значения.

Ответ 19

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