이메일 주소에는 어떤 문자가 허용됩니까?

완전한 이메일 유효성 검사를 요구하지 않습니다.

전자 메일 주소의 문자 user-name와 server일부에 허용되는 문자를 알고 싶습니다 . 이메일 주소가 다른 형식을 취할 수 있지만 지나치게 신경 쓰지 않을 수도 있습니다. 이 간단한 형식 user-name@server(예 : wild.wezyr@best-server-ever.com)과 두 부분 모두에서 허용되는 문자 만 묻습니다 .

참조 RFC 5322 : 인터넷 메시지 형식을 조금 적게하고, RFC 5321 : 단순 메일 전송 프로토콜 .

RFC 822 는 또한 이메일 주소를 다루지 만 대부분 다음과 같은 구조를 처리합니다.

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

그리고 평소와 같이 Wikipedia에는 이메일 주소에 관한 기사가 있습니다 .

이메일 주소의 로컬 부분은 다음 ASCII 문자를 사용할 수 있습니다.

• 대문자와 라틴 문자를 소문자 A로 Z하고 a을을 z;
• 숫자 0를 9;
• 특수 문자 !#$%&'*+-/=?^_`{|}~;
• .따옴표가없는 한 첫 번째 또는 마지막 문자가 아니며 따옴표 John..Doe@example.com가없는 한 연속적으로 나타나지 않는 경우 (예 : 허용되지 않지만 "John..Doe"@example.com허용됨) dot .
• 공백과 "(),:;<>@[\]문자는 제한이 허용됩니다 (아래 단락에 설명 된대로 따옴표로 묶은 문자열 내에서만 허용되며 또한 백 슬래시 또는 큰 따옴표 앞에 백 슬래시가 와야합니다).
• 주석은 로컬 부분의 양쪽 끝에 괄호와 함께 사용할 수 있습니다. 예를 들어, john.smith(comment)@example.com및 (comment)john.smith@example.com에 모두 동일합니다 john.smith@example.com.

ASCII 문자 외에도 2012 년 현재 RFC 6532 사양 및 Wikipedia에 설명 된대로 UTF-8로 인코딩 된 위의 국제 문자를 사용할 수 있습니다 . 2019 년 기준으로 이러한 표준은 여전히 ​​제안으로 표시되어 있지만 천천히 출시되고 있습니다. 이 사양의 변화는 본질적으로 같은 허용 및 제한 특수 문자의 규칙에 영향을주지 않고 유효 숫자 (atext)와 같은 국제 문자를 추가 하고을 .U+007F!#@:

유효성 검증 은 정규식을 사용하여 이메일 주소 유효성 검증을 참조하십시오 .

domain부분은 정의 다음과 같이 :

프로토콜에 대한 인터넷 표준 (댓글에 대한 요청) 구성 요소 호스트 이름 라벨 만 ASCII 문자를 포함 할 수 있다는 것을 의무화 a를 통해을 z(대소 문자를 구분 방식으로) 숫자 0를 통해를 9, 그리고 하이픈 ( -). RFC 952 에서 호스트 이름의 원래 사양은 레이블이 숫자 나 하이픈으로 시작할 수 없으며 하이픈으로 끝나서는 안된다고 규정했습니다. 그러나 후속 스펙 ( RFC 1123 )은 호스트 이름 레이블을 숫자로 시작하도록 허용했습니다. 다른 기호, 문장 부호 또는 공백은 허용되지 않습니다.

조심해! 이 스레드에는 많은 지식 부패가 있습니다 (이전에는 사실 이었지만 지금은 그렇지 않습니다).

현재와 ​​미래의 세계 및 전세계 어디에서나 실제 전자 메일 주소의 오탐 (false positive) 거부를 방지하려면 최소한 RFC 3490 , "IDNA (Internationalizing Domain Names in Applications)"의 고급 개념을 알아야 합니다. 나는 미국과 A의 사람들이 종종 이것에 의존하지 않는다는 것을 알고 있지만, 이미 전 세계적 으로 널리 사용되고 있으며 (주로 영어가 아닌 부분).

