Это действительный адрес электронной почты?
"Françoise Lefèvre"@example.com
Я читаю RFC 5321 чтобы попытаться понять, что представляет собой действительный адрес электронной почты - и я, вероятно, делаю это намного сложнее, чем это должно быть-но это меня беспокоит.
i.e., within a quoted string, any ASCII graphic or space is permitted without blackslash-quoting except double-quote and the backslash itself.
значит ли это, что ASCII расширенные наборы символов действительны в кавычках? Или это означает стандартная таблица ASCII только?
редактировать - с ответами в имейте в виду, вот простой 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) ||
(
/^[u002au002bu003du003fu0040u0020-u0027u002d-u002fu0030-u0039u0041-u005au005e-u007e]+$/.test(value.replace(/(["])(?:|.)*?/, "")) &&
/^[u0020-u007e]+$/.test(value.match(/(["])(?:|.)*?/, ""))
);
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 спецификация (разрешено в кавычках local части) позволяет только большинство значений ASCII (RFC 2822, раздел 3.4.1), который включает значения в диапазонах от 33-90 и 94-126. Было предложено RFC 5335 это позволит использовать символы, отличные от ascii в addr-spec, однако, это все еще помечены как экспериментальные и не поддерживается в почтовый адрес.
в этом RFC,ASCII
означает US-ASCII
, т. е. символы со значением больше 127 не допускаются. В качестве доказательства, вот некоторые цитаты из RFC 5321:
данные почты могут содержать любой из 128 кодов символов ASCII, [...]
[...]
системы не должны определять почтовые ящики таким образом, чтобы требовать использования в SMTP символов, отличных от ASCII (октетов с битом высокого порядка, установленным на один) или ASCII "управляющих символов" (десятичное значение 0-31 и 127). Эти символы не должны использоваться в командах MAIL или RCPT или других командах, требующих имен почтовых ящиков.
эти кавычки совершенно ясно подразумевают, что символы со значением больше 127 считаются non-ASCII
. Поскольку такие символы явно запрещены в командах MAIL TO или RCPT, их нельзя использовать для адресов электронной почты.
таким образом, "Francoise Lefevre"@example.com
является совершенно действительным адресом (в соответствии с RFC), тогда как "Françoise Lefèvre"@example.com
нет.
технически да, но читаем дальше:
пока вышеуказанное определение для Локальная-часть относительно разрешительна,
для максимальной совместимости хост что ожидает получить почту избежать определения почтовым ящикам Local-часть требует (или использует) Quoted-строковая форма или где Локальная часть чувствительна к регистру.
...
системы не должны определять почтовые ящики в такой путь как требовать использование в SMTP символов, отличных от ASCII.
спецификация HTML5 имеет интересно взять на себя вопрос о действительных адресов электронной почты:
допустимым адресом электронной почты является строка, соответствующая abnf production 1* (atext / ".") "@"ldh-str 1*( "."ldh-str), где atext определен в разделе 3.2.3 RFC 5322, а ldh-str-в разделе 3.5 RFC 1034.
хорошая вещь об этом, конечно, заключается в том, что вы можете взглянуть наисходный код проверки (ищите ). Конечно, это в C, но не слишком сложно перевести на JS.