Những ký tự được cho phép trong một địa chỉ email?


641

Tôi không hỏi về xác nhận email đầy đủ.

Tôi chỉ muốn biết những gì được phép ký tự user-nameservercác phần của địa chỉ email. Điều này có thể là quá đơn giản, có thể địa chỉ email có thể có các hình thức khác, nhưng tôi không quan tâm. Tôi chỉ hỏi về hình thức đơn giản này: user-name@server(ví dụ wild.wezyr@best-server-ever.com) và các ký tự được phép trong cả hai phần.


185
Các +được cho phép. Nó khiến tôi phát điên khi các trang web không cho phép vì email của tôi có +trong đó và rất nhiều trang không cho phép.
Dan Herbert

42
Tôi nghĩ điều quan trọng là cung cấp liên kết đến thông số kỹ thuật, vì bạn thực sự muốn hiểu đúng và đó là nơi thông số kỹ thuật xuất hiện. Nếu bạn quá lười để đọc và hiểu thông số kỹ thuật, thì vui lòng để lại kiểm tra các ký tự được phép trong địa chỉ email cho những người quan tâm đến điều đó
jhwist

9
Câu hỏi trước đó bao gồm cùng một tài liệu: stackoverflow.com/questions/760150/ . Điều đáng buồn là, mặc dù câu hỏi đó lớn hơn câu hỏi này gần 8 tháng, nhưng câu hỏi cũ hơn có câu trả lời tốt hơn nhiều. Hầu như tất cả các câu trả lời dưới đây đã hết hạn khi chúng được đăng ban đầu. Xem mục Wikipedia (và đừng lo lắng, nó có tài liệu tham khảo chính thức có liên quan ).
John Y

10
Trái với một số câu trả lời, khoảng trắng được cho phép trong phần cục bộ của địa chỉ email, nếu được trích dẫn. "hello world"@example.comcó giá trị
dùng253751

3
@LaraRuffleColes - Đối với Gmail, khi bạn tạo tài khoản email, nó không cho phép bạn tạo địa chỉ chứa dấu "+". Dấu "+" ("Địa chỉ cộng") cho phép bất kỳ ai có địa chỉ Gmail thêm dấu "+" theo sau là "chuỗi" vào cuối tên người dùng của họ để tạo địa chỉ email "thay thế" ("bí danh") để sử dụng cho tài khoản của họ. Ví dụ: "example @ gmail", "example+tag @ gmail". Một cách sử dụng thông thường (và có thể là "Chính") là có thể tạo địa chỉ email bí danh cho tài khoản của bạn, cho phép bạn gắn thẻ và lọc thư đến, theo lý thuyết được lọc bởi người gửi.
Kevin Fegan

Câu trả lời:


797

Xem RFC 5322: Định dạng thư Internet và ở mức độ thấp hơn, RFC 5321: Giao thức chuyển thư đơn giản .

RFC 822 cũng bao gồm các địa chỉ email, nhưng nó chủ yếu liên quan đến cấu trúc của nó:

 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

Và như thường lệ, Wikipedia có một bài viết khá hay về địa chỉ email :

Phần cục bộ của địa chỉ email có thể sử dụng bất kỳ ký tự ASCII nào sau đây:

  • chữ hoa và chữ thường chữ Latinh Ađến Zađến z;
  • chữ số 0đến 9;
  • nhân vật đặc biệt !#$%&'*+-/=?^_`{|}~;
  • dấu chấm ., với điều kiện đó không phải là ký tự đầu tiên hoặc cuối cùng trừ khi được trích dẫn và cũng được cung cấp rằng nó không xuất hiện liên tiếp trừ khi được trích dẫn (ví dụ: John..Doe@example.comkhông được phép nhưng "John..Doe"@example.comđược phép);
  • không gian và "(),:;<>@[\]ký tự được cho phép với các hạn chế (chúng chỉ được phép bên trong một chuỗi được trích dẫn, như được mô tả trong đoạn dưới đây, và ngoài ra, dấu gạch chéo ngược hoặc trích dẫn kép phải được đặt trước dấu gạch chéo ngược);
  • ý kiến ​​được cho phép với dấu ngoặc đơn ở một trong hai phần của địa phương; ví dụ john.smith(comment)@example.com(comment)john.smith@example.comcả hai đều tương đương với john.smith@example.com.

Ngoài các ký tự ASCII, kể từ năm 2012, bạn có thể sử dụng các ký tự quốc tế ở trênU+007F , được mã hóa dưới dạng UTF-8 như được mô tả trong thông số RFC 6532 và được giải thích trên Wikipedia . Lưu ý rằng kể từ năm 2019, các tiêu chuẩn này vẫn được đánh dấu là Đề xuất, nhưng đang được triển khai chậm. Những thay đổi trong thông số kỹ thuật này về cơ bản đã thêm các ký tự quốc tế dưới dạng các ký tự chữ và số hợp lệ (atext) mà không ảnh hưởng đến các quy tắc về các ký tự đặc biệt được phép và hạn chế như !#@:.

Để xác thực, xem Sử dụng biểu thức chính quy để xác thực địa chỉ email .

Phần domainđược định nghĩa như sau :

