Я использовал следующий шаблон для проверки поля электронной почты.
return Regex.IsMatch(email,
@"^(?("")("".+?(?<!\\)""@)|(([0-9a-z]((\.(?!\.))|[-!#\$%&'\*\+/=\?\^`\{\}\|~\w])*)(?<=[0-9a-z])@))" +
@"(?(\[)(\[(\d{1,3}\.){3}\d{1,3}\])|(([0-9a-z][-0-9a-z]*[0-9a-z]*\.)+[a-z0-9][\-a-z0-9]{0,22}[a-z0-9]))$",
RegexOptions.IgnoreCase, TimeSpan.FromMilliseconds(250));
Он использует следующую ссылку: https://docs.microsoft.com/en-us/dotnet/standard/base-types/how-to-verify-that-strings-are-in-valid-email-format
Мое требование состоит в том, чтобы иметь максимальное количество символов 64 для пользовательской части, а максимальная длина всей строки электронной почты составляет 254 символа. Шаблон в ссылке допускает не более 134 символов. Может ли кто-нибудь дать четкое объяснение смысла шаблона? Каков правильный шаблон для достижения моей цели?
...) && email.Length < 255 && email.Split('@')[0].Length < 65;




Если вы хотите избежать использования регулярного выражения (которое, на мой взгляд, трудно расшифровать), вы можете использовать метод .Split() в строке электронной почты, используя символ «@» в качестве разделителя. Затем вы можете проверить длины строк двух компонентов оттуда.
Код, который вы указали, переработан, все, что вам нужно для проверки электронной почты, — это проверить символ at и точку. Если вам нужно что-то более точное, вы, вероятно, находитесь в точке, где вам действительно нужно отправить электронное письмо получателю и попросить его подтвердить, что он держит электронное письмо, что проще, чем сложное регулярное выражение, и что обеспечивает гораздо большую точность.
Такое регулярное выражение будет просто:
.+@.+\..+
Прокомментировано ниже
.+ At least one of any character
@ The at symbol
.+ At least one character
\. The . symbol
.+ At least one character
Конечно, это означает, что некоторые электронные письма могут быть восприняты как ложные срабатывания, например, [email protected], когда пользователь имел в виду [email protected], но даже если вы разрабатываете самые надежные регулярные выражения, которые сверяются со списком принятых TLD. , вы никогда не поймаете [email protected], и вы можете вставить положительные ложные значения, такие как [email protected], когда будет выпущен новый TLD, а ваш код не будет обновлен.
Так что будь проще.
Несколько лет назад я написал атрибут проверки электронной почты на C#, который должен распознавать большую часть этого подмножества синтаксически допустимых адресов электронной почты, имеющих форму локальная часть@домен — я говорю «большинство», потому что я не удосужился попытаться разобраться с такими вещами, как пуникод, Литералы адресов IPv4 (четверки с точками) или литералы адресов IPv6.
Я уверен, что есть много других крайних случаев, которые я пропустил. Но в то время это работало достаточно хорошо для наших целей.
Пользуйтесь на здоровье: Проверка адреса электронной почты C#
Прежде чем вы пойдете по пути написания своего собственного, вы можете прочитать несколько соответствующих RFC и попытаться понять капризы того, что представляет собой «действительный» адрес электронной почты (это не то, что вы думаете), и (2) перестать пытаться для проверки адреса электронной почты RFC 822. Практически единственный способ «подтвердить» адрес электронной почты — это отправить на него письмо и посмотреть, отвалится он или нет. Это не значит, что по этому адресу кто-то есть дома или что этот почтовый ящик не исчезнет на следующей неделе.
В книге Джеффри Фридла Освоение регулярных выражений есть [более или менее?] полное регулярное выражение для сопоставления синтаксически допустимых адресов электронной почты. Это 6598 символов.
Знаете ли вы, что postmaster@. — это официальный адрес электронной почты? Теоретически это приведет вас к почтмейстеру корневого DNS-сервера.
Или что [теоретически] адреса электронной почты типа MyDepartmentServer!MainServer!BigRouter!TheirDepartmentServer!SpecificServer!jsmith действительны. Здесь вы определяете фактический путь по сети, по которому должна проходить электронная почта. Помогает, если вы знаете задействованную топологию сети.