문제

나는 최근에 표준의 모든 변형과 가능성을 고려하여 이메일 주소와 일치하는 Regexp를 작성하는 어딘가를 읽는 것이 매우 어렵고 처음에 가정하는 것보다 훨씬 더 복잡합니다.

누구든지 왜 그런지에 대한 통찰력을 제공 할 수 있습니까?

실제로 이것을 완전히 수행하는 것으로 알려져 있고 입증 된 regexp가 있습니까?

이메일 주소와 일치하는 데 regexps를 사용하는 좋은 대안은 무엇입니까?

도움이 되었습니까?

해결책

공식적인 전자 메일 사양, 예, 주석과 같은 것들 (특히 공백에 대한 주석을 먼저 제거하지 않는 경우)과 다양한 형식 (전자 메일 주소가 항상있는 것은 아닙니다. 누군가 @somewhere.tld). 당신은 (거대하고 이해할 수없는 Regex 패턴으로) 가까워 질 수 있지만 이메일을 확인하는 훨씬 더 나은 방법은 매우 친숙한 악수를하는 것입니다.

  • 그들은 당신에게 그들의 이메일을 말해줍니다
  • 당신은 그들에게 안내서와의 만남 링크를 이메일로 보내줍니다
  • 그들이 링크를 클릭하면 다음을 알고 있습니다.

    1. 이메일이 정확합니다
    2. 존재합니다
    3. 그들은 그것을 소유합니다

이메일 주소를 맹목적으로 수락하는 것보다 훨씬 낫습니다.

다른 팁

이를 수행하는 여러 PERL 모듈 (예 : 많은 Perl 모듈)이 있습니다. 자신의 regexp를 쓰려고 시도하지 마십시오. 보다

Mail::VRFY 구문 및 네트워크 점검을 수행합니다 (DO 및 SMTP 서버는이 주소를 수락합니다)

https://metacpan.org/pod/mail::vrfy

RFC::RFC822::Address - 재귀 하강 이메일 주소 파서.

https://metacpan.org/pod/rfc::rfc822::aDdress

Mail::RFC822::Address -REGEXP 기반 주소 검증, 미친 regexp를 위해만 볼 가치가 있습니다.

http://ex-parrot.com/~pdw/mail-rfc822-address.html

다른 언어에 대해서도 비슷한 도구가 존재합니다. 아래의 미친 regexp ...

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

전자 메일 주소를 검증하는 것은 어쨌든 실제로 도움이되지 않습니다. 일반적인 오타 나 메이크업 전자 메일 주소를 포착하지 않습니다. 왜냐하면 이들은 유효한 주소처럼 보이는 경향이 있기 때문입니다.

주소가 유효한지 확인하려면 확인 메일을 보내는 것 외에는 선택의 여지가 없습니다.

사용자가 "ASDF"가 아닌 이메일처럼 보이는 것을 입력하고 싶다면 @를 확인하십시오. 더 복잡한 검증은 실제로 어떤 이점도 제공하지 않습니다.

(나는 이것이 당신의 질문에 대답하지 않는다는 것을 알고 있지만, 어쨌든 언급 할 가치가 있다고 생각합니다)

나는 이제 Cal Henderson, Dave Child, Phil Haack, Doug Lovell 및 RFC 3696에서 테스트 사례를 모았습니다. 158 테스트 주소.

나는 내가 찾을 수있는 모든 유효성 검사기에 대해이 모든 테스트를 실행했습니다. 비교는 여기에 있습니다. http://www.dominicsayers.com/isemail

사람들이 유효성 검사기를 향상 시키면서이 페이지를 최신 상태로 유지하려고 노력할 것입니다. Cal, Dave 및 Phil 에게이 테스트를 편집하고 건설적인 비판을 제공하는 데 도움과 협력에 감사드립니다. 내 자신의 유효성 검사기.