Các tiêu chuẩn Internet (Yêu cầu Nhận xét) cho các giao thức bắt buộc các nhãn tên máy chủ thành phần chỉ có thể chứa các chữ cái ASCII athông qua z(theo cách không phân biệt chữ hoa chữ thường), các chữ số 0thông qua 9và dấu gạch nối ( -). Thông số ban đầu của tên máy chủ trong RFC 952 , bắt buộc rằng các nhãn không thể bắt đầu bằng chữ số hoặc dấu gạch nối và không được kết thúc bằng dấu gạch nối. Tuy nhiên, một đặc điểm kỹ thuật tiếp theo ( RFC 1123 ) cho phép nhãn tên máy chủ bắt đầu bằng chữ số. Không có biểu tượng, ký tự dấu chấm câu hoặc khoảng trắng khác được cho phép.


15
@WildWzyr, nó không đơn giản. Địa chỉ email có rất nhiều quy tắc cho những gì được phép. Nói đến thông số kỹ thuật đơn giản hơn là liệt kê ra tất cả chúng. Nếu bạn muốn có Regex hoàn chỉnh, hãy kiểm tra tại đây để có ý tưởng về lý do tại sao nó không đơn giản: chính quy-expressions.info / email.html
Dan Herbert

6
không có danh sách đơn giản, chỉ vì bạn muốn một cái gì đó đơn giản không có nghĩa là nó sẽ như vậy. một số nhân vật chỉ có thể ở một số địa điểm nhất định chứ không phải ở những nơi khác. bạn không thể có những gì bạn muốn mọi lúc.

15
@Wildwezyr Vâng, ký tự toàn bộ được phép ở phần cục bộ. Nhưng không phải lúc bắt đầu hay kết thúc. Hoặc với một điểm dừng hoàn toàn khác. Vì vậy, câu trả lời KHÔNG đơn giản chỉ là một danh sách các ký tự được phép, có các quy tắc về cách sử dụng các ký tự đó - .ann..other.@example.comkhông phải là một địa chỉ email hợp lệ, nhưng ann.other@example.com, mặc dù cả hai đều sử dụng cùng một ký tự.
Đánh dấu Pim

14
Ngoài ra, hãy nhớ rằng với các tên miền được quốc tế hóa, danh sách các ký tự được phép sẽ phát nổ.
Chinmay Kanchi

50
Đây không còn là câu trả lời hợp lệ, do các địa chỉ quốc tế hóa. Xem câu trả lời của Mason.
ZacharyP

329

Coi chừng! Có một loạt các kiến ​​thức bị thối trong chủ đề này (thứ từng là sự thật và bây giờ thì không).

Để tránh sự từ chối dương tính của các địa chỉ email thực tế trong thế giới hiện tại và tương lai và từ bất cứ nơi nào trên thế giới, bạn cần biết ít nhất khái niệm cấp cao về RFC 3490 , "Quốc tế hóa tên miền trong ứng dụng (IDNA)". Tôi biết mọi người ở Mỹ và A thường không quan tâm đến vấn đề này, nhưng nó đã được sử dụng rộng rãi và đang gia tăng nhanh chóng trên khắp thế giới (chủ yếu là các phần không phải tiếng Anh).

Ý chính là bây giờ bạn có thể sử dụng các địa chỉ như mason @ 日本 .com và wildwezyr@fahrvergnügen.net. Không, điều này chưa tương thích với mọi thứ ngoài kia (như nhiều người đã than thở ở trên, thậm chí các địa chỉ nhận dạng qmail đơn giản + thường bị từ chối sai). Nhưng có một RFC, có một thông số kỹ thuật, hiện được IETF và ICANN hỗ trợ, và - quan trọng hơn - có một số lượng lớn các triển khai hỗ trợ cho cải tiến này hiện đang phục vụ.

Bản thân tôi không biết nhiều về sự phát triển này cho đến khi tôi quay trở lại Nhật Bản và bắt đầu thấy các địa chỉ email như hei @ .ca và các URL của Amazon như thế này:

http://www.amazon.co.jp/ エ レ ク ロ ニ ク - デ ジ ル メ - オ ィ オ / b / ref = topnav_storetab_e =

Tôi biết bạn không muốn liên kết đến thông số kỹ thuật, nhưng nếu bạn chỉ dựa vào kiến ​​thức đã lỗi thời của các tin tặc trên các diễn đàn Internet, trình xác thực email của bạn sẽ từ chối các địa chỉ email mà người dùng không nói tiếng Anh ngày càng mong muốn làm việc. Đối với những người dùng đó, việc xác thực như vậy sẽ gây khó chịu như hình thức chết não phổ biến mà tất cả chúng ta đều ghét, một dạng không thể xử lý tên miền + hoặc ba phần hoặc bất cứ điều gì.