요점은 이제 mason @ 日本 .com 및 wildwezyr@fahrvergnügen.net과 같은 주소를 사용할 수 있다는 것입니다. 아니요. 이것은 아직 많은 것들과 호환되지 않습니다 (많은 사람들이 위에서 애도했듯이 간단한 큐메일 스타일 + 신분 주소조차도 종종 잘못 거부됩니다). 그러나 RFC가 있고 사양이 있으며 이제는 IETF와 ICANN의 지원을 받고 있으며 더 중요한 것은 현재 서비스중인 이러한 개선을 지원하는 구현이 점점 더 많아지고 있다는 것입니다.

일본으로 돌아가서 hei @ や る .ca와 같은 이메일 주소와 다음과 같은 Amazon URL을보기 시작할 때까지이 개발에 대해 많이 알지 못했습니다.

http://www.amazon.co.jp/ 에레 크 토로 니크 스-데지 타르 카메라-포타 부로 오디오 / b / ref = topnav_storetab_e? ie = UTF8 & node = 3210981

사양에 대한 링크를 원하지 않지만 인터넷 포럼의 해커에 대한 오래된 지식에만 의존하는 경우 전자 메일 유효성 검사기는 영어를 사용하지 않는 사용자가 점점 더 많이 사용할 것으로 예상되는 전자 메일 주소를 거부하게됩니다. 이러한 사용자에게는 이러한 유효성 검사가 우리 모두가 싫어하는 평범한 뇌사 형태, + 또는 3 부분으로 된 도메인 이름을 처리 할 수없는 것과 같은 성가신 것입니다.

그래서 그것은 번거롭지 않다고 말하지는 않지만 "일부 / 어떤 / 아무 조건에서도 허용되는"문자의 전체 목록은 (거의) 모든 언어의 모든 문자입니다. "모든 유효한 전자 메일 주소를 수락하고 많은 전자 메일 주소를 수락하려면" 국제화 전자 메일 주소 를 Punycode 로 먼저 변환 하지 않는 한 기본적으로 문자 기반 접근 방식을 쓸모 없게 만드는 것이 좋습니다 (죄송합니다). .

그런 다음 위의 조언을 대부분 따를 수 있습니다.

이메일 주소 형식은 다음과 같습니다 local-part@domain-part(최대 64 @ 255 자, 더 이상 256 자 이하).

local-part및 domain-part그것 이상의 규칙이 있기 때문에 허용되는 문자의 다른 세트를 가질 수 있지만,이 모두가 아니다.

일반적으로 로컬 부분은 다음 ASCII 문자를 가질 수 있습니다.

• 소문자 라틴 문자 : abcdefghijklmnopqrstuvwxyz,
• 대문자 라틴 문자 : ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
• 숫자 : 0123456789 ,
• 특수 문자: !#$%&'*+-/=?^_`{|}~ ,
• 점: . (첫 번째 또는 마지막 문자가 아니거나 인용하지 않는 한 반복되지 않음),
• 다음과 같은 공백 구두점 : "(),:;<>@[\] (일부 제한 사항이 있음),
• 의견 : ()(예 : 괄호 안에 허용 (comment)john.smith@example.com)

도메인 부분 :

• 소문자 라틴 문자 : abcdefghijklmnopqrstuvwxyz,
• 대문자 라틴 문자 : ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
• 숫자 : 0123456789 ,
• 하이픈 : - (첫번째 또는 마지막 문자가 아님),
• 대괄호로 묶인 IP 주소를 포함 할 수 있습니다 : jsmith@[192.168.2.1]또는 jsmith@[IPv6:2001:db8::1].

이 이메일 주소는 유효합니다 :

• prettyandsimple@example.com
• very.common@example.com
• disposable.style.email.with+symbol@example.com
• other.email-with-dash@example.com
• x@example.com (한글자 로컬 부분)
• "much.more unusual"@example.com
• "very.unusual.@.unusual.com"@example.com
• "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
• example-indeed@strange-example.com
• admin@mailserver1 (최상위 도메인이없는 로컬 도메인 이름)
• #!$%&'*+-/=?^_`{}|~@example.org
• "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
• " "@example.org (따옴표 사이의 공백)
• example@localhost (localhost에서 보냄)
• example@s.solutions( 인터넷 최상위 도메인 목록 참조 )
• user@com
• user@localserver
• user@[IPv6:2001:db8::1]

그리고이 잘못된 예 :