사람들은 RFC 3696에 대한 오류 특히. 표준 예제 중 세 가지는 실제로 유효하지 않은 주소입니다. 주소의 최대 길이는 254 또는 256 자입니다. ~ 아니다 320.

'+'와 같은 캐릭터를 허용하는 것이 스팸 퇴치 사용자에게 매우 유용 할 수 있지만 예를 들어 넌센스가 아닙니다. myemail+sketchysite@gmail.com (즉각적인 일회용 Gmail 주소).

사이트가 그것을 받아 들일 때만.

BNF에는 유효한 이메일 주소를 설명하는 컨텍스트 무료 문법이 있습니다. RFC-2822. 복잡합니다. 예를 들어:

" @ "@example.com

유효한 이메일 주소입니다. 나는 그것을 완전히 수행하는 regexp를 모른다. 일반적으로 주어진 예제는 먼저 주석을 제거해야합니다. 나는 다시 한 번 완전히하기 위해 재귀 적 출신 파서를 썼습니다.

기괴하고 흔하지 않은 이메일 주소 형식을 받아 들일지 여부는 제 생각에 자신이 원하는 것에 달려 있습니다.

메일 서버를 작성하는 경우 수용 한 내용이 매우 정확하고 극도로 정확해야합니다. 따라서 위에서 인용 한 "미친"정규식이 적절합니다.

그러나 우리의 나머지 사람들은 주로 웹 양식의 사용자 유형이 합리적으로 보이고 일종의 SQL 주입 또는 버퍼 오버 플로우가 없는지 확인하는 데 관심이 있습니다.

솔직히, 누군가가 메일 링리스트, 뉴스 레터 또는 웹 사이트에 가입 할 때 의견, 신어선, 따옴표, 공간, 괄호 또는 기타 횡설수설이있는 200 개의 문자 전자 메일 주소를 입력하는 것에 관심이 있습니까? 그러한 광대에 대한 적절한 반응은 "username@domain.tld와 같은 주소가있을 때 나중에 다시 오십시오"입니다.

내가하는 검증은 정확히 하나의 '@'가 있는지 확인하는 것으로 구성됩니다. 공간, 널 또는 신축성이 없다는 것; '@'의 오른쪽 부분은 적어도 하나의 점 (줄에 두 개의 도트가 아님)을 가지고 있습니다. 그리고 따옴표, 괄호, 쉼표, 콜론, 느낌표, 세미콜론 또는 백 슬래시가 없으며,이 모든 것은 실제 이메일 주소의 일부보다 해커에 대한 시도 일 가능성이 높습니다.

예, 이것은 누군가 내 웹 사이트에 등록하려고 할 수있는 유효한 주소를 거부한다는 것을 의미합니다. 아마도 실제 주소의 0.001%를 "잘못"거부 할 것입니다! 나는 그것과 함께 살 수 있습니다.

RFC의 거의 사용되지 않지만 유효한 부분을 인용하고 다양한 기타 다양한 다른 부분은 어려워집니다. 나는이 주제에 대해 충분히 알지 못합니다. 다른 사람들은 가지고있다 그것에 대해 길게.

유효한 Regex는 Perl Mail :: RFC822 :: 주소 모듈이 포함됩니다. 분명히 작동하는 정규 표현 - 그러나 댓글이 이미 공백으로 대체 된 경우에만. (이메일 주소의 댓글은 무엇입니까? 당신은 왜 기대하는 것보다 어려운지 알 수 있습니다 ...)

물론, 다른 곳에있는 단순화 된 Regexes는 진정으로 사용되는 거의 모든 이메일 주소를 검증 할 것입니다 ...

Regex의 일부 맛은 실제로 중첩 된 브래킷 (예 : Perl 호환 브래킷)과 일치 할 수 있습니다. 즉, 나는 RFC 822를 올바르게 일치한다고 주장하는 정규식을 보았으며 공백이없는 두 페이지의 텍스트였습니다. 따라서 유효한 이메일 주소를 감지하는 가장 좋은 방법은 이메일을 보내고 작동하는지 확인하는 것입니다.

