День восемьсот пятьдесят четвёртый. #ЗаметкиНаПолях
Валидация Email и URL в .NET
Существует множество совершенно безумных способов проверки email в .NET. Недавно я наткнулся на войну между двумя разработчиками в пул-реквесте. Война велась вокруг «идеального» регулярного выражения для проверки email.

user@domain.tld, что может быть проще?

Посмотрите на этот ответ на Stack Overflow. Регулярное выражение в ответе приведено следующее:

(?:[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])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-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])+)\])

Другой пример можно взять из валидации email в Angular. Тут также используется регулярное выражение:

^(?=.{1,254}$)(?=.{1,64}@)[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*@[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])?)*$

Немного другой, но всё равно гигантский шаблон. Итак, учитывая эти параметры (и, вероятно, многие другие), какое же выражение нам выбрать для валидации нашей модели?

public class CreateAccountViewModel
{
  [RegularExpression("SoMeCrAzYReGeX")]
  public string Email { get; set; }
}

На самом деле, ни то, ни другое. В .NET Core (и в .NET Framework) есть встроенный валидатор email:

[EmailAddress]
public string Email { get; set; }

Красиво и просто, без лишних сложностей. Но тогда возникает вопрос, какое регулярное выражение использует .NET? Вообще-то тут в принципе не используется регулярное выражение!

Логика валидации довольно проста:
1. Значение – строка?
2. Есть ли в строке символ @?
3. Находится ли символ @ в любой позиции, кроме первой или последней?
Всё. Регулярное выражение не требуется!

Это идеальный валидатор? Конечно, нет, и, если он используется в списке рассылки, то письма будут отправляться на адреса, которые не совсем соответствуют спецификации RFC. Однако, такой валидации достаточно, чтобы поймать 99,99% ошибок. Тем более, что, например, при создании учётной записи вы, скорее всего, дополнительно «проверите» email, отправив на него письмо с подтверждением регистрации.

Аналогичный атрибут [Url] для валидации URL, просто проверяет, начинается ли строка с http://, https:// или ftp://.

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

Источник: https://dotnetcoretutorials.com/2021/05/16/validating-an-email-in-a-net-api