Angular.js: 이메일 검사기가 잘못되었습니다.

네 맞습니다. EMAIL_REGEX가 잘못된 것 같습니다.

http://dev.w3.org/html5/markup/input.email.html 에 따르면 다음을 사용할 수 있습니다.

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

과 같은 그 모습 때문에 포함하지 않음에 더 잘 작동합니다 . 다음 @

이에 대한 빠른 패치를 제출해 보겠습니다.

... 실제로, 이것은 제가 생각했던 것보다 조금 더 복잡합니다. 조금 더 많은 작업이 필요할 수 있습니다. 마침표로 시작하는 정규 표현식도 허용하는 것처럼 보입니다. 그래서 여기서해야 할 일이 약간 있습니다.

나보다 먼저이 문제를 해결할 수 있다면 언제든지 pull request를 제출하십시오.

버그 신고에 감사드립니다. 문서 데모에서는 항상 1.2.9 각도 스크립트를로드하기 때문에 1.2.10이 떨어질 때까지이 수정 사항을 알 수 없습니다. 그러나 며칠 후에 문서 데모에서이 문제가 해결되는 것을 볼 수 있습니다 (커밋이 되 돌리지 않는 한 O_O가 발생할 수 있음).

좋아요, 10 배!

2014 년 1 월 22 일 수요일 오전 5:32, Caitlin Potter [email protected]

버그 신고에 감사드립니다. 문서 데모에서는이 수정 사항을 알 수 없습니다.
1.2.9 각도 스크립트를 항상로드하기 때문에 1.2.10이 떨어질 때까지.
그러나 며칠 후에 문서 데모에서이 문제가 해결되는 것을 볼 수 있습니다.

—
이 이메일에 직접 회신하거나 Gi tHub에서 확인하십시오.
.

" dummy @ ferferfe "(도메인 없음)가 유효한 메일로 간주된다는 것을 알았을 때 내 표정은

@ mica16 이지만 dummy@ferferfe 은 유효한 이메일 주소입니다. 도메인에는 확장자가 필요하지 않습니다. localhost 대해 생각해보세요.

@Zequez는 맞지만 예를 들어 웹 사이트 등록을 위해 로컬 호스트 주소를 사용하는 사람은 누구입니까?

@mbeckenbach 사용
ng-pattern = "/ ^ [a-z0-9! # $ % & '* + / =? ^ _`{|} ~ .-] + @ [a-z0-9-] +. [a-z0 -9-] / "
이상적이지는 않지만 작동합니다.

@mbeckenbach 예, 사실입니다. 그러나 점이없는 도메인 이름은 유효한 도메인입니다. ICANN이 THEM에 도메인 등록을 허용하지 않는다고해서 도메인 이름이 유효하지 않다는 의미는 아닙니다.

6 @ 6 은 이메일 주소가 아닙니다. 특별한 상황에서 적절한 이메일 주소가 될 수 있다는 사실이 제 생각에는 우리가 그것을 허용하도록 유도해서는 안됩니다. 이 허용 패턴을 통해 실수가 발생할 확률은 그러한 이메일 주소를 가진 사람을 제외 할 확률보다 훨씬 더 큽니다.

Jeff에게 +1

@jeffmcmahan 죄송하지만 IETF 또는 WHATWG에 문제를 제출해야하는 것 같습니다. 이메일 주소의 정의가 변경되면 Angular에서 변경해야하지만 실제로 RFC 및 WHATWG 권장 사항에 설명 된 내용을 따라야합니다.

이제 좀 더 엄격하게하고 싶다면 패턴 유효성 검사기를 추가해도됩니다.

@caitp 당신은 보스입니다.

EMAIL_REGEXP를 구성 가능하게 만드는 것은 어떻습니까? 서버 측 유효성 검사는 angularjs보다 엄격합니다. 특히 @ 기호 앞의 부분은 63자를 넘지 않아야합니다. 이제 모든 이메일 입력에 대한 사용자 지정 지시문을 생성하거나 각 이메일 입력에 ng-pattern을 추가해야합니다.