@mmaibaum이 나열한 것보다 덜 미쳤던 정규식을 추가하기 위해 :

^[a-zA-Z]([.]?([a-zA-Z0-9_-]+)*)?@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$ 

방탄이 아니며 전체 이메일 사양을 다루지는 않지만 대부분의 기본 요구 사항을 다루는 괜찮은 작업을 수행합니다. 더 좋은 점은 다소 이해하기 쉬우 며 편집 할 수 있습니다.

토론에서 구겨진 HouseOffusion.com, 세계적 수준의 냉담한 자원.

Java에서 이메일 조정을 확인하는 쉽고 좋은 방법은 Apache의 이메일 Validator를 사용하는 것입니다. 커먼즈 유효성 검사기 도서관.

오타를 보더라도 이메일을 보내기 전에 항상 입력 형식의 이메일 주소를 확인합니다. "배송 실패"알림 메일에 대한 자동 스캐너를 쓰고 싶지 않을 것입니다. :-)

이메일 사양에 따라 이메일 주소에 유효 할 수있는 많은 것들이 있기 때문에 정말 어렵습니다. RFC 2822. 일반적으로 보지 못하는 것은 +와 같이 이메일 주소에 대해 완벽하게 유효한 문자입니다. 사양에 따르면.

이메일 주소에 전념하는 전체 섹션이 있습니다. http://regexlib.com, 이것은 훌륭한 자원입니다. 나는 당신에게 어떤 기준이 당신에게 중요한지를 결정하고 일치하는 기준을 찾는 것이 좋습니다. 대부분의 사람들은 실제로 사양에 의해 허용되는 모든 가능성에 대해 완전히 지원할 필요가 없습니다.

.NET 프레임 워크에서 실행중인 경우 Instantiating을 사용해보십시오. MailAddress 물체와 잡기 FormatException 그것이 날아가거나 꺼내면 Address 그것이 성공한다면. 예외를 포획하는 성능에 대해 말도 안되는 소리에 들어 가지 않고 (실제로 단일 웹 형태 일 경우에는 그다지 큰 차이를 만들지 않을 것입니다), MailAddress .NET 프레임 워크의 클래스는 매우 완전한 구문 분석 프로세스를 거칩니다 (Regex를 사용하지 않음). 반사판을 열고 검색하십시오 MailAddress 그리고 MailBnfHelper.ReadMailAddress() 모든 멋진 것들을보기 위해. 나보다 똑똑한 사람은 Microsoft에서 그 파서를 구축하는 데 많은 시간을 보냈습니다. 실제로 주소로 이메일을 보낼 때 사용하겠습니다.

많은 사람들이 시도했고 많은 사람들이 가까이 왔습니다. 당신은 그것을 읽고 싶을 수도 있습니다 위키 백과 기사, 그리고 약간 기타.

특히, 많은 웹 사이트와 이메일 서버에는 이메일 주소의 유효성 검증이 완화되어 있기 때문에 기본적으로 표준을 완전히 구현하지는 않습니다. 그래도 이메일이 항상 작동하기에 충분합니다.

이거 한번 해봐:

"(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])"

보세요 여기 세부 사항을 위해.

그러나 RFC822 표준을 구현하는 대신 다른 관점에서이를 보는 것이 좋습니다. 메일 서버가 표준을 반영하지 않으면 표준이 말하는 것은 실제로 중요하지 않습니다. 따라서 이메일 주소를 검증 할 때 가장 인기있는 메일 서버가하는 일을 모방하는 것이 더 낫다고 주장합니다.

Java에 대한이 클래스는 다음과 같은 유효성 검사기가 있습니다.http://www.leshazlewood.com/?p=23

이것은 Shiro의 제작자 (공식적으로 KI, 공식적으로 jsecurity)에 의해 작성되었습니다.

이메일 주소 유효성에 대한 테스트의 장단점 :

