2008-11-18 17 views
16

Có ai có danh sách các địa chỉ email mà tôi có thể sử dụng để kiểm tra tập lệnh xác thực địa chỉ JS của tôi không? Tôi đang tìm kiếm như là một danh sách đầy đủ như là hợp lý để kiểm tra các trường hợp cạnh phổ biến nhất, nếu không phải tất cả các trường hợp.danh sách các địa chỉ email có thể được sử dụng để kiểm tra tập lệnh xác thực javascript

+0

Hãy suy nghĩ bạn nên thực hiện một số. Nó sẽ rất không quan trọng, và có lẽ bất hợp pháp cho bất cứ ai ở đây để cung cấp cho bạn một danh sách những người thực sự – seanb

+1

Tất cả những người có dấu kiểm trong cột kết quả ở đây là địa chỉ hợp lệ: http://isemail.info/_system/is_email/test /? tất cả –

Trả lời

21

Ví dụ hợp lệ theo RFC2822

  • [email protected]
  • [email protected]
  • [email protected]
  • tên \ @ tag @ ví dụ. com - đây là địa chỉ email hợp lệ chứa hai ký hiệu @.
  • không gian \ là \ [email protected]
  • "không gian có thể được trích dẫn" @ example.com
  • # $% & '* + -/=^_ `!.? {|} ~ @ [ 1.0.0.127]
  • ! # $% & '* + -/=.?^_ `{|} ~ @ [IPv6: 0123: 4567: 89AB: CDEF: 0123: 4567: 89AB: CDEF]
  • tôi (đây là một bình luận) @ example.com - những lời nhận xét không được khuyến khích nhưng không bị cấm bởi RFC2822.

Ví dụ hợp lệ theo RFC2822s

  • tôi @
  • @ example.com
  • tôi. @ Example.com
  • .me @ example.com
  • tôi @ dụ ..com
  • [email protected]
  • me \ @ example.com

Từ: http://en.wikibooks.org/wiki/JavaScript/Best_Practices

+4

+1 | name + tag @ example.com là cái mà tôi cố gắng sử dụng mọi lúc (đọc: bộ lọc Gmail) nhưng được phân loại là không hợp lệ đối với mọi trang web đã "cuộn riêng" mà không quan tâm đến RFC2822. Thật tức giận! –

+1

[email protected] hợp lệ. Bài viết wikipedia đề cập sai giải thích RFC2822 trong trường hợp đó. RFC2822 sử dụng biểu mẫu Backus-Naur tăng cường để nói rằng một miền có thể là (trong số những thứ khác) 'nguyên tử * (". "Nguyên tử)' và theo kiểu của Aug.BNF được sử dụng, * có nghĩa là 0 đến vô cùng xuất hiện của bất kỳ thứ gì sau không được chỉ định khác. Do đó, phần '(". "Atom) sau đây là tùy chọn. Và, như me.example là một phần địa phương hợp lệ của email, [email protected] cũng phải được chấp nhận. – binderbound

+1

cũng như sau (yêu cầu hợp lệ) không hợp lệ: 'name \ @ tag @ example'' dấu cách \ được cho phép @ example.com'. Đây là một cách giải thích sai khác của RFC282. Không nơi nào nó nói rằng bạn có thể thoát @ và không gian để có được một email hợp lệ. Trong thực tế, nó đặc biệt nói rằng họ phải được trích dẫn. Nghiêm túc - bạn không thể tin tưởng một cách mù quáng wikipedia, ngay cả ngày nay. Họ không có tài nguyên để kiểm tra nội dung mọi người đăng đúng cách. Họ chỉ kiểm tra xem bạn có nguồn tham khảo hay không, điều đó không đủ tốt. – binderbound

0

Phần miền (sau @ cuối cùng), là một loạt các nhãn chuỗi chia cho một dấu chấm.

Mỗi nhãn là một chuỗi các 1-63 octet gồm A-Z, a-z 0-9 hoặc dấu gạch ngang (-)

Kích thước tối đa của tên miền là 255 octet.

Để tương thích với ARPANET, mỗi nhãn phải bắt đầu bằng chữ cái và kết thúc bằng một ký tự hoặc chữ số nhưng một số TLD: bây giờ s cho phép một tất cả miền số, như 0.nu

