Apache commons-альтернатива валидатора для новых gTLD

если вас не беспокоят интернационализированные адреса, вы можете изменить последнюю часть адреса и продолжить использовать Apache commons.

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

• abc.def.com действителен. Аналогично abc.def.name, abc.def.xx--kput3i, abc.def.uk действительны.
• ab,de.com is недействительный. Аналогично ab,de.name, ab,de.xx-kput3i, ab,de.uk недопустимы.

поэтому вместо того, чтобы звонить

return EmailValidator.getInstance().isValid(userEmail);

можно назвать

if ( userEmail == null ) {
    return false;
}
return EmailValidator.getInstance().isValid(userEmail.trim().replaceFirst("\.\p{Alpha}[\p{Alnum}-]*\p{Alnum}$", ".com"));

объяснение

• регулярное выражение "\.\p{Alpha}[\p{Alnum}-]*\p{Alnum}$" проверяет часть TLD: она находится в конце строки (из-за $), он начинается с точки и не содержит другой точки, и он соответствует стандартам: начинается с символа ASCII Alpha, а затем ноль или более буквенно-цифровых знаков или тире и заканчивается буквенно-цифровым символом.
• я использую trim() потому что до сих пор, если вы используете EmailValidator, это позволяет пробелы до и после адреса. Удаление пробелов просто упрощает замену TLD, и это не должно иметь значения, поскольку речь идет о действительности адреса.
• если строка не имеет допустимого TLD в конце,String.replaceFirst() вернет его как есть. Это еще может быть действительным, потому что адреса электронной почты формат x@[n.n.n.n] здесь n.n.n.n. действительный IP-адрес действительны. Так что в принципе, если вы не нашли TLD, вы позволяете EmailValidator решите вопрос о действительности сам.
• конечно, если TLD не является признанным IANA TLD, эта проверка не скажет вам об этом. Письмо типа david@galaxy.hoopie-frood будет принято как законное, но у IANA пока нет этого TLD.

проверка домена аналогична, без trim() детали:

if (userDomain == null ) {
   return false;
}
return DomainValidator.getInstance().isValid(userDomain.replaceFirst("\.\p{Alpha}[\p{Alnum}-]*\p{Alnum}$"));

я также пробовал Проверка адреса электронной почты JavaMail, но мне это не очень нравится: она позволяет полностью недопустимые доменные имена, такие как net-name.net- (заканчивается тире) или IP-адреса (которые не разрешены для электронной почты без квадратных скобок вокруг них), и это хорошо только для адресов электронной почты, а не для доменов.

интернационализации

Если вам нужно проверить для интернационализированных доменов и электронной почты, это немного другое. Легко проверить наличие интернационализированных доменов (например 元気。テスト). Все, что вам нужно сделать, это преобразовать их в ASCII с java.net.IDN.toASCII() (при xn--z4qx76d.xn--zckzah для моего примера домена-это допустимый TLD), а затем сделайте то же самое, что я написал выше.

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

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