Angular.js: валидатор электронной почты неправильный

Созданный на 20 янв. 2014  ·  26Комментарии  ·  Источник: angular/angular.js

Если ввести адрес электронной почты:
мне @ .example.com

Он говорит, что электронная почта действительна.

Проверьте это в этом URL-адресе (из документов):

http://docs.angularjs.org/api/ng.directive : input.email

moderate bug

Самый полезный комментарий

Вы можете быстро исправить это, используя ng-pattern

<input type="email" ng-pattern="/^[_a-z0-9]+(\.[_a-z0-9]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$/">

Все 26 Комментарий

Да, вы правы, похоже, что EMAIL_REGEX неверен.

Согласно http://dev.w3.org/html5/markup/input.email.html , мы можем использовать

/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

и похоже, что он должен работать лучше, потому что не включает . после @

Я попробую отправить быстрый патч для этого.

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

Если вы можете решить эту проблему раньше меня, отправьте запрос на перенос.

Спасибо за сообщение об ошибке. В демонстрации документации вы не заметите этого исправления до тех пор, пока не упадет версия 1.2.10, потому что она постоянно загружает угловой скрипт 1.2.9. Но через несколько дней вы должны увидеть это в демонстрации документа (если фиксация не будет отменена, что может произойти O_O)

Отлично, 10х!

В среду, 22 января 2014 г., в 5:32, Кейтлин Поттер [email protected] написала :

Спасибо за сообщение об ошибке. В демонстрации документации вы не заметите этого исправления
пока 1.2.10 не упадет, потому что он постоянно загружает угловой скрипт 1.2.9.
Но через несколько дней вы должны увидеть это в демонстрационной версии документа.

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/angular/angular.js/issues/5899#issuecomment -32990587
.

Каким было мое выражение лица, когда я заметил, что " dummy @ ferferfe " (без домена) считается действительным письмом;)

@ mica16, но dummy@ferferfe - действительный адрес электронной почты. Домены не нуждаются в расширении, просто подумайте о localhost .

@Zequez правильно, но кто, черт возьми, использует адрес localhost для регистрации веб-сайтов в примере?

@mbeckenbach Использование
ng-pattern = "/ ^ [a-z0-9! # $% & '* + / =? ^ _` {|} ~ .-] + @ [a-z0-9 -] +. [a-z0 -9 -] / "
Не идеально, но работает.

@mbeckenbach да, правда. Но учтите, что доменное имя без точек - это действительный домен. То, что ICANN не позволит вам зарегистрировать домен у ИХ, не означает, что доменное имя недействительно.

6 @ 6 не является адресом электронной почты. Тот факт, что это может быть правильный адрес электронной почты в особых обстоятельствах, на мой взгляд, не должен заставлять нас разрешать это. Шансы на ошибку, допущенную через этот разрешающий шаблон, на порядки больше, чем вероятность того, что мы исключим кого-то с таким адресом электронной почты.

+1 для Джеффа

@jeffmcmahan Мне очень жаль, но похоже, что вам следует

Теперь, если вы хотите быть немного более строгим, вы также можете добавить валидатор шаблона, это будет нормально.

@caitp Ты босс.

Как насчет того, чтобы настроить EMAIL_REGEXP? Наша проверка на стороне сервера строже, чем проверка angularjs. В частности, он требует, например, чтобы длина части перед знаком @ не превышала 63 символа. Теперь нам нужно создать настраиваемую директиву для всех входных сообщений электронной почты или не забыть добавить шаблон ng для каждого ввода электронной почты.

вы можете использовать ng-pattern в дополнение к type = email, @rjokelai - также, изменение конвейера проверки @matsko упростит добавление настраиваемой проверки электронной почты

«Теперь, если вы хотите быть немного более строгим, вы также можете добавить валидатор шаблона, это будет хорошо».

как насчет валидатора по умолчанию, который принимает только обычные электронные письма с точкой в ​​них, и если кто-то из крошечного меньшинства хочет быть менее строгим, они могут сделать свой собственный валидатор. Почему подавляющему большинству разработчиков нужно создавать свои собственные паттерны, чтобы крошечному меньшинству этого не требовалось? Это глупый пуризм стандартов

потому что это в основном полифилл для проверки ограничений html5, вот почему. На следующей неделе мы надеемся выпустить функцию, которая упростит настройку.

Действительны ли электронные письма без доменной зоны? Я тестирую простое поле ввода с помощью type = "email", а Angular успешно проверяет электронную почту

О, уже есть закрытая проблема - https://github.com/angular/angular.js/issues/9463

Действительны ли электронные письма без доменной зоны? Я тестирую простое поле ввода с помощью type = "email", а Angular успешно проверяет электронную почту foo @ bar . (Угловой v1.3.0)

Это действительные электронные письма согласно спецификации. На этот вопрос столько раз ответили в этом трекере проблем, что нет ничего недействительного в электронном письме без TLD.

Используйте настраиваемый валидатор, чтобы запросить конкретные TLD, которые вы хотите

@caitp , я понимаю, что мы беспокоили вас по этому поводу, но я думаю, что было бы полезно, если бы вы объяснили, почему соблюдение спецификации является обязательным. Мы все понимаем, что разумный и компетентный разработчик не будет предполагать, что валидатор электронной почты допускает _0 @ 0_. То есть он будет использоваться для стандартной ситуации регистрации формы, и во многих таких ситуациях это вызовет проблемы. И нам говорят, что важность соблюдения спецификации перевешивает эти проблемы. Хорошо. Но почему?

Потому что будет очень странно, когда ваш браузер говорит, что он действителен, а angular говорит, что это не так.

Вы не ищете проверку электронной почты, вы ищете проверку шаблона поверх проверки электронной почты - вам нужны действительные адреса электронной почты (обрабатываемые angular), которые соответствуют определенному шаблону (содержит TLD)

  1. Было бы странно, если бы вы добавили проверку шаблона, а затем «ваш браузер говорит, что он действителен, а [A] ngular говорит, что это не так»? Нет. Так почему это было бы странно, если бы эта проверка шаблона была встроена?
  2. Мы все знаем, что то, что считается действительным адресом электронной почты в интересующем нас варианте использования, уже, чем спецификация.

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

Так почему это было бы странно, если бы эта проверка шаблона была встроена?

Фактически, вы получаете такое же поведение от браузера. http://jsfiddle.net/t6rdmngo/ Если вы запустите это в современном браузере, вы не сможете отправить верхнюю форму из-за несоответствия шаблона, если вы не включите TLD.

В версии angular вы получаете такое же поведение. Это хорошо. Это то, что мы хотим. Идентичное поведение между собственным поведением и поведением фреймворка. У фреймворка не должно быть разногласий с платформой

Теперь я понимаю. Спасибо, что потерпели меня!

Вы можете быстро исправить это, используя ng-pattern

<input type="email" ng-pattern="/^[_a-z0-9]+(\.[_a-z0-9]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$/">

Если вы измените последний * на + в регулярном выражении, он будет работать, как ожидалось

http://w3c.github.io/html-reference/input.email.html

/^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~- provided+@[a-zA-Z0-9-pting+(?:.[a -zA-Z0-9 -] +) + $ /

Была ли эта страница полезной?
0 / 5 - 0 рейтинги