Vì vậy, tôi không nói rằng đó không phải là một rắc rối, nhưng danh sách đầy đủ các ký tự "được phép trong một số / bất kỳ / không có điều kiện" là (gần như) tất cả các ký tự trong tất cả các ngôn ngữ. Nếu bạn muốn "chấp nhận tất cả các địa chỉ email hợp lệ (và nhiều địa chỉ email không hợp lệ)" thì bạn phải đưa IDN vào tài khoản, điều này về cơ bản làm cho cách tiếp cận dựa trên ký tự trở nên vô dụng (trừ khi bạn chuyển đổi địa chỉ email quốc tế thành Punycode .

Sau khi làm điều đó bạn có thể làm theo (hầu hết) các lời khuyên ở trên.


17
Đúng; đằng sau hậu trường, tên miền vẫn chỉ là ASCII. Nhưng, nếu ứng dụng web hoặc biểu mẫu của bạn chấp nhận đầu vào do người dùng nhập, thì ứng dụng đó cần thực hiện cùng một công việc mà trình duyệt web hoặc ứng dụng thư khách thực hiện khi người dùng nhập tên máy chủ IDN: để chuyển đổi đầu vào của người dùng thành dạng tương thích DNS. Sau đó xác nhận. Nếu không, các địa chỉ email quốc tế này sẽ không vượt qua xác nhận của bạn. (Chuyển đổi như một trong những tôi liên kết với chỉ sửa đổi các ký tự ASCII chúng được đưa ra, vì vậy nó là an toàn để sử dụng chúng trên các địa chỉ email không phải quốc tế hóa (những người đang vừa trở về chưa sửa đổi).)
Mason

2
Đối với các nhà phát triển Javascript , tôi hiện đang nghiên cứu các phương pháp để thực hiện việc này và Punycode.js dường như là giải pháp hoàn thiện và hoàn hảo nhất.
wwaawaw

5
Lưu ý rằng Email quốc tế hóa (như được xác định hiện tại) không chuyển đổi các địa chỉ không phải ASCII bằng cách sử dụng Punycode hoặc tương tự, thay vào đó mở rộng các phần lớn của chính giao thức SMTP để sử dụng UTF8.
IMSoP

2
Tôi có thiếu điều gì không hay điều này không trả lời được câu hỏi? Tôi đang đọc 'câu trả lời khác là sai, bạn cần chấp nhận nhiều ký tự hơn' nhưng sau đó không nói rõ thêm ký tự nào. Tôi cũng không thể (dễ dàng) thấy trong RFC đó liệu nó có nghĩa là tất cả các điểm mã Unicode hay chỉ BMP.
Samuel Harmer

3
Điều này dường như đang đi đúng hướng để là câu trả lời chính xác. Tôi cá là nó sẽ nhận được nhiều phiếu hơn nếu bạn đưa vào chi tiết cụ thể về các nhân vật được bảo lưu và được phép.
Sean

59

Định dạng của địa chỉ email là: local-part@domain-part(tối đa 64 @ 255 ký tự, không có tổng cộng 256).

Các local-partdomain-partcó thể có bộ khác nhau của các nhân vật được phép, nhưng đó không phải là tất cả, như có nhiều quy tắc để nó.

Nói chung, phần cục bộ có thể có các ký tự ASCII này:

  • chữ thường chữ Latinh: abcdefghijklmnopqrstuvwxyz,
  • chữ hoa chữ Latinh: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • chữ số: 0123456789,
  • ký tự đặc biệt: !#$%&'*+-/=?^_`{|}~,
  • dấu chấm: .(không phải ký tự đầu tiên hoặc cuối cùng hoặc lặp lại trừ khi được trích dẫn),
  • dấu chấm câu như: "(),:;<>@[\](với một số hạn chế),
  • ý kiến: ()(được cho phép trong ngoặc đơn, ví dụ (comment)john.smith@example.com).

Phần tên miền:

  • chữ thường chữ Latinh: abcdefghijklmnopqrstuvwxyz,
  • chữ hoa chữ Latinh: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • chữ số: 0123456789,
  • dấu gạch nối: -(không phải ký tự đầu tiên hoặc cuối cùng),
  • có thể chứa địa chỉ IP được bao quanh bởi dấu ngoặc vuông: jsmith@[192.168.2.1]hoặc jsmith@[IPv6:2001:db8::1].

Các địa chỉ email này là hợp lệ:

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com (một phần địa phương)
  • "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 (tên miền cục bộ không có tên miền cấp cao nhất)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org (khoảng trắng giữa các trích dẫn)
  • example@localhost (được gửi từ localhost)
  • example@s.solutions(xem Danh sách các tên miền cấp cao nhất trên Internet )
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

Và những ví dụ không hợp lệ:

  • Abc.example.com(không có @nhân vật)
  • A@b@c@example.com(chỉ một @được phép bên ngoài dấu ngoặc kép)
  • a"b(c)d,e:f;gi[j\k]l@example.com (không có ký tự đặc biệt nào trong phần cục bộ này được phép bên ngoài dấu ngoặc kép)
  • just"not"right@example.com (các chuỗi được trích dẫn phải được phân tách bằng dấu chấm hoặc phần tử duy nhất tạo thành phần cục bộ)
  • this is"not\allowed@example.com (dấu cách, dấu ngoặc kép và dấu gạch chéo ngược chỉ có thể tồn tại khi nằm trong chuỗi được trích dẫn và trước dấu gạch chéo ngược)
  • this\ still\"not\allowed@example.com (ngay cả khi đã thoát (trước dấu gạch chéo ngược), dấu cách, dấu ngoặc kép và dấu gạch chéo ngược vẫn phải được chứa trong dấu ngoặc kép)
  • john..doe@example.com(dấu chấm kép trước @); (với cảnh báo: Gmail cho phép điều này thông qua)
  • john.doe@example..com(dấu chấm kép sau @)
  • một địa chỉ hợp lệ với một không gian hàng đầu
  • một địa chỉ hợp lệ với dấu cách

Nguồn: Địa chỉ email tại Wikipedia


Regex RFC2822 của Perl để xác thực email:

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

Giá trị regex đầy đủ cho các địa chỉ RFC2822 chỉ là 3,7k.

Xem thêm: Trình phân tích địa chỉ email RFC 822 trong PHP .


Các định nghĩa chính thức của địa chỉ email là trong:

  • RFC 5322 (phần 3.2.3 và 3.4.1, lỗi thời RFC 2822), RFC 5321, RFC 3696,
  • RFC 6531 (ký tự được phép).

Liên quan:


5
Một sự thận trọng hơn nữa đối với những người thực hiện regex này: Đừng. Chỉ cần xác minh rằng nó có định dạng something@something.somethingvà gọi nó là một ngày.
Chris Sobolewski

Mặc dù những thứ như thế này không thể duy trì được, nhưng đây là một bài tập hay để giải mã và thực sự tìm ra những gì nó làm
đánh giá

@ChrisSobolewski cho phép nhiều lần cả hai mặt của '@'
Jasen

Tôi đã cố gắng thực hiện điều này trong postfix thông qua bảng truy cập pcre theo một hạn chế check_recipient_access, trước tiên biến 3 pcres dài (từ trang được liên kết) thành một dòng mỗi dòng và đứng đầu và theo đuôi như sau: / ^ [... pcre ..] $ / DUNNO, sau đó thêm một dòng cuối cùng /.*/ DỰ ÁN, nhưng nó vẫn cho phép thông qua các địa chỉ email không hợp lệ. Hậu tố 3.3.0; perl 5, phiên bản 26, lật đổ 1 (v5.26.1).
scoobydoo

3
Tôi nói điên rồi. Ai sẽ sử dụng nó trong sản xuất. Có một điểm mà biểu thức chính quy không còn được sử dụng. Nó vượt xa điểm đó.
tomuxmon

22

Wikipedia có một bài viết hay về điều này , và thông số chính thức ở đây . Từ Wikipdia:

Phần cục bộ của địa chỉ email có thể sử dụng bất kỳ ký tự ASCII nào sau đây:

  • Chữ in hoa và chữ thường viết hoa (az, AZ)
  • Chữ số 0 đến 9
  • Nhân vật ! # $% & '* + - / =? ^ _ `{| } ~
  • Tính cách . (dấu chấm, dấu chấm, dấu chấm hết) với điều kiện đó không phải là ký tự đầu tiên hoặc cuối cùng và cũng cung cấp rằng nó không xuất hiện hai hoặc nhiều lần liên tiếp.

Ngoài ra, các chuỗi trích dẫn (ví dụ: "John Doe" @ example.com) được cho phép, do đó cho phép các ký tự có thể bị cấm, tuy nhiên chúng không xuất hiện trong thực tế chung. RFC 5321 cũng cảnh báo rằng "một máy chủ dự kiến ​​sẽ nhận thư NÊN tránh xác định hộp thư trong đó Phần cục bộ yêu cầu (hoặc sử dụng) dạng chuỗi trích dẫn".


@Wildwezyr Tên máy chủ hợp lệ, có thể là địa chỉ IP, FQN hoặc một cái gì đó có thể phân giải được với máy chủ mạng cục bộ.
JensenDied

Chuỗi trích dẫn là rất cần thiết để đi qua một cổng, nhớ Banyan Vines?
mckenzm

13

Google làm một điều thú vị với địa chỉ gmail.com của họ. địa chỉ gmail.com chỉ cho phép các chữ cái (az), số và dấu chấm (được bỏ qua).

ví dụ: pikachu @ gmail giống như pi.kachu @ gmail và cả hai địa chỉ email sẽ được gửi đến cùng một hộp thư. PIKACHU @ gmail cũng được gửi đến cùng một hộp thư.

Vì vậy, để trả lời câu hỏi, đôi khi nó phụ thuộc vào người thực hiện về mức độ tiêu chuẩn RFC mà họ muốn tuân theo. Kiểu địa chỉ gmail của Google tương thích với các tiêu chuẩn. Họ làm theo cách đó để tránh nhầm lẫn nơi những người khác nhau sẽ lấy địa chỉ email tương tự, ví dụ:

*** 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)

