Попытка автоматизировать исправление неверных данных - очень опасная практика. В конечном счете, только пользователь может предоставить правильные данные. Однако существуют строгие правила форматирования адреса электронной почты - проверка регулярных выражений может выполняться в javascript (или с использованием функций preg с тем же синтаксисом регулярных выражений) - но обратите внимание, что в Интернете существует множество плохих примеров регулярных выражений, требующих решения эта проблема.
Это должна быть довольно полная реализация валидатора RFDR28 ADDR_SPEC:
/[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?/gi
Однако на практике я нахожу это достаточным:
/^[a-z0-9\._%+!$&*=^|~#%'`?{}/\-]+@([a-z0-9\-]+\.){1,}([a-z]{2,22})$/gi
Затем на сервере вы можете выполнить MX поиск , чтобы убедиться, что предоставленный домен не только соответствует требованиям форматирования, но и существует как сайт для получения электронной почты.
Это не доказывает, что именованный почтовый ящик существует на этом сайте, и что он принимает электронные письма - в конечном итоге вам нужно будет отправить электронное письмо на этот адрес, включая ссылку / пароль обратной ссылки, чтобы установить, является ли адрес электронной почты действительным .
Обновление
Хотя, как здесь говорится в ответе с наибольшим количеством голосов, лучший способ проверить ADDR_SPEC - это отправить токен по адресу, который будет отправлен обратно через Интернет, это не очень помогает, если данные не поступают из Человек, который контролирует почтовый ящик, и действие отсоединяется от основного взаимодействия, даже когда они делают. Еще одним соображением является то, что адрес электронной почты, который действителен сегодня, может быть не завтра.
Использование регулярного выражения (и поиска в MX) по-прежнему является хорошей идеей для обеспечения немедленной обратной связи с пользователем, но для полного решения вам также необходимо отслеживать отскоки .