또한, @matsko의 검증 파이프 라인의 변화는 쉽게 사용자 정의 이메일 유효성 검사를 추가 할 것입니다 - 당신은 @rjokelai 입력 = 이메일 이외에 겨 패턴을 사용할 수 있습니다

"이제 좀 더 엄격하게하고 싶다면 패턴 유효성 검사기를 추가해도 괜찮을 것입니다."

기본 유효성 검사기는 점이있는 일반 이메일 만 수락하고, 소수의 누군가가 덜 엄격 해지기를 원하는 경우 자체 유효성 검사기를 만들 수 있습니다. 왜 대다수의 개발자는 소수가하지 않아도되도록 자신 만의 패턴을 만들어야합니까? 이것은 어리석은 표준 순수주의입니다

이것이 기본적으로 html5 제약 조건 검증을위한 폴리 필이기 때문에 그 이유입니다. 다음 주에이 작업을 훨씬 쉽게 사용자 정의 할 수있는 기능을 제공 할 예정입니다.

도메인 영역이없는 이메일은 유효합니까? type = "email"로 간단한 입력 필드를 테스트하고 있으며 Angular는 _foo @ bar_ 이메일을 성공적으로 확인합니다. (Angular v1.3.0)

아, 이미 닫힌 문제가 있습니다 — https://github.com/angular/angular.js/issues/9463

도메인 영역이없는 이메일은 유효합니까? type = "email"로 간단한 입력 필드를 테스트하고 있으며 Angular는 foo @ bar 이메일을 성공적으로 검증합니다. (Angular v1.3.0)

사양에 따라 유효한 이메일입니다. 이 질문은이 문제 추적기에서 여러 번 답변되었으며 TLD가없는 이메일에 대해서는 유효하지 않습니다.

원하는 특정 TLD를 요구하려면 사용자 지정 유효성 검사기를 사용하십시오.

@caitp , 나는 우리가 이것에 대해 당신을 _0 @ 0_을 허용한다고 가정하지 않을 것임을 알고 있습니다

브라우저가 유효하다고 말하고 각도가 유효하지 않다고 말하면 정말 이상 할 것이기 때문입니다.

이메일 유효성 검사를 찾고 있지 않고 이메일 유효성 검사 위에 패턴 유효성 검사를 찾고 있습니다 --- 특정 패턴 (TLD 포함)과 일치하는 유효한 이메일 주소 (각도로 처리됨)를 원합니다.

1. 패턴 유효성 검사를 추가 한 다음 "브라우저가 유효하다고 말하고 [A] ngular는 유효하지 않다고 말하면"이상할까요? 아니요. 그렇다면 패턴 유효성 검사가 내장되어 있다면 왜 이상할까요?
2. 우리 모두는 우리가 관심있는 사용 사례에서 유효한 이메일을 전달하는 것이 사양보다 좁다는 것을 알고 있습니다.

_Angular가 내가 관심있는 사용 사례를 제공하지 않아야하는 이유를 알고 싶습니다. 일반적인 경우이기 때문입니다 ._

그렇다면 패턴 유효성 검사가 내장되어 있다면 왜 이상할까요?

실제로 브라우저에서 동일한 동작을 얻습니다. http://jsfiddle.net/t6rdmngo/ 최신 브라우저에서 실행하는 경우 TLD를 포함하지 않으면 패턴 불일치로 인해 최상위 양식을 제출할 수 없습니다.

각도 버전에서 동일한 동작을 얻습니다. 이것은 좋다. 이것이 우리가 원하는 것입니다. 네이티브 동작과 프레임 워크 동작 간의 동일한 동작. 프레임 워크는 플랫폼과 의견이 일치하지 않아야합니다.

이제 알겠다. 참아 줘서 고마워!

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.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:.[a -zA-Z0-9-] +) + $ /