preg_match проверка неанглийских адресов электронной почты (международные доменные имена)

Question

Мы все знаем, что проверка адреса электронной почты является осязаемым предметом, существует так много мнений о наилучшем способе борьбы с ним без кодирования для всего RFC. Но с 2009 года он становится еще более сложным, и я пока не видел, чтобы кто-либо обращался к проблеме IDN.

Вот что я использую:

preg_match(/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,6}\z/i) 

, который будет работать для большинства адресов электронной почты, но что, если мне нужно, чтобы соответствовать нонам латинского адреса электронной почты? например, bob @ china. 中國, или bob@russia.рф

Посмотрите here для получения полного списка. (Обратите внимание на все нелатинские расширения домена внизу списка.)

Информация об этом предмете может быть найдена here, и я думаю, что они говорят, что эти новые символы будут просто считаться «.xn - fiqz9s 'и' .xn - p1ai 'на уровне машины, но я не уверен на 100%.

Если это так, значит ли это единственное изменение, которое мне необходимо рассмотреть в моем коде: (Для доменных расширений, таких как .travelersinsurance и .sandvikcoromant)

preg_match(/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,20}\z/i) 

ВНИМАНИЕ: Это не связанно с обсуждением найденного на этой странице Using a regular expression to validate an email address

Answer 1

Вот что я в итоге придумал.

preg_match(/^[\pL\pM*+\pN._%+-]+@[\pL\pM*+\pN.-]+\.[\pL\pM*+]{2,20}\z/u) 

Это использует Unicode регулярные выражения как \ рь, \ рм * + и \ пН, чтобы помочь мне справиться с символами и числами с любого языка.

\ pL Любое письмо с любого языка, верхнего или нижнего регистра.

\ pM * + Соответствует нулю или более кодовым точкам, которые объединяют метки. Персонаж, который должен сочетаться с другим персонажем (например, акцентами, умлаутами, обложками и т. Д.).

\ pN Любое число.

Выражение выше будет работать отлично для обычных адресов электронной почты, как me@mydomain.com и какофония адрес электронной почты, как A.ş 中 3_yÄh মহাজোটের оо 文% 网 +d-fελληνικά@πyÄhooαράδειγμα.δοκιμή.

Это не то, что я не доверяю людям, чтобы иметь возможность вводить собственные адреса электронной почты, но люди делают ошибки, и я могу использовать этот код в других ситуациях. Например: мне нужно дважды проверить целостность существующего списка из 10 000 адресов электронной почты.Кроме того, меня всегда учили НЕ доверять пользовательскому вводу и фильтру ВСЕГДА.

UPDATE

Я только что обнаружил, что, хотя это прекрасно работает при тестировании на таких сайтах, как phpliveregex.com и локально при разборе обычную строку для содержания UTF-8 не работает должным образом с полями электронной почты, потому что браузеры преобразования полей от этого типа контента до нормального латина. Таким образом, адрес электронной почты, такой как bob @ china. 中國 или bob@russia.рф, преобразуется до получения сервером bob@china.xn--fiqz9s или bob@russia.xn--p1ai. Единственное, чего я действительно отсутствовал в моем исходном фильтре, было включение дефис из расширения домена.

Вот окончательная версия:

preg_match('/^[a-z0-9%+-._]+@[a-z0-9-.]+\.[a-z0-9-]{2,20}\z/i'); 

Answer 2

Я буду придерживаться верного и предположения, что вы должны отправьте им электронное письмо с подтверждением. Нет необходимости в причудливом регулярном выражении, которое нужно будет обновлять снова и снова. Просто предположите, что они знают свой адрес электронной почты и позволяют им вводить его.

Это то, что я всегда делал, когда возникает такая ситуация. Если что-нибудь, что я сделал бы, чтобы они дважды вводили их адрес. Это позволит вам потратить больше времени на важные части вашего сайта/проекта.

Answer 3

Рассмотрим: Каждый раз, когда вы сделаете свое собственное новое регулярное выражение без проверки адресов в соответствии с полной спецификацией RFC, вы просто сделать ситуацию с помощью " экзотических "адресов электронной почты в Интернете. Вы изобретаете какой-то новый вспомогательный суб или надмножество официальной спецификации RFC; это означает, что вы либо будете иметь ложные срабатывания, либо ложные негативы, либо и то, и другое, вы лишите людей использовать их фактические адреса, потому что ваше регулярное выражение не учитывает их правильно или вы принимаете адреса, которые фактически недействительны.

Добавьте к этому, что даже если адрес синтаксически действителен, это еще не означает, что a) фактически существует (по-прежнему) адрес, b) принадлежит этому пользователю или c) может фактически получать электронную почту. В схеме грантов вещей проверка синтаксиса является чрезвычайно незначительной проблемой.

Если вы собираетесь проверить синтаксис вообще, либо сделать очень грубый общий чек, который, несомненно, не отклонять любые действительные адреса (например /.+@.+/), или Validate в соответствии со всеми правилами RFC; не делайте некоторые промежуточные полусферические сортировки строго-но-не-действительно проверки, которые вы только что придумали.