Помимо всех предложений по регулярным выражениям, которые в основном не поддерживают все доступных TLD (включая, например, .info
и .museum
) и предстоящее решение ICANN разрешить использование китайского и арабского в URL ( который позволил бы [a-z]
и \w
потерпеть неудачу), для которого достаточно следующего более общего регулярного выражения
([^.@]+)(\.[^.@]+)*@([^.@]+\.)+([^.@]+)
Я бы также упомянул, что выполнение WHERE user=test OR user=test@example.com
слишком подвержено ошибкам. Лучше использовать автоматически сгенерированный PK в таблице и использовать его в предложении WHERE
.
Я действительно не вижу значения строгих, длинных и нечитаемых почтовых выражений, соответствующих спецификациям RFCxxxx. Лучшим способом по-прежнему является отправка письма со ссылкой с ключом активации конечному пользователю, чтобы он мог подтвердить адрес электронной почты. Сообщите это также в форме. При необходимости позвольте пользователю ввести адрес электронной почты дважды, как вы делаете для паролей.