• Abc.example.com( @문자 없음 )
• A@b@c@example.com( @따옴표 밖에 하나만 허용됨)
• a"b(c)d,e:f;gi[j\k]l@example.com (이 지역 부분의 특수 문자는 따옴표 밖에 허용되지 않습니다)
• just"not"right@example.com (따옴표로 묶은 문자열은 점으로 구분되거나 로컬 부분을 구성하는 유일한 요소 여야합니다)
• this is"not\allowed@example.com (공백, 따옴표 및 백 슬래시는 따옴표로 묶인 문자열 내에 있고 백 슬래시가 앞에있을 때만 존재할 수 있습니다)
• this\ still\"not\allowed@example.com (이스케이프 처리 된 경우에도 백 슬래시로 시작), 공백, 따옴표 및 백 슬래시는 여전히 따옴표로 묶어야합니다.
• john..doe@example.com(앞에 이중 점 @); (주의 사항 : Gmail은 이것을 통해 가능합니다)
• john.doe@example..com(뒤에 두 개의 점 @)
• 선행 공백이있는 유효한 주소
• 후행 공백이있는 유효한 주소

출처 : Wikipedia의 이메일 주소

이메일 확인을위한 Perl의 RFC2822 정규식 :

(?:(?:\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*)

RFC2822 주소에 대한 전체 정규식은 3.7k에 불과했습니다.

PHP의 RFC 822 Email Address Parser 도 참조하십시오 .

이메일 주소의 공식적인 정의는 다음과 같습니다.

• RFC 5322 (섹션 3.2.3 및 3.4.1, 폐기 RFC 2822), RFC 5321, RFC 3696,
• RFC 6531 (허용되는 문자).

관련 :

• 정규 표현식의 진정한 힘

Wikipedia는 이것에 관한 좋은 기사를 가지고 있으며 , 공식 사양은 여기에 있습니다 . Wikipdia에서 :

전자 우편 주소의 로컬 부분은 다음 ASCII 문자를 사용할 수 있습니다.

• 대문자와 소문자 영문 (az, AZ)
• 숫자 0 ~ 9
• 캐릭터! # $ % & '* +-/ =? ^ _`{| } ~
• 캐릭터 . (도트, 마침표, 마침표)는 첫 번째 또는 마지막 문자가 아니며 연속적으로 두 번 이상 나타나지 않는 경우 제공됩니다.

또한 따옴표로 묶은 문자열 (예 : "John Doe"@ example.com)이 허용되므로 달리 금지 된 문자는 허용되지만 일반적인 관례에는 나타나지 않습니다. RFC 5321은 또한 "메일을받을 것으로 예상되는 호스트는 로컬 부분이 인용 문자열 형식을 요구하는 (또는 사용하는) 사서함을 정의하지 않아야한다"고 경고합니다.

구글은 그들의 gmail.com 주소로 흥미로운 일을한다. gmail.com 주소는 문자 (az), 숫자 및 마침표 (무시) ​​만 허용합니다.

예를 들어 pikachu@gmail.com은 pi.kachu@gmail.com과 동일하며 두 전자 메일 주소가 모두 같은 사서함으로 전송됩니다. PIKACHU@gmail.com도 동일한 사서함으로 배달됩니다.

따라서 질문에 대답하기 위해 때로는 구현하려는 RFC 표준의 양에 따라 구현 자에 따라 다릅니다. Google의 gmail.com 주소 스타일은 표준과 호환됩니다. 다른 사람들이 비슷한 이메일 주소를 사용하는 경우 혼동을 피하기 위해 그렇게합니다.

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

Wikipedia 링크는 일반적으로 허용되는 이메일 주소에 대한 좋은 참조입니다. http://en.wikipedia.org/wiki/Email_address

wikipedia article 에서 시작할 수 있습니다 .

• 대문자와 소문자 영문 (az, AZ)
• 숫자 0 ~ 9
• 캐릭터! # $ % & '* +-/ =? ^ _`{| } ~
• 캐릭터 . (도트, 마침표, 마침표)는 첫 번째 또는 마지막 문자가 아니며 연속적으로 두 번 이상 나타나지 않는 경우 제공됩니다.

이름:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

섬기는 사람:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

@ 및를 확인하십시오. 확인을 위해 이메일을 보냅니다.

누군가 이메일 확인을 망쳤거나 새 주소가 유효하기 때문에 인터넷 사이트의 20 %에서 내 .name 이메일 주소를 계속 사용할 수 없습니다.

짧은 대답은 두 가지 답변이 있다는 것입니다. 해야 할 일에 대한 하나의 표준이 있습니다. 즉 현명하고 문제를 예방할 수있는 행동입니다. 문제를 일으키지 않고 수용해야 할 행동에 대한 또 다른 표준이 있습니다. 이 이중성은 전자 메일을 보내고받는 데 효과적이지만 수명이 길다.

당신이 만든 주소에 대한 좋은 가이드; 참조 : http://www.remote.org/jochen/mail/info/chars.html

유효한 이메일을 필터링하려면 다음 단계를 볼 수있을만한 모든 것을 전달하십시오. 또는 많은 RFC를 읽기 시작하십시오. 여기서는 용입니다.

문제 에 대한 좋은 읽을 거리 .

발췌 :

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

허용 된 답변은 이메일 주소의 유효한 로컬 부분을 논의 할 때 Wikipedia 기사를 참조하지만 Wikipedia는 이에 대한 권한이 없습니다.

IETF RFC 3696 은이 문제에 대한 권한 이며 섹션 3 에서 참조해야합니다 . 5 페이지의 이메일 주소 제한 :

최신 전자 메일 주소는 "도메인 부분"(완전한 도메인 이름)과 at 기호 ( "@")로 구분 된 "로컬 부분"으로 구성됩니다. 도메인 부분의 구문은 이전 섹션의 구문에 해당합니다. 필터링 및 이름 목록에 대해 해당 섹션에서 식별 된 문제는 전자 메일 컨텍스트에 사용 된 도메인 이름에도 적용됩니다. 도메인 이름은 대괄호 안에있는 IP 주소로 바꿀 수도 있지만 테스트 및 문제 해결 목적을 제외하고는 해당 형식을 사용하지 않는 것이 좋습니다.

로컬 부분은 아래 설명 된 인용 규칙을 사용하여 나타날 수 있습니다. 인용 된 양식은 실제로 거의 사용되지 않지만 일부 합법적 인 목적에는 필요합니다. 따라서 필터링 루틴에서 거부하지 말고 대신 대상 호스트의 평가를 위해 전자 메일 시스템으로 전달해야합니다.

정확한 규칙은 제어 문자를 포함한 모든 ASCII 문자가 인용 부호로 표시되거나 인용 문자열로 표시 될 수 있다는 것입니다. 인용이 필요한 경우, 백 슬래시 문자는 다음 문자를 인용하는 데 사용됩니다. 예를 들어

  Abc\@def@example.com

유효한 이메일 주소 형식입니다. 다음과 같이 빈 공간이 나타날 수도 있습니다.

  Fred\ Bloggs@example.com

백 슬래시 문자는 예를 들어

  Joe.\\Blow@example.com

백 슬래시 문자를 사용한 따옴표 외에도 기존의 큰 따옴표 문자를 사용하여 문자열을 둘러 쌀 수 있습니다. 예를 들어

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

위의 첫 두 예제의 대체 형식입니다. 인용 된 이러한 양식은 거의 권장되지 않으며 실제로는 드물지만 위에서 설명한 것처럼 전자 메일 주소를 처리하는 응용 프로그램에서 지원해야합니다. 특히, 인용 된 형태는 종종 다른 시스템 및 상황으로부터의 전이와 관련된 주소의 상황에서 나타난다; 이러한 전이 요구 사항은 여전히 ​​발생하며 사용자가 제공 한 전자 메일 주소를 수락하는 시스템은 해당 주소가 레거시 시스템과 연결되어 있는지 여부를 "알 수"없으므로 주소 양식을 수락하여 전자 메일 환경으로 전달해야합니다.

따옴표가 없으면 로컬 부분은
알파벳 문자, 숫자 또는 특수 문자의 조합으로 구성 될 수 있습니다

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

마침표 ( ".")도 나타날 수 있지만 로컬 부분을 시작하거나 종료하는 데 사용되지 않거나 연속 된 두 개 이상의 마침표가 표시되지 않을 수 있습니다. 다르게 말하면, 부호 ( "@"), 백 슬래시, 큰 따옴표, 쉼표 또는 대괄호 이외의 ASCII 그래픽 (인쇄) 문자는 인용없이 나타날 수 있습니다. 제외 된 문자 목록이 나타나면 인용해야합니다. 와 같은 형태

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

유효하고 상당히 규칙적으로 표시되지만 위에 나열된 모든 문자는 허용됩니다.

다른 사람들처럼 전자 메일 주소의 유효성을 검사하기 위해 PHP와 JavaScript 모두에서 작동하는 정규식을 제출합니다.

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

이 Wikipedia 링크 에서 찾을 수 있듯이

이메일 주소의 로컬 부분은 다음 ASCII 문자를 사용할 수 있습니다.

• 대문자와 라틴 문자를 소문자 A로 Z하고 a을을 z;

• 숫자 0를 9;

• 특수 문자 !#$%&'*+-/=?^_`{|}~;

• .따옴표가없는 한 첫 번째 또는 마지막 문자가 아니며 따옴표 John..Doe@example.com가없는 한 연속적으로 나타나지 않는 경우 (예 : 허용되지 않지만 "John..Doe"@example.com허용됨) dot .

• 공백과 "(),:;<>@[\]문자는 제한이 허용됩니다 (아래 단락에 설명 된대로 따옴표로 묶은 문자열 내에서만 허용되며 또한 백 슬래시 또는 큰 따옴표 앞에 백 슬래시가 와야합니다).

• 주석은 로컬 부분의 양쪽 끝에 괄호와 함께 사용할 수 있습니다. 예를 들어, john.smith(comment)@example.com및 (comment)john.smith@example.com에 모두 동일합니다 john.smith@example.com.

위의 ASCII 문자 외에도 UTF-8로 인코딩 된 U + 007F 이상의 국제 문자는 RFC 6531 에서 허용 되지만 메일 시스템은 로컬 파트를 지정할 때 사용할 문자를 제한 할 수 있습니다.

따옴표로 묶인 문자열은 local-part 내에서 점으로 구분 된 엔터티로 존재하거나 가장 바깥 쪽 따옴표가 local-part의 가장 바깥 쪽 문자 인 경우에 존재할 수 있습니다 (예 : abc."defghi".xyz@example.com 또는 "abcdefghixyz"@example.com허용. 반대로, abc"defghi"xyz@example.com아니거나 abc\"def\"ghi@example.com). 그러나 인용 된 문자열과 문자는 일반적으로 사용되지 않습니다. RFC 5321 은 또한 "메일을받을 것으로 예상되는 호스트는 로컬 부분이 인용 문자열 형식을 요구하는 (또는 사용하는) 사서함을 정의하지 않아야 한다"고 경고합니다.

로컬 부분 postmaster은 대소 문자를 구분하지 않으므로 특별히 취급되며 도메인 전자 메일 관리자에게 전달해야합니다. 기술적 다른 로컬 파트는 대소 문자를 구분하므로 jsmith@example.com및 JSmith@example.com다른 사서함 지정; 그러나 많은 조직에서 대문자와 소문자를 동일하게 취급합니다.

기술적으로 유효한 광범위한 특수 문자에도 불구하고; 실제로 조직, 메일 서비스, 메일 서버 및 메일 클라이언트가 모든 것을 허용하지는 않습니다. 예를 들어 Windows Live Hotmail은 영숫자, 점 ( .), 밑줄 ( _) 및 하이픈 ( -)을 사용하여 전자 메일 주소 만 만들 수 있습니다 . 일반적인 조언은 이메일이 거부 될 위험을 피하기 위해 일부 특수 문자를 사용하지 않는 것입니다.

답은 (거의) ALL(7 비트 ASCII)입니다.
포함 규칙이 "... 일부 / 어떤 / 아무 조건에서도 허용되는 경우 ..."

RFC 5322 의 "도메인 텍스트"부분에서 허용되는 텍스트에 대한 몇 가지 가능한 포함 규칙 중 하나를 17 페이지 상단에서 살펴보면 다음과 같습니다.

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

이 설명에서 누락 된 문자 3 개는 domain-literal []에서 따옴표 쌍 \과 공백 문자 (% d32) 를 형성하는 데 사용됩니다 . 이를 통해 32-126 (10 진수)의 전체 범위가 사용됩니다. 비슷한 요구 사항이 "qtext"및 "ctext"로 나타납니다. 많은 제어 문자도 허용 / 사용됩니다. 이러한 제어 문자 목록 중 하나 는 RFC 5322의 31 페이지 섹션 4.1에 obs-NO-WS-CTL로 나타납니다 .

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

이 모든 제어 문자는 섹션 3.5의 시작 부분에 명시된대로 허용됩니다.

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

따라서 이러한 포함 규칙은 "너무 넓습니다". 또는 다른 의미에서 예상 규칙은 "너무 단순합니다".

간단히하기 위해 유효성 검사 전에 큰 따옴표 안의 모든 텍스트와 큰 따옴표로 묶은 관련 텍스트를 제거하여 허용되지 않는 내용에 따라 전자 메일 주소 제출에 kibosh를 배치하여 제출을 삭제합니다. 누군가 John을 가질 수 있다고해서 ". * $ hizzle * Bizzle".. Doe@whatever.com 주소가 시스템에서 허용해야한다는 의미는 아닙니다. 우리는 미래에 살고 있으며 엉덩이를 닦는 데 좋은 일을하는 것보다 무료 이메일 주소를 얻는 데 시간이 덜 걸릴 수 있습니다. 그리고 이메일 기준이 입력과 허용 안함을 나타내는 입력 바로 옆에 표시되지 않는 것처럼 보이지 않습니다.

또한 인용 된 자료를 제거한 후 다양한 RFC에서 허용되지 않는 내용을 삭제합니다. 특별히 허용되지 않는 문자 및 패턴 목록은 테스트하기에 훨씬 짧은 목록 인 것 같습니다.

허용되지 않음 :

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

주어진 예에서 :

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

이메일 주소를 추가하거나 변경하려고 할 때 확인 결과 이메일 메시지를 남은 결과로 전송하면 제출 된 이메일 주소를 코드에서 처리 할 수 ​​있는지 확인할 수 있습니다. 필요에 따라 여러 번 소독 한 후 전자 메일이 유효성 검사를 통과하면 해당 확인을 해제합니다. 요청이 확인 링크에서 돌아 오면 새 이메일을 보류 중 임시 상태 또는 스토리지에서 이동하여 실제 Bonafide 일류 저장 이메일이 될 수 있습니다.

사려 깊다면 이메일 주소 변경 실패 또는 성공 알림을 이전 이메일 주소로 보낼 수 있습니다. 확인되지 않은 계정 설정은 합당한 시간이 지나면 실패한 시도로 시스템에서 벗어날 수 있습니다.

시스템에 악취가 나는 이메일을 허용하지 않습니다. 아마도 돈을 버리는 것일 수도 있습니다. 그러나 시간의 99.9 %가 사람들이 옳은 일을하고 엣지 케이스 호환성 시나리오를 활용하는 벼랑에 적합성 제한을 두지 않는 이메일을 가지고 있습니다. 정규식 DDoS에주의하십시오. 이곳에서 문제가 발생할 수 있습니다. 그리고 이것은 내가하는 세 번째 일과 관련이 있습니다. 나는 하나의 전자 메일을 기꺼이 처리 할 시간을 제한했습니다. 유효성 검사를 위해 컴퓨터 속도를 늦춰야하는 경우 들어오는 데이터 API 엔드 포인트 논리를 벗어나지 않습니다.

편집 :이 대답은 "나쁜"것에 대한 찌그러지고 계속받을 가치가 있습니다. 어쩌면 그것은 여전히 ​​나쁘지 않을 수도 있습니다.

내 PHP에서는이 검사를 사용합니다.

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

직접 해보십시오 http://phpfiddle.org/main/code/9av6-d10r

RFC 지침에 따라이 정규식을 만들었습니다.

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

Gmail은 특수 문자 및 경우에 따라 (.) + 기호 만 허용하지만 다른 특수 문자는 Gmail에서 허용되지 않습니다. RFC에 따르면 특수 문자를 사용할 수 있지만 특수 문자를 사용하여 Gmail로 메일을 보내지 말아야합니다.