Lưu ý rằng các TLD được phép là 63 octet. Rất nhiều kịch bản sai giới hạn nó đến 2-3 octets làm cho domain.name không hợp lệ.

Ví dụ?

abcdefghijklmnopqrstuvwxyz.ABCDEFGHIJKLMNOPQRSTUVWXYZ.! # $% & '+-/=.?^`{|}[email protected]ijklmnopqrstu.vwxyzABCDEFGHIJKLMNOP.QRSTUVWXYZ0.1.2.3.4.5.6.7.8.9.az.AZ. 0-9.a0.b1.c2.d3.e4.f5.g6.h7.i8.j9.K0.L1.M2.N3.O.domain.tên

(và không có, nó không được đăng ký)

Cập nhật: Với IDNA hầu như tất cả mọi thứ thể:

Xem thêm:

https://stackoverflow.com/questions/3232/how-far-should-one-take-e-mail-address-validation

http://www.leshazlewood.com/?p=5

Cập nhật: bobince gợi ý để kiểm tra đối với một dấu chấm trong tên miền.

Tóm tắt: Chỉ kiểm tra @ và dấu chấm trong phần tên miền và sau đó gửi email xác nhận.

Dưới đây là một ví dụ mà kiểm tra cho @ và chấm:

  • Phải có ít nhất một @
  • Phải có ít nhất một char ở phần địa phương (pos> 0)
  • phải có ít nhất một dấu chấm trong phần miền
  • phần
  • Tên miền phải có ít kẻo 4 ký tự

đây là một đơn giản:

function isEmail(address) { 
    var pos = address.lastIndexOf("@"); 
    return pos > 0 && (address.lastIndexOf(".") > pos) && (address.length - pos > 4); 
} 

Hoặc một hàm trả về phần địa phương và miền trong một đối tượng (nếu bạn muốn xử lý nó hơn nữa, ví dụ như chuyển đổi nó sang punycode)

function isEmail(address) { 
    var pos = address.lastIndexOf("@"); 
    return pos > 0 && (address.lastIndexOf(".") > pos) && (address.length - pos > 4) ? 
    { 
     local:address.substr(0,pos < 0 ? 0 : pos), 
     domain:address.substr(pos+1) 
    }: false; 
} 
+0

Thử nghiệm ‘.’ Cũng hữu ích để bắt những người chỉ đặt ‘hotmail’ mà không có TLD. Chúng tôi có thể, tôi nghĩ rằng, một cách an toàn giả định không ai sẽ được điền vào một địa chỉ @ một TLD chính nó. – bobince

+0

Tôi không chắc là nó hợp pháp hay không có địa chỉ tại TLD. Về mặt kỹ thuật, điều đó có thể xảy ra, nhưng tôi không biết về bất kỳ thứ gì có nó. – some

+0

Không quan tâm: @Dominc_Sayers đã nhận xét về trang được liên kết của anh ấy * "Hôm nay tôi đã tìm thấy ai đó có địa chỉ email đang hoạt động ở Miền cấp cao nhất. Nói cách khác là địa chỉ email không có dấu chấm trong phần tên miền. [...] một địa chỉ tại TLD Ukraina .ua "* http://isemail.info/_system/is_email/test/?all – ptim

9

bây giờ tôi đã đối chiếu kiểm tra các trường hợp từ Cal Henderson, Dave Child, Phil Haack, Doug Lovell và RFC 3696. 164 test addresses in all.

Tôi đã chạy tất cả các thử nghiệm này với tất cả các trình xác thực mà tôi có thể tìm thấy. So sánh ở đây: http://www.dominicsayers.com/isemail

Tôi sẽ cố gắng cập nhật trang này khi mọi người nâng cao trình xác thực của họ. Cảm ơn Cal, Dave và Phil đã giúp đỡ và hợp tác trong việc biên soạn các thử nghiệm này và những lời chỉ trích mang tính xây dựng của my own validator.

Mọi người nên biết về số errata against RFC 3696 nói riêng. Ba trong số các ví dụ kinh điển thực tế là địa chỉ không hợp lệ. Và độ dài tối đa của một địa chỉ là 254 hoặc 256 ký tự, không phải 320.

Các vấn đề liên quan