Это действительный адрес электронной почты?
"Françoise Lefèvre"@example.comЯ читаю RFC 5321 для попытаться понять, что является действительным адресом электронной почты - и я ASCII-изображение или пробел разрешены без кавычек, кроме двойная кавычка и обратная косая черта.
Означает ли это, что расширенные наборы символов ASCII действительны в кавычках? Или это подразумевает только стандартную таблицу ASCII ?
EDIT - Имея в виду ответы, вот простой валидатор jQuery , который может работать в дополнение к встроенному плагину -в проверке электронной почты для проверки символов.
jQuery.validator.addMethod("ascii_email", function( value, element ) { // In compliance with RFC 5321, this allows all standard printing ASCII characters in quoted text. // Unquoted text must be ASCII-US alphanumeric or one of the following: ! # $ % & ' * + - / = ? ^ _ ` { | } ~ // @ and . get a free pass, as this is meant to be used together with the email validator var result = this.optional(element) || ( /^[\u002a\u002b\u003d\u003f\u0040\u0020-\u0027\u002d-u002f\u0030-\u0039\u0041-\u005a\u005e-\u007e]+$/.test(value.replace(/(["])(?:\\\1|.)*?\1/, "")) && /^[\u0020-\u007e]+$/.test(value.match(/(["])(?:\\\1|.)*?\1/, "")) ); return result; }, "Invalid characters");Встроенная проверка плагина выглядит довольно хорошо, за исключением обнаружения неверных символов. Из тестовых случаев, перечисленных здесь здесь , он только запрещает комментарии, сворачивая пробелы и адреса без TDL (то есть: @localhost, @ 255.255.255.255) - без которых я легко могу жить.
4 ответа
Согласно этой странице MSDN расширенные символы ASCII в настоящее время недействительны, но есть предлагаемая спецификация, которая изменит это.
http://msdn.microsoft.com/en-us/library/system.net.mail.mailaddress (VS.90) .aspx
Важная часть здесь:
Томас Ли прав в что цитируется локальная часть действительна в электронном письме адрес и некоторые почтовые адреса могут быть недействительным, если не в строке в кавычках. Однако персонажи других вы упомянули умляут и агава не в ASCII набор символов, они расширены ASCII. В RFC 2822 (и последующих RFC 5322 и 3696) dtext спецификация (допускается в цитируемых местных части) допускает только большинство значений ASCII (RFC 2822, раздел 3.4.1), который включает значения в диапазоне от 33 до 90 и 94-126.RFC 5335 был предложен что позволит использовать символы, отличные от ascii в addr-spec, но все еще помечены как экспериментальные и как таковые не поддерживается в MailAddress.
Технически да, но читайте дальше:
Хотя приведенное выше определение для Локальная часть относительно терпима,
для максимальной совместимости хост который ожидает получения почты ДОЛЖЕН избегать определения почтовых ящиков, в которых Локальная часть требует (или использует) Строка в кавычках или где Локальная часть чувствительна к регистру.
...
Системы НЕ ДОЛЖНЫ определять почтовые ящики в таким образом, чтобы потребовать использования в SMTP символов, отличных от ASCII.
В этом RFC, ASCII означает US-ASCII, т.е. не допускаются символы со значением больше 127. В качестве доказательства приведем несколько цитат из RFC 5321:
Почтовые данные могут содержать любой из 128 кодов символов ASCII, [...]
[...]
Системы НЕ ДОЛЖНЫ определять почтовые ящики таким образом, чтобы требовать использования в SMTP символов, не являющихся символами ASCII (октеты с битом старшего порядка, установленным в единицу) или "управляющих символов" ASCII (десятичное значение 0-31 и 127). Эти символы НЕ ДОЛЖНЫ использоваться в командах MAIL или RCPT или других командах, требующих указания имен почтовых ящиков".
Эти кавычки совершенно ясно подразумевают, что символы со значением больше 127 считаются не ASCII. Поскольку такие символы явно запрещены в командах MAIL TO или RCPT, их невозможно использовать для адресов электронной почты.
Таким образом, "Francoise Lefevre"@example.com является совершенно правильным адресом (согласно RFC), тогда как "Françoise Lefèvre"@example.com - нет.
В спецификации HTML5 есть интересный подход к вопросу действительных адресов электронной почты:
Действительный адрес электронной почты - это строка, которая соответствует ABNF-производству 1*( atext / "." ) "@" ldh-str 1*( "." ldh-str ), где atext определен в RFC 5322 раздел 3.2.3, а ldh-str определен в RFC 1034 раздел 3.5.
Самое приятное в этом, конечно, то, что вы можете затем взглянуть на исходный код браузера с открытым исходным кодом для его проверки (ищите функцию IsValidEmailAddress). Конечно, он на языке C, но его несложно перевести на JS.