Liên kết wikipedia là một tài liệu tham khảo tốt về những gì địa chỉ email thường cho phép. http://en.wikipedia.org/wiki/Email_address


2
Phải, đây là một câu trả lời tuyệt vời về lý do tại sao Gmail không cho phép TẠO email với điều này. Nhưng bạn có thể gửi và nhận email {john'doe}@my.servermà không có vấn đề gì. Đã thử nghiệm với máy chủ hMail.
Piotr Kula

Bạn có thể kiểm tra khách hàng của mình bằng cách gửi email đến {piotr'kula}@kula.solutions- Nếu nó hoạt động, bạn sẽ nhận được một mẫu trả lời tự động đẹp. Nếu không sẽ không có gì xảy ra.
Piotr Kula

3
Gmail tuân theo RFC 6530 theo nghĩa là mọi địa chỉ email có thể được Gmail cho phép đều hợp lệ theo RFC. Gmail chỉ chọn giới hạn hơn nữa tập hợp các địa chỉ được phép với các quy tắc bổ sung và để tạo các địa chỉ tương tự khác có dấu chấm ở phần cục bộ, theo sau là "+" và các ký tự chữ và số, đồng nghĩa.
Teemu Leisti

Google giới hạn các tiêu chí tạo tài khoản ... Tôi tưởng tượng họ sẽ xóa chuỗi tài khoản email đến của "dấu chấm câu" bổ sung và dấu cộng với dấu chuỗi bí danh được chuẩn bị trước để thư có thể được chuyển đến tài khoản thích hợp. Dễ như ăn bánh. Khi làm như vậy, họ thực sự không cho phép mọi người tạo các địa chỉ email đơn giản để các địa chỉ hợp lệ được tạo thường sẽ vượt qua các xác nhận đơn giản và phức tạp nhất.
BradChesney79

Không chỉ là gmail, Một số nhà cung cấp có "bộ lọc chuyển tiếp" từ chối các chuỗi được trích dẫn nhất định, đặc biệt có chứa "=" như thể chúng là các dấu phân cách. Điều này là để chặn người dùng thiết lập các cổng và lồng các địa chỉ spam trong chuỗi trích dẫn riêng. "@" là hợp lệ nhưng "= @ =" không (được coi là) hợp lệ.
mckenzm

12

Bạn có thể bắt đầu từ bài viết trên wikipedia :

  • Chữ in hoa và chữ thường viết hoa (az, AZ)
  • Chữ số 0 đến 9
  • Nhân vật ! # $% & '* + - / =? ^ _ `{| } ~
  • Tính cách . (dấu chấm, dấu chấm, dấu chấm hết) với điều kiện đó không phải là ký tự đầu tiên hoặc cuối cùng và cũng cung cấp rằng nó không xuất hiện hai hoặc nhiều lần liên tiếp.

11

Tên:

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

Người phục vụ:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

4
Còn về <>[]? Ví dụ: "()<>[]:,;@\\\"!#$%&'-/=?^_{} | ~ .a "@ example.org`?
kenorb

20
Xin trích dẫn nguồn. Không có nguồn, điều này trông giống như phỏng đoán.
Mathieu K.

15
Điều này đã lỗi thời và có thể không bao giờ chính xác.
Jason Harrison

9

Kiểm tra @ và. và sau đó gửi email cho họ để xác minh.

Tôi vẫn không thể sử dụng địa chỉ email .name của mình trên 20% các trang web trên internet vì ai đó đã làm sai xác thực email của họ hoặc do địa chỉ mới này có hiệu lực.


9
Cũng . không thực sự cần thiết; Tôi đã nghe nói về ít nhất một trường hợp địa chỉ email ở một tên miền cấp cao nhất (cụ thể là ua). Địa chỉ là <name> @ua - không có dấu chấm!

Đây là cách dễ nhất để không làm hỏng xác nhận của bạn, vì hầu hết mọi thứ đều được cho phép và nếu điều gì đó không được phép, máy chủ của người nhận sẽ cho bạn biết.
Avamander

5

Câu trả lời ngắn gọn là có 2 câu trả lời. Có một tiêu chuẩn cho những gì bạn nên làm. tức là hành vi khôn ngoan và sẽ giúp bạn thoát khỏi rắc rối. Có một tiêu chuẩn khác (rộng hơn nhiều) cho hành vi bạn nên chấp nhận mà không gây rắc rối. Tính hai mặt này hoạt động để gửi và chấp nhận email nhưng có ứng dụng rộng rãi trong cuộc sống.

Đối với một hướng dẫn tốt cho các địa chỉ bạn tạo ra; xem: http://www.remote.org/jochen/mail/info/chars.html

Để lọc các email hợp lệ, chỉ cần chuyển bất kỳ thứ gì đủ dễ hiểu để xem bước tiếp theo. Hoặc bắt đầu đọc một loạt các RFC, thận trọng, ở đây là những con rồng.


Các liên kết đã biến mất. Nội dung gì ở đó?
ygoe

5

Một đọc tốt về vấn đề này .

Trích đoạn:

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

1
Tôi đã tự hỏi về '@' trước phần tên miền. Điều đó có thể được sử dụng?
Saiyaff Farouk

@SaiyaffFarouk theo đặc điểm kỹ thuật, có. Tuy nhiên, hầu hết các nhà cung cấp thư có thể sẽ không cho phép nó như một phần xác thực của chính họ
Luke Madhanga

danh sách blog Joe.\\Blow@example.commà không có dấu ngoặc kép. Điều này có thực sự hợp lệ không? Có vẻ như không rõ ràng khi đưa ra câu trả lời ở đây, nhưng tôi đang hỏi bởi vì tôi đã thấy (rất hiếm) các trường hợp chuỗi email DNS SoA có chứa dấu gạch chéo ngược.
wesinat0r

5

Câu trả lời được chấp nhận đề cập đến một bài viết Wikipedia khi thảo luận về phần cục bộ hợp lệ của một địa chỉ email, nhưng Wikipedia không phải là cơ quan có thẩm quyền về vấn đề này.

IETF RFC 3696 là cơ quan có thẩm quyền về vấn đề này và nên được tư vấn ở phần 3. Hạn chế về địa chỉ email trên trang 5:

Địa chỉ email hiện đại bao gồm "phần cục bộ" được phân tách từ "phần miền" (tên miền đủ điều kiện) bằng ký hiệu ("@"). Cú pháp của phần miền tương ứng với phần đó trong phần trước. Những mối quan tâm được xác định trong phần đó về lọc và danh sách tên cũng áp dụng cho tên miền được sử dụng trong ngữ cảnh email. Tên miền cũng có thể được thay thế bằng một địa chỉ IP trong ngoặc vuông, nhưng hình thức đó không được khuyến khích mạnh mẽ ngoại trừ mục đích kiểm tra và khắc phục sự cố.

Phần cục bộ có thể xuất hiện bằng cách sử dụng các quy ước trích dẫn được mô tả dưới đây. Các hình thức trích dẫn hiếm khi được sử dụng trong thực tế, nhưng được yêu cầu cho một số mục đích hợp pháp. Do đó, chúng không nên bị từ chối trong các thói quen lọc mà thay vào đó, nên được chuyển đến hệ thống email để đánh giá bởi máy chủ đích.

Quy tắc chính xác là mọi ký tự ASCII, bao gồm các ký tự điều khiển, có thể xuất hiện được trích dẫn hoặc trong một chuỗi được trích dẫn. Khi trích dẫn là cần thiết, ký tự dấu gạch chéo ngược được sử dụng để trích dẫn ký tự sau. Ví dụ

  Abc\@def@example.com

là một hình thức hợp lệ của một địa chỉ email. Không gian trống cũng có thể xuất hiện, như trong

  Fred\ Bloggs@example.com

Ký tự dấu gạch chéo ngược cũng có thể được sử dụng để trích dẫn chính nó, ví dụ:

  Joe.\\Blow@example.com

Ngoài việc trích dẫn bằng cách sử dụng ký tự dấu gạch chéo ngược, các ký tự trích dẫn kép thông thường có thể được sử dụng để bao quanh chuỗi. Ví dụ

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

là các hình thức thay thế của hai ví dụ đầu tiên ở trên. Các hình thức trích dẫn này hiếm khi được đề xuất và không phổ biến trong thực tế, nhưng, như đã thảo luận ở trên, phải được hỗ trợ bởi các ứng dụng đang xử lý địa chỉ email. Cụ thể, các biểu mẫu được trích dẫn thường xuất hiện trong bối cảnh các địa chỉ liên quan đến chuyển tiếp từ các hệ thống và bối cảnh khác; những yêu cầu chuyển tiếp đó vẫn phát sinh và, vì một hệ thống chấp nhận địa chỉ email do người dùng cung cấp không thể "biết" liệu địa chỉ đó có được liên kết với hệ thống cũ hay không, các mẫu địa chỉ phải được chấp nhận và chuyển vào môi trường email.

Không có dấu ngoặc kép, các phần cục bộ có thể bao gồm bất kỳ sự kết hợp nào của các
ký tự chữ cái, chữ số hoặc bất kỳ ký tự đặc biệt nào

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

dấu chấm (".") cũng có thể xuất hiện, nhưng có thể không được sử dụng để bắt đầu hoặc kết thúc phần cục bộ, cũng không thể xuất hiện hai hoặc nhiều khoảng thời gian liên tiếp. Nói cách khác, mọi ký tự (in) đồ họa ASCII khác với ký hiệu ("@"), dấu gạch chéo ngược, dấu ngoặc kép, dấu phẩy hoặc dấu ngoặc vuông có thể xuất hiện mà không cần trích dẫn. Nếu bất kỳ danh sách các ký tự loại trừ nào xuất hiện, chúng phải được trích dẫn. Các hình thức như

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

là hợp lệ và được nhìn thấy khá thường xuyên, nhưng bất kỳ ký tự nào được liệt kê ở trên đều được cho phép.

Như những người khác đã làm, tôi gửi một biểu thức chính quy hoạt động cho cả PHP và JavaScript để xác thực địa chỉ email:

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

3

Như có thể tìm thấy trong liên kết Wikipedia này

Phần cục bộ của địa chỉ email có thể sử dụng bất kỳ ký tự ASCII nào sau đây:

  • chữ hoa và chữ thường chữ Latinh Ađến Zađến z;

  • chữ số 0đến 9;

  • nhân vật đặc biệt !#$%&'*+-/=?^_`{|}~;

  • dấu chấm ., với điều kiện đó không phải là ký tự đầu tiên hoặc cuối cùng trừ khi được trích dẫn và cũng được cung cấp rằng nó không xuất hiện liên tiếp trừ khi được trích dẫn (ví dụ: John..Doe@example.comkhông được phép nhưng "John..Doe"@example.comđược phép);

  • không gian và "(),:;<>@[\]ký tự được cho phép với các hạn chế (chúng chỉ được phép bên trong một chuỗi được trích dẫn, như được mô tả trong đoạn dưới đây, và ngoài ra, dấu gạch chéo ngược hoặc trích dẫn kép phải được đặt trước dấu gạch chéo ngược);

  • ý kiến ​​được cho phép với dấu ngoặc đơn ở một trong hai phần của địa phương; ví dụ john.smith(comment)@example.com(comment)john.smith@example.comcả hai đều tương đương với john.smith@example.com.

Ngoài các ký tự ASCII ở trên, các ký tự quốc tế trên U + 007F, được mã hóa dưới dạng UTF-8, được RFC 6531 cho phép , mặc dù các hệ thống thư có thể hạn chế sử dụng các ký tự nào khi gán các phần cục bộ.

Một chuỗi được trích dẫn có thể tồn tại dưới dạng một thực thể được phân tách bằng dấu chấm trong phần cục bộ hoặc nó có thể tồn tại khi các trích dẫn ngoài cùng là các ký tự ngoài cùng của phần cục bộ (ví dụ: abc."defghi".xyz@example.comhoặc "abcdefghixyz"@example.comđược cho phép. Ngược lại, abc"defghi"xyz@example.comkhông phải vậy abc\"def\"ghi@example.com). Chuỗi trích dẫn và ký tự, tuy nhiên, không được sử dụng phổ biến. RFC 5321 cũng cảnh báo rằng "một máy chủ dự kiến ​​sẽ nhận thư NÊN tránh xác định hộp thư trong đó Phần cục bộ yêu cầu (hoặc sử dụng) dạng chuỗi trích dẫn".

Phần cục bộ postmasterđược xử lý đặc biệt, nó không phân biệt chữ hoa chữ thường và nên được chuyển tiếp đến người quản trị email tên miền. Về mặt kỹ thuật, tất cả các bộ phận cục bộ khác đều phân biệt chữ hoa chữ thường, do đó jsmith@example.comJSmith@example.comchỉ định các hộp thư khác nhau; tuy nhiên, nhiều tổ chức coi chữ hoa và chữ thường là tương đương.

Mặc dù có nhiều loại ký tự đặc biệt có giá trị về mặt kỹ thuật; các tổ chức, dịch vụ thư, máy chủ thư và khách hàng thư trong thực tế thường không chấp nhận tất cả chúng. Ví dụ: Windows Live Hotmail chỉ cho phép tạo địa chỉ email bằng cách sử dụng chữ và số, dấu chấm ( .), dấu gạch dưới ( _) và dấu gạch nối ( -). Lời khuyên phổ biến là tránh sử dụng một số ký tự đặc biệt để tránh nguy cơ email bị từ chối.


0

Câu trả lời là (gần như) ALL(ASCII 7 bit).
Nếu quy tắc bao gồm là "... được cho phép theo một số / bất kỳ / không có điều kiện ..."

Chỉ cần xem một trong một số quy tắc bao gồm có thể có đối với văn bản được phép trong phần "văn bản tên miền" trong RFC 5322 ở đầu trang 17, chúng tôi thấy:

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

ba ký tự bị thiếu duy nhất trong mô tả này được sử dụng theo tên miền [], để tạo thành một cặp được trích dẫn \và ký tự khoảng trắng (% d32). Với điều đó, toàn bộ phạm vi 32-126 (thập phân) được sử dụng. Một yêu cầu tương tự xuất hiện là "qtext" và "ctext". Nhiều ký tự điều khiển cũng được cho phép / sử dụng. Một danh sách các ký tự điều khiển như vậy xuất hiện trong trang 31, phần 4.1 của RFC 5322 dưới dạng 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

Tất cả các ký tự điều khiển này được cho phép như đã nêu ở đầu phần 3.5:

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

Và một quy tắc bao gồm như vậy là "quá rộng". Hay nói cách khác, quy tắc dự kiến ​​là "quá đơn giản".


0

Để đơn giản, tôi vệ sinh việc gửi bằng cách xóa tất cả văn bản trong dấu ngoặc kép và những dấu ngoặc kép liên quan xung quanh trước khi xác thực, đặt kibosh vào việc gửi địa chỉ email dựa trên nội dung không được phép. Chỉ vì ai đó có thể có John .. "The * $ hizzle * Bizzle" .. Địa chỉ Doe@whthing.com không có nghĩa là tôi phải cho phép nó trong hệ thống của mình. Chúng ta đang sống trong tương lai, nơi có thể mất ít thời gian hơn để có được một địa chỉ email miễn phí hơn là làm tốt công việc lau mông của bạn. Và không phải là nếu tiêu chí email không được dán ngay bên cạnh đầu vào cho biết những gì được và không được phép.

Tôi cũng vệ sinh những gì đặc biệt không được phép bởi các RFC khác nhau sau khi tài liệu được trích dẫn bị xóa. Danh sách các ký tự và mẫu đặc biệt không được phép dường như là một danh sách ngắn hơn nhiều để kiểm tra.

Không được phép

    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 )

Trong ví dụ đã cho:

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

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

Gửi một email xác nhận đến kết quả còn sót lại khi cố gắng thêm hoặc thay đổi địa chỉ email là một cách tốt để xem mã của bạn có thể xử lý địa chỉ email được gửi hay không. Nếu email vượt qua xác nhận sau bao nhiêu vòng vệ sinh nếu cần, thì hãy hủy xác nhận đó. Nếu một yêu cầu quay trở lại từ liên kết xác nhận, thì email mới có thể được chuyển từ trạng thái giữ | | tạm thời | | trạng thái luyện ngục để trở thành một email lưu trữ hạng nhất thực sự, có bonafide.

Một thông báo về sự thay đổi địa chỉ email thất bại hoặc thành công có thể được gửi đến địa chỉ email cũ nếu bạn muốn được quan tâm. Thiết lập tài khoản chưa được xác nhận có thể rơi ra khỏi hệ thống do các lần thử thất bại hoàn toàn sau một khoảng thời gian hợp lý.

Tôi không cho phép các email hôi thối trên hệ thống của mình, có lẽ đó chỉ là vứt tiền. Tuy nhiên, 99,9% thời gian mọi người chỉ cần làm đúng và có một email không đẩy các giới hạn tuân thủ đến bờ vực sử dụng các kịch bản tương thích trường hợp cạnh. Hãy cẩn thận với regex DDoS, đây là nơi mà bạn có thể gặp rắc rối. Và điều này có liên quan đến điều thứ ba tôi làm, tôi đặt giới hạn về thời gian tôi sẵn sàng xử lý bất kỳ một email nào. Nếu nó cần làm chậm máy của tôi để được xác nhận - nó sẽ không vượt qua logic điểm cuối API dữ liệu đến của tôi.

Chỉnh sửa: Câu trả lời này tiếp tục bị cho là "xấu", và có lẽ nó xứng đáng với nó. Có lẽ nó vẫn tệ, có thể không.


2
Tôi cho rằng câu trả lời này bị hạ thấp bởi vì đây là một ý kiến ​​và nó thực sự không trả lời câu hỏi. Bên cạnh đó, người dùng nhận được địa chỉ email âm thầm được vệ sinh sẽ không bao giờ nhận được email từ bạn. Bạn nên thông báo cho họ rằng địa chỉ email của họ không được chấp nhận.
vcarel

2
Tôi nghi ngờ các downvote là bởi vì có quá nhiều ý tưởng ở đây. Danh sách không được phép, trong khi đây là các thử nghiệm đơn vị hữu ích, nên được mở đầu bằng những gì được phép. Phương pháp lập trình có vẻ tương đối tốt, nhưng, có lẽ sẽ phù hợp hơn sau khi bạn liệt kê các thông số kỹ thuật bạn đang làm việc, v.v. Các phần và chỉnh sửa sao chép nhẹ sẽ giúp ích. Chỉ cần 2cents của tôi.
Hold OfferHunger

@vcarel - Ồ, hoàn toàn. Xác thực phía người dùng phía trước sẽ thông báo cho họ những quy tắc nào (có sẵn từ chú giải công cụ) mà họ đã vi phạm. Bạn nói đúng-- đó là một ý kiến ​​tổng thể. Tuy nhiên, câu hỏi trên là từ một người đang hỏi X cho câu hỏi Y chắc chắn. Đây là hướng dẫn và nó hoạt động ... không chỉ hoạt động, nó còn hoạt động tốt. Tôi không để địa chỉ email nhảm nhí trong hệ thống của mình, nơi tôi đưa ra quyết định.
BradChesney79

@Hold OfferHunger Tôi có thể thấy rằng ý tưởng tổng thể không được thể hiện mạch lạc như nó có thể, tôi có thể sửa đổi vào một ngày khác, nơi tôi có nhiều thời gian hơn để diễn đạt tốt hơn. Cảm ơn vì sự sáng suốt.
BradChesney79

-1

Trong PHP của tôi, tôi sử dụng kiểm tra này

<?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";
}
?>

hãy tự mình thử http://phpfiddle.org/main/code/9av6-d10r


-1

Tôi đã tạo regex này theo hướng dẫn của RFC:

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

1
Phiên bản này cải thiện regex bằng cách kiểm tra độ dài của tên miền / tên miền phụ. Thưởng thức! ^ [\\ w \\. \\! _ \\% # \\ $ \\ & \\ '= \\? \ * \\ + \\ - \\ / \\ ^ \ `\\ {\\ | \\} \\ ~] + @ (?: [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])? w] (?: [\\ w \\ -] {0,61} [\\ w])?) *) $
Mậu

-2

Gmail sẽ chỉ cho phép + ký dưới dạng ký tự đặc biệt và trong một số trường hợp (.) Nhưng bất kỳ ký tự đặc biệt nào khác đều không được phép tại Gmail. RFC nói rằng bạn có thể sử dụng các ký tự đặc biệt nhưng bạn nên tránh gửi thư đến Gmail bằng các ký tự đặc biệt.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.