Проверка электронной почты С# asp.net

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

    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 символов. Может ли кто-нибудь дать четкое объяснение смысла шаблона? Каков правильный шаблон для достижения моей цели?

regex101.com и regexper.com удобны для расшифровки регулярных выражений и описания того, что делает каждая часть.
Rufus L 31.05.2019 23:59
...) && email.Length < 255 && email.Split('@')[0].Length < 65;
Rufus L 01.06.2019 00:03
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
2
137
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

Ответ принят как подходящий

Если вы хотите избежать использования регулярного выражения (которое, на мой взгляд, трудно расшифровать), вы можете использовать метод .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 действительны. Здесь вы определяете фактический путь по сети, по которому должна проходить электронная почта. Помогает, если вы знаете задействованную топологию сети.

Другие вопросы по теме