전자 메일을 검증하는 두 가지 유형의 regexes가 있습니다.

  1. 너무 느슨한 것.
  2. 너무 엄격한 것들.

정규 표현식이 모든 유효한 전자 메일 주소와 일치 할 수는 없으며 일부 문자열은 유효한 전자 메일 주소처럼 보일 수 있지만 실제로 다른 사람의받은 편지함으로 이동하지 않기 때문에 유효하지 않은 전자 메일 주소가 없습니다. 이메일이 실제로 유효한 지 확인하기 위해 테스트하는 유일한 방법은 해당 주소로 이메일을 보내고 어떤 종류의 응답을 받는지 확인하는 것입니다. 이를 염두에두고 이메일을 일치시키는 데 너무 엄격한 Regexes는 실제로 많은 목적을 가진 것 같습니다.

이메일 Regex를 요청하는 대부분의 사람들은 첫 번째 옵션 인 너무 느슨한 regexes를 찾고 있다고 생각합니다. 그들은 문자열을 테스트하고 이메일처럼 보이는지 확인하고 싶어합니다. 전자 메일이 아닌 경우 사용자에게 말할 수 있습니다. "이봐, 당신은 여기에 이메일을 넣어야합니다. 유효한 이메일이 아닙니다. 아마도이 필드가 이메일을위한 것이거나 오타가 있다는 것을 몰랐을 것입니다. "

사용자가 유효한 이메일과 비슷하게 보이는 문자열을 넣지 만 실제로는 아니지만 응용 프로그램의 다른 부분에 의해 처리되어야하는 문제입니다.

누구든지 왜 그런지에 대한 통찰력을 제공 할 수 있습니까?

그렇습니다. 오늘날 아무도 실제로 사용하지 않는 많은 것들을 허용하는 매우 복잡한 표준입니다. :)

실제로 이것을 완전히 수행하는 것으로 알려져 있고 입증 된 regexp가 있습니까?

다음은 전체 표준을 완전히 구문 분석하려는 시도가 있습니다 ...

http://ex-parrot.com/~pdw/mail-rfc822-address.html

이메일 주소와 일치하는 데 regexps를 사용하는 좋은 대안은 무엇입니까?

당신이 사용하고있는 언어로 기존 프레임 워크를 사용하는 것 같아요? 그것들은 아마도 내부적으로 Regexp를 사용할 것입니다. 복잡한 문자열입니다. Regexps는 복잡한 문자열을 구문 분석하도록 설계되었으므로 실제로 최선의 선택입니다.

편집하다: 나는 내가 링크 한 regexp가 단지 재미를위한 것이라고 덧붙여 야한다. 나는 그런 복잡한 regexp를 사용하는 것을 보증하지 않습니다. 어떤 사람들은 "당신의 regexp가 둘 이상의 줄이라면 어딘가에 버그를 보장받습니다"라고 말합니다. 표준이 얼마나 복잡한 지 설명하기 위해 연결했습니다.

추가 웨인S 답변, 섹션도 있습니다 www.regular-Pexpressions.info 몇 가지 샘플이 포함 된 이메일 전용.

당신은 항상 가치가 있는지 또는 실제로 어느 100%이상의 Regexp는 잘못된 보안 감각에만 기여합니다.

결국, 실제로 배상 이메일은 실제 최종 검증을 제공 할 것입니다. (-당신은 당신의 mailserver가 버그가 있는지 알게 될 것입니다 ;-)

이 게시물의 완전성을 위해 PHP의 경우 전자 메일을 검증하는 언어 내장 기능이 있습니다.

PHP의 경우 특정 이메일 유효성 검사 유형과 함께 Nice Filter_var를 사용하십시오 :)

PHP : d에서 더 이상 미친 이메일 regexes가 없습니다

var_dump(filter_var('bob@example.com', FILTER_VALIDATE_EMAIL));

http://www.php.net/filter_var

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top