Cách xác thực địa chỉ email trong JavaScript


4376

Có một biểu thức chính quy để xác thực một địa chỉ email trong JavaScript không?



60
xin vui lòng, điều này đúng, quá nhiều trang web không thích địa chỉ email của tôi là "FirstName@secondName.name", không phải tất cả các tên miền cấp cao đều kết thúc 2 hoặc 3 chữ cái.
Ian Ringrose

41
Bất kỳ hỗ trợ nào cho việc sử dụng kiểm tra regex cho e-mail tôi đều chống lại 100%. Tôi mệt mỏi khi được thông báo địa chỉ e-mail "foo+bar @ gmail" của tôi là không hợp lệ. Tùy chọn tốt nhất là yêu cầu người dùng nhập e-mail của họ hai lần và nếu bạn PHẢI sử dụng trình kiểm tra regex, sau đó cho người dùng biết rằng địa chỉ e-mail của họ có vẻ không hợp lệ và hỏi họ có chắc họ đã gõ không đúng. Thậm chí còn đi xa hơn để chỉ ra CÁI GÌ không kiểm tra trong kiểm tra regrec, nhưng KHÔNG ngăn họ gửi biểu mẫu.
Soundfx4 15/03/2016

17
@ Soundfx4: đây phải là câu trả lời và được chấp nhận như vậy. Kiểm tra tính chính xác của một địa chỉ là một việc ngu ngốc phải làm - cách tốt nhất để khiến khách hàng nản lòng. Tôi yêu cầu địa chỉ được nhập hai lần và gợi ý rằng có một số vấn đề có thể xảy ra (thiếu @, ;comv.v.) và để người dùng sửa chúng nếu họ muốn (và chấp nhận bất cứ điều gì họ gửi cho tôi)
WoJ

4
Tôi hoàn toàn đồng ý với câu trả lời được đưa ra bởi WoJ. Định dạng của một địa chỉ email hợp lệ là quá phức tạp để được kiểm tra với một biểu thức chính quy đơn giản. Cách duy nhất để chắc chắn rằng địa chỉ hợp lệ là dùng thử.
Nicole

Câu trả lời:


4943

Sử dụng các biểu thức thông thường có lẽ là cách tốt nhất. Bạn có thể thấy một loạt các bài kiểm tra ở đây (lấy từ crom )

function validateEmail(email) {
    const re = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
    return re.test(String(email).toLowerCase());
}

Đây là ví dụ về expresion thường xuyên chấp nhận unicode:

const re = /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})$/i;

Nhưng hãy nhớ rằng người ta không nên chỉ dựa vào xác thực JavaScript. JavaScript có thể dễ dàng bị vô hiệu hóa. Điều này cũng nên được xác nhận ở phía máy chủ.

Đây là một ví dụ về hành động trên:

function validateEmail(email) {
  const re = /^(([^<>()[\]\\.,;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
  return re.test(email);
}

function validate() {
  const $result = $("#result");
  const email = $("#email").val();
  $result.text("");

  if (validateEmail(email)) {
    $result.text(email + " is valid :)");
    $result.css("color", "green");
  } else {
    $result.text(email + " is not valid :(");
    $result.css("color", "red");
  }
  return false;
}

$("#validate").on("click", validate);
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

<form>
  <p>Enter an email address:</p>
  <input id='email'>
  <button type='submit' id='validate'>Validate!</button>
</form>

<h2 id='result'></h2>


575
Regex này loại bỏ các email đang sử dụng hợp lệ. Không được dùng. Google cho "RFC822" hoặc "RFC2822" để có được một biểu thức chính quy phù hợp.
Randal Schwartz

42
Điều này thậm chí không chấp nhận các ví dụ trong RFC 822. Một số trường hợp đơn giản không phù hợp với \ @ b @ c.com, a(b)@c.com. Xem RFC để biết thêm. Đây là một regex sẽ không từ chối bất kỳ địa chỉ hợp lệ nào [^ @] + @ [^ @] + \. [^ @] + Và bảo vệ chống lại các lỗi phổ biến.
Vroo

126
@ GoodPerson Tôi chỉ cố gắng gửi email cho n @ ai để nói với anh ấy / cô ấy rằng họ có một địa chỉ email thú vị. Nhưng than ôi, gmail sẽ không cho phép tôi. Tôi nghi ngờ bất cứ ai gặp vấn đề lớn hơn khi giao tiếp với người khác qua email hơn là chỉ xác thực javascript của trang web của tôi! Nhưng cảm ơn vì đã vượt qua thử thách.
Ben Roberts

26
Đây là một giải pháp có vẻ tốt với hầu hết những người nói tiếng Anh bản địa, nhưng nó đã thất bại trong bài kiểm tra Thổ Nhĩ Kỳ (xem Joel Spolsky). Hầu hết các chữ cái unicode đều được cho phép, và ví dụ ở Argentina, các địa chỉ như "ñoñó1234@server.com" là hoàn toàn bình thường. joelonsoftware.com/articles/Unicode.html
oligofren

139
Bạn không thể xác nhận địa chỉ email, thời gian. Người duy nhất có thể xác nhận địa chỉ email là nhà cung cấp địa chỉ email. Ví dụ: câu trả lời này cho biết các địa chỉ email này: %2@gmail.com, "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, _@gmail.com, 1@gmail.com , 1_example@something.gmail.comtất cả đều hợp lệ, nhưng Gmail sẽ không bao giờ cho phép bất kỳ địa chỉ email nào trong số này. Bạn nên làm điều này bằng cách chấp nhận địa chỉ email và gửi thông điệp email đến địa chỉ email đó, với mã / liên kết mà người dùng phải truy cập để xác nhận tính hợp lệ.
Kevin Fegan

830

Tôi đã sửa đổi một chút câu trả lời của Jaymon cho những người muốn xác nhận thực sự đơn giản dưới dạng:

anystring@anystring.anystring

Biểu thức chính quy:

/\S+@\S+\.\S+/

Hàm JavaScript ví dụ:

function validateEmail(email) 
    {
        var re = /\S+@\S+\.\S+/;
        return re.test(email);
    }
    
console.log(validateEmail('anystring@anystring.anystring'));


69
Bạn có thể triển khai thứ gì đó dài gấp 20 lần có thể gây ra sự cố cho một số người dùng và có thể không hợp lệ trong tương lai hoặc bạn có thể lấy phiên bản của ImmortalFirefly để đảm bảo rằng ít nhất họ sẽ nỗ lực để biến nó thành sự thật. Tùy thuộc vào ứng dụng của bạn, có thể nhiều người sẽ gặp phải một người nào đó sẽ nổi điên vì bạn không chấp nhận email độc đáo của họ, thay vì ai đó gây ra sự cố bằng cách nhập địa chỉ email không thực sự tồn tại (họ có thể thực hiện bằng cách nhập địa chỉ email RFC2822 hợp lệ 100% nhưng sử dụng tên người dùng hoặc tên miền chưa đăng ký). Nâng cao!
dùng83358

82
@ImmortalFirefly, regex bạn cung cấp sẽ thực sự khớp name@again@example.com. Hãy thử dán dòng của bạn vào bảng điều khiển JavaScript. Tôi tin rằng ý định của bạn là chỉ khớp toàn bộ văn bản, sẽ yêu cầu bắt đầu văn bản '^' và kết thúc văn bản '$' toán tử. Cái tôi đang sử dụng là/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com')
OregonTrail

8
Dựa trên xác nhận này, email này là hợp lệ: kiểm tra @ this..com
Ehsan

4
Hừm. Wikipedia nói rằng đó "very.unusual.@.unusual.com"@example.comlà một địa chỉ email hợp lệ. /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('"very.unusual.@.unusual.com"@example.com') // false. Giáo sư.
Bacon Bits

3
Điều này cũng @@@.@không cho phép ? : D
hfossli

763

Để hoàn thiện, ở đây bạn có một biểu thức chính quy tuân thủ RFC 2822 khác

Tiêu chuẩn chính thức được gọi là RFC 2822 . Nó mô tả cú pháp mà các địa chỉ email hợp lệ phải tuân thủ. Bạn có thể ( nhưng bạn không nên - đọc tiếp ) thực hiện nó với biểu thức chính quy này:

(?:[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])+)\])

(...) Chúng tôi nhận được triển khai RFC 2822 thực tế hơn nếu chúng tôi bỏ qua cú pháp bằng dấu ngoặc kép và dấu ngoặc vuông. Nó vẫn sẽ phù hợp với 99,99% của tất cả các địa chỉ email trong sử dụng thực tế ngày hôm nay.

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

Một thay đổi nữa mà bạn có thể thực hiện là cho phép bất kỳ tên miền cấp cao nhất gồm hai chữ cái mã quốc gia và chỉ các tên miền cấp cao chung cụ thể. Regex này lọc địa chỉ email giả như thế nàoasdf@adsf.adsf . Bạn sẽ cần cập nhật nó khi các tên miền cấp cao mới được thêm vào .

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[A-Z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum)\b

Vì vậy, ngay cả khi tuân theo các tiêu chuẩn chính thức, vẫn có sự đánh đổi được thực hiện. Đừng mù quáng sao chép các biểu thức thông thường từ các thư viện trực tuyến hoặc các diễn đàn thảo luận. Luôn kiểm tra chúng trên dữ liệu của riêng bạn và với các ứng dụng của riêng bạn.

Nhấn mạnh mỏ


84
NB: "Trong thực tế sử dụng ngày hôm nay " có thể đã hợp lệ khi mã được viết, trở lại 200 lần. Mã này sẽ có khả năng vẫn được sử dụng vượt quá năm đó cụ thể. (Nếu tôi có một xu cho mỗi "meh, sẽ không có ai sử dụng TLD 4 + ngoại trừ những cái cụ thể" Tôi phải sửa, tôi có thể điều chỉnh thị trường đồng và niken của thế giới;))
Piskvor rời khỏi tòa nhà

7
Để triển khai thực tế RFC 2822, phần cuối nên được sửa đổi một chút để ngăn chặn các phần mở rộng tên miền char. / [a-z0-9! # $% & '* + \ / =? ^ _ {|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_{|} ~ -] +) * @ (?: [a-z0-9] (?: [a-z0-9 -] * [a-z0-9])? \.) + [a-z0-9] [a-z0-9 -] * [a-z0-9] /
sẽ Farrell

5
Ngoài ra, phần đầu tiên phải là (?: [Az có chữ A để tránh âm bản giả khi người dùng viết hoa địa chỉ email của họ.
Don Cán

9
@DonRolling Đừng làm vậy. Điều đó không có nghĩa là "A đến Z, a đến z", nó cũng có nghĩa là "[\] ^ _` "bởi vì những từ đó nằm giữa " Z "và" a ". Sử dụng \w, hoặc tốt hơn, chỉ viết thường địa chỉ email trước khi làm bất cứ điều gì với nó bởi vì dù sao đó cũng là quy ước.
kirb

5
"Bạn sẽ cần cập nhật nó khi các tên miền cấp cao mới được thêm vào." Chà, rất nhiều cho điều đó bây giờ - có hơn 1500 TLD được công nhận.
Nathan Osman

377

Wow, có rất nhiều phức tạp ở đây. Nếu tất cả những gì bạn muốn làm chỉ là bắt những lỗi cú pháp rõ ràng nhất, tôi sẽ làm một cái gì đó như thế này:

^\S+@\S+$

Nó thường nắm bắt các lỗi rõ ràng nhất mà người dùng mắc phải và đảm bảo rằng biểu mẫu hầu hết là đúng, đó là tất cả những gì về xác thực JavaScript.


70
+1 khi gửi email và xem điều gì xảy ra là cách chắc chắn thực sự duy nhất để xác thực địa chỉ email, không cần phải làm gì nhiều hơn so với kết quả regex đơn giản.
kommradHomer

20
Bạn vẫn có thể giữ cho nó đơn giản nhưng làm nhiều hơn một chút để đảm bảo nó có dấu "." ở đâu đó sau @ chỉ có số hoặc chữ số, vì vậy những thứ như tôi @ đây, tôi @ đây @ và tôi @ herecom không hợp lệ ... ^ \ S + @ \ S + [\.] [0-9a-z ] + $
Tim Franklin

14
Tôi nghĩ rằng địa chỉ e-mail có thể chứa không gian. Có lẽ tốt hơn để sử dụng.+@.+
Sam

11
/\S+@\S+/.test("áéíóúý@ÁÉÍÓÚÝð") true
gtournie

110
@gtournie Không ai quan tâm. Không ai sẽ nhập đó vào một lĩnh vực email một cách tình cờ , và đó là tất cả front-end xác nhận dành cho: Để ngăn chặn những người vô tình nhập sai chút thông tin, chẳng hạn như tên của họ, trong một lĩnh vực email.
meagar

330

Có điều gì đó bạn phải hiểu lần thứ hai bạn quyết định sử dụng biểu thức chính quy để xác thực email: Có lẽ đó không phải là một ý tưởng hay . Một khi bạn đã đồng ý với điều đó, có rất nhiều triển khai ngoài kia có thể giúp bạn đi được nửa đường, bài viết này tổng hợp chúng một cách độc đáo.

Tuy nhiên, trong ngắn hạn, cách duy nhất để hoàn toàn chắc chắn, tích cực chắc chắn rằng những gì người dùng nhập vào thực tế là một email là thực sự gửi email và xem điều gì sẽ xảy ra. Ngoài ra, tất cả chỉ là phỏng đoán.


112
-1 tại sao tôi muốn dành thời gian xác thực một địa chỉ email thậm chí không vượt qua kiểm soát regex?
kommradHome

63
@kommradHomer - một địa chỉ "regex không hợp lệ" hầu như luôn luôn hợp lệ, bởi vì bất kỳ regex nào bạn sử dụng để xác thực địa chỉ email gần như chắc chắn là sai và sẽ loại trừ các địa chỉ email hợp lệ. Một địa chỉ email là name_part@domain_partvà thực tế bất cứ điều gì, kể cả một @, có giá trị trong name_part; Địa chỉ foo@bar@machine.subdomain.example.museumlà hợp pháp, mặc dù nó phải được thoát như foo\@bar@machine..... Khi email đến miền, ví dụ: 'example.com', tên miền đó có thể định tuyến thư "cục bộ" để tên người dùng và tên máy chủ "lạ" có thể tồn tại.
Stephen P

6
Regex thứ hai trong câu trả lời của chuyến đi trong stackoverflow.com/a/1373724/69697 là thiết thực để sử dụng và hầu như không có phủ định sai. Tôi đồng ý với @kommradHomer tại đây - tại sao gửi email nếu bạn không phải làm vậy? Tôi có thể hiểu phản xạ không thích đối với các biểu thức không thể hiểu được và mong muốn giữ mã đơn giản, nhưng đây là một vài dòng mã có thể cứu máy chủ của bạn rất nhiều rắc rối bằng cách loại bỏ ngay các mục chắc chắn không hợp lệ. Một regex tự nó là không có ích, nhưng phục vụ như là một bổ sung tốt cho xác nhận máy chủ.
Ben Regenspan

6
@dmur Tôi thừa nhận "hầu như luôn luôn hợp lệ" có thể nói quá, nhưng tôi đã có địa chỉ email (hoàn toàn hợp lệ và đang hoạt động) bị từ chối bởi các trang web quá thường xuyên, chỉ vì tôi có .ustên miền hoặc vì tôi đã sử dụng +ở bên trái các @- nhiều nơi đã cố định các lỗi nghiêm trọng, nhưng các địa phương phần (bên trái của @) có thể là bất cứ điều gì người sở hữu miền muốn. -> "foo@bar.com"@example.com <- là một địa chỉ email hợp lệ.
Stephen P

8
@kommradHomer "Địa chỉ regex không hợp lệ là% 100 một địa chỉ không hợp lệ." Tôi xin lỗi ... xin lỗi? Bạn có biết bao nhiêu lần tôi đã được thông báo rằng foo+bar@gmail.com KHÔNG phải là một email hợp lệ trong khi thực tế nó có giá trị HOÀN HẢO?! Logic của bạn là TUYỆT VỜI. Tôi đã gửi biểu mẫu với các email như vậy: thisisafakeemailbutitwillpassyourstoolregexcheck@regexchecksareretarded.com Và đoán xem? R PNG PASSES kiểm tra REGEX ... nhưng nó KHÔNG phải là một email hợp lệ (mặc dù về mặt kỹ thuật là vậy, nhưng tôi hứa với bạn rằng nó không tồn tại ... nhưng cào cằm anh ấy ). Như nhiều người đã nói, NÓ LÀ MỘT Ý TƯỞNG BAD ....
Soundfx4

211

Bản thân HTML5 đã xác thực email. Nếu trình duyệt của bạn hỗ trợ HTML5 thì bạn có thể sử dụng mã sau đây.

<form><input type="email" placeholder="me@example.com" required>
    <input type="submit">
</form>

jsFiddleliên kết

Từ thông số HTML5 :

Một địa chỉ e-mail hợp lệ là một chuỗi phù hợp với emailsản xuất của ABNF sau, bộ ký tự cho đó là Unicode.

email   = 1*( atext / "." ) "@" label *( "." label )
label   = let-dig [ [ ldh-str ] let-dig ]  ; limited to a length of 63 characters by RFC 1034 section 3.5
atext   = < as defined in RFC 5322 section 3.2.3 >
let-dig = < as defined in RFC 1034 section 3.5 >
ldh-str = < as defined in RFC 1034 section 3.5 >

Yêu cầu này là vi phạm cố ý RFC 5322, định nghĩa cú pháp cho các địa chỉ email đồng thời quá nghiêm ngặt (trước ký tự "@"), quá mơ hồ (sau ký tự "@") và quá lỏng lẻo (cho phép nhận xét , các ký tự khoảng trắng và các chuỗi được trích dẫn theo cách cư xử xa lạ với hầu hết người dùng) sẽ được sử dụng thực tế ở đây.

Biểu thức chính quy tương thích với JavaScript và Perl sau đây là cách triển khai định nghĩa trên.

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

29
Điều này là tốt, nhưng vấn đề với điều này là nó phải nằm trong formthẻ và được gửi bởi một submitđầu vào, điều mà không phải ai cũng có thể làm được. Ngoài ra, bạn không thể thực sự định kiểu thông báo lỗi.
Jason

3
Tôi đã thêm một câu trả lời dưới đây giải phóng bạn khỏi biểu mẫu và gửi. Nhưng có, các trình duyệt thường cũng chỉ áp dụng một số kiểm tra tính hợp lý và không phải là xác nhận RFC 822 đầy đủ.
Boldewyn

8
@ br1: không phải là không hợp lệ chỉ vì không tồn tại một tên miền toplevel nào. Điều gì mạng nội bộ của bạn có aa giải quyết một số IP?
cừu bay

7
Loại trường email Html5 chấp nhận các email như user @ email
Puce 19/03/2015

1
Lưu ý @ Puce's bình luận: đầu vào email HTML 5 chấp nhận user@emailtrong khi, ví dụ, PHP filter_varthì không. Điều này có thể gây ra vấn đề.
texelate

136

Tôi đã tìm thấy đây là giải pháp tốt nhất:

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

Nó cho phép các định dạng sau:

1. beautifulandsimple@example.com
2. Very.common@example.com
3. dùng một lần.style.email.with + symbol@example.com
4. other.email-with-dash@example.com
9. #!$%&'*+-/=?ucci_` nbspl|~@example.org
6. "() []:,; @ \\\"! # $% & '* + - / =? ^ _ `{} | ~ .a "@ example.org
7. "" @ example.org (khoảng trắng giữa các trích dẫn)
8. üñîçøðé@example.com (Ký tự Unicode trong phần cục bộ)
9. üñîçøðé@üñîçøðé.com (Ký tự Unicode trong phần tên miền)
10. Pelé@example.com (tiếng Latin)
11. δ κ π Greek Greek Greek
12. 我 買 @. 香港 (tiếng Trung)
13. 甲 斐 @ 川. 日本 (tiếng Nhật)
14. чебурашкакаяяяяяяяя

Nó rõ ràng linh hoạt và cho phép các nhân vật quốc tế quan trọng, trong khi vẫn thực thi định dạng any@anything.anything cơ bản. Nó sẽ chặn các không gian được RFC cho phép về mặt kỹ thuật, nhưng chúng hiếm đến nỗi tôi rất vui khi làm điều này.


9
Đây chính xác là những gì tôi đang làm. Tất cả các câu trả lời "phức tạp" này đều tạo ra vấn đề: chúng không cho phép IDN mã hóa hoặc sử dụng một bộ TLD cố định hoặc hạn chế người dùng không sử dụng các ký tự như [@ çiêu.ö trong tiền tố email của họ (trước @) hoặc tên miền. JavaScript ở lối vào (không dành cho mục đích sử dụng phụ trợ) không đủ để xác thực vì lý do bảo mật. Vậy tại sao không chỉ giúp người dùng ngăn ngừa lỗi chính tả cơ bản. Các lỗi chính tả cơ bản là: quên TLD hoặc tiền tố người dùng (trước @) hoặc phần tên miền hoặc gõ nhầm @thành .(hoặc ngược lại). Vì lý do chúng ta phải hạn chế hơn về phía máy chủ.
Hafenkranich

Vì một số lý do kỳ lạ username@domain.comkhông hoạt động với mẫu này
einstein

2
Theo regex của bạn "_.............. kamal @ gmail" là hợp lệ, điều này không nên!
Kamal Naya

1
Đây là RegEx đã nêu với các ví dụ, nếu bạn muốn sửa đổi giải pháp này: regex101.com/r/AzzGQU/2
ryanm

7
Regex này là chính xác. Nếu bất cứ ai đang nhập email của họ như vậy a@b@c@d.x.y.@.zthì có lẽ họ xứng đáng có một thời gian tồi tệ? : D
corysimmons

94

Trong các trình duyệt hiện đại, bạn có thể xây dựng dựa trên câu trả lời của @ Sushil với JavaScript thuần túy và DOM :

function validateEmail(value) {
  var input = document.createElement('input');

  input.type = 'email';
  input.required = true;
  input.value = value;

  return typeof input.checkValidity === 'function' ? input.checkValidity() : /\S+@\S+\.\S+/.test(value);
}

Tôi đã đưa ra một ví dụ trong fiddle http://jsfiddle.net/boldewyn/2b6d5/ . Kết hợp với phát hiện tính năng và xác thực xương cốt từ Câu trả lời của Squirtle , nó giải phóng bạn khỏi cuộc thảm sát biểu hiện thông thường và không làm phiền trên các trình duyệt cũ.


4
Đây là một ý tưởng thông minh để khắc phục sự cố nhưng nó không hoạt động vì các trình duyệt cũng có xác nhận hợp lệ. Ví dụ: .@axác nhận như truetrong các phiên bản hiện tại của Chrome, Firefox và Safari.
Hank

13
@HenryJackson Thật không may, trong trường hợp này là có. Điều này là do theo RFC là một địa chỉ email hợp lệ (nghĩ là mạng nội bộ). Các trình duyệt sẽ bị nướng, nếu chúng xác nhận quá hẹp và tạo ra các phủ định sai.
Boldewyn

3
Được cập nhật để chứa tính năng phát hiện và xuống cấp duyên dáng, giờ đây nó không bị hỏng trên các trình duyệt mới mà sử dụng bất kỳ biểu thức chính nào bạn muốn.
Ronny

Giải pháp tốt đẹp. Đáng buồn thay, điều này chỉ dành cho HTML5 +.
Edward Olamisan

3
Đây là giải pháp tốt nhất cho câu hỏi ban đầu. Đúng, nó sử dụng HTML5, nhưng phần lớn các ứng dụng yêu cầu mức độ chính xác này chắc chắn sẽ dựa vào HTML5 theo một cách nào khác, vì vậy, điểm chính. Chúng tôi không thể xác định xem email của ai đó có hợp lệ hay không mà không được họ xác minh bằng mọi cách, vì vậy chúng tôi thực sự không nên đầu tư quá nhiều thời gian hay công sức để xác thực email. Kiểm tra nhanh cho bất kỳ cú pháp rõ ràng hoặc sự cố gắng cố gắng là tất cả những nỗ lực chúng ta nên dành.
Woody Payne

69

Đây là phiên bản RFC822 chính xác.

function checkEmail(emailAddress) {
  var sQtext = '[^\\x0d\\x22\\x5c\\x80-\\xff]';
  var sDtext = '[^\\x0d\\x5b-\\x5d\\x80-\\xff]';
  var sAtom = '[^\\x00-\\x20\\x22\\x28\\x29\\x2c\\x2e\\x3a-\\x3c\\x3e\\x40\\x5b-\\x5d\\x7f-\\xff]+';
  var sQuotedPair = '\\x5c[\\x00-\\x7f]';
  var sDomainLiteral = '\\x5b(' + sDtext + '|' + sQuotedPair + ')*\\x5d';
  var sQuotedString = '\\x22(' + sQtext + '|' + sQuotedPair + ')*\\x22';
  var sDomain_ref = sAtom;
  var sSubDomain = '(' + sDomain_ref + '|' + sDomainLiteral + ')';
  var sWord = '(' + sAtom + '|' + sQuotedString + ')';
  var sDomain = sSubDomain + '(\\x2e' + sSubDomain + ')*';
  var sLocalPart = sWord + '(\\x2e' + sWord + ')*';
  var sAddrSpec = sLocalPart + '\\x40' + sDomain; // complete RFC822 email address spec
  var sValidEmail = '^' + sAddrSpec + '$'; // as whole string

  var reValidEmail = new RegExp(sValidEmail);

  return reValidEmail.test(emailAddress);
}

Địa chỉ IDN không được xác thực (info@üpöü.com)
DAH

66

JavaScript có thể khớp với biểu thức chính quy:

emailAddress.match( / some_regex /);

Đây là biểu thức chính quy RFC22 cho email:

^((?>[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+\x20*|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*
"\x20*)*(?<angle><))?((?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+)+|"((?=[\x01-\x
7f])[^"\\]|\\[\x01-\x7f])*")@(((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}|\[(((?(?<
!\[)\.)(25[0-5]|2[0-4]\d|[01]?\d?\d)){4}|[a-zA-Z\d\-]*[a-zA-Z\d]:((?=[\x01-\x7f])
[^\\\[\]]|\\[\x01-\x7f])+)\])(?(angle)>)$

1
@Kato: Nó sử dụng một số tiện ích mở rộng không tương thích, bao gồm (?>để dừng quay lại và (?<angle><)…(?(angle)>)để tránh cung cấp thời gian dài |.
Ry-

60

Tất cả các địa chỉ email đều chứa ký hiệu 'at' (tức là @). Kiểm tra điều kiện cần thiết:

email.indexOf("@") > 0

Đừng bận tâm với bất cứ điều gì phức tạp hơn. Ngay cả khi bạn có thể xác định một cách hoàn hảo liệu email có hợp lệ về mặt cú pháp hay không, điều đó sẽ không cho bạn biết liệu nó có thuộc về người đã cung cấp hay không. Đó là những gì thực sự quan trọng.

Để kiểm tra điều đó, gửi tin nhắn xác nhận.


3
Điều gì xảy ra nếu có nhiều hơn một biểu tượng '@'? biểu tượng hạn chế khác? Xác nhận này không thể tin cậy được ...
eatmypants

56

Xác nhận chính xác địa chỉ email tuân thủ RFC không phải là điều có thể đạt được với biểu thức chính quy một lớp. Một bài viết với giải pháp tốt nhất tôi tìm thấy trong PHP là Địa chỉ email hợp lệ là gì? . Rõ ràng, nó đã được chuyển sang Java. Tôi nghĩ rằng chức năng này quá phức tạp để được chuyển và sử dụng trong JavaScript. Cổng JavaScript / node.js: https://www.npmjs.com/package/email-addresses .

Một thực hành tốt là xác thực dữ liệu của bạn trên máy khách, nhưng kiểm tra kỹ xác thực trên máy chủ. Với suy nghĩ này, bạn chỉ cần kiểm tra xem một chuỗi có giống địa chỉ email hợp lệ trên máy khách hay không và thực hiện kiểm tra nghiêm ngặt trên máy chủ.

Đây là hàm JavaScript tôi sử dụng để kiểm tra xem một chuỗi có giống địa chỉ thư hợp lệ không:

function looksLikeMail(str) {
    var lastAtPos = str.lastIndexOf('@');
    var lastDotPos = str.lastIndexOf('.');
    return (lastAtPos < lastDotPos && lastAtPos > 0 && str.indexOf('@@') == -1 && lastDotPos > 2 && (str.length - lastDotPos) > 2);
}

Giải trình:

  • lastAtPos < lastDotPos: Last @nên là trước cuối cùng .@không thể là một phần của tên máy chủ (theo như tôi biết).

  • lastAtPos > 0: Cần có một cái gì đó (tên người dùng email) trước cuối cùng @.

  • str.indexOf('@@') == -1: Không nên có @@trong địa chỉ. Ngay cả khi @xuất hiện dưới dạng ký tự cuối cùng trong tên người dùng email, nó phải được trích dẫn vì vậy "sẽ nằm giữa ký tự đó @và cuối cùng @trong địa chỉ.

  • lastDotPos > 2: Nên có ít nhất ba ký tự trước dấu chấm cuối cùng a@b.com.

  • (str.length - lastDotPos) > 2: Cần có đủ các ký tự sau dấu chấm cuối cùng để tạo thành một miền có hai ký tự. Tôi không chắc chắn nếu dấu ngoặc là cần thiết.


Fn này có vẻ tốt, nhưng nó có tốt hơn regex được viết trong câu trả lời hàng đầu không?
Atul G Lòng tin

4
Tôi nghi ngờ điều đó. Tôi chỉ sử dụng nó để kiểm tra xem một chuỗi có giống email hay không và để lại chi tiết cho mã phía máy chủ.
Miloš Rašić

Nó xác nhận OK bất kỳ chuỗi nào như 'aaaa', tức là không có '@' và '.'
Gennady Shumakher

1
Nó không nên. last IndexOf () sẽ trả về -1 nếu không tìm thấy kim.
Miloš Rašić

Ngay cả khi @xuất hiện dưới dạng ký tự cuối cùng trong tên người dùng email, nó phải được trích dẫn vì vậy "sẽ nằm giữa đó @và cuối cùng @trong địa chỉ. Thế còn "@@"@example.com?
Ry-

47

Điều này đã bị đánh cắp từ http://codesnippets.joyent.com/posts/show/1917

email = $('email');
filter = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/;
if (filter.test(email.value)) {
  // Yay! valid
  return true;
}
else
  {return false;}

7
Điều này lọc ra các tên miền .museumvà phổ biến .travel(do giới hạn 4 char sau .)
bobobobo

4
Thay đổi {2,4} thành {2,6} sẽ không thành vấn đề
Anton N

11
@Anton N: Nó cũng có khoảng một loạt các vấn đề khác; trận chung kết {2,4}chỉ là một chỉ báo hữu ích (như trong "khi bạn thấy lỗi đó, những người khác có thể sẽ ở xung quanh"). Cái cơ bản nhất là thiếu +ở phần địa phương; hộp bình luận này quá nhỏ để chỉ ra tất cả các lỗi được cam kết ở trên.
Piskvor rời khỏi tòa nhà

37
Tại sao bạn không thể làm gì return filter.test(email.value);?
MT.

3
@AntonN: Bây giờ chúng tôi có hơn 10 TLD ký tự ( xn--clchc0ea0b2g2a9gcd). Vẫn không phải là một vấn đề?
Piskvor rời khỏi tòa nhà vào

42

Làm cái này:

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

Tại sao? Nó dựa trên RFC 2822 , đây là một địa chỉ email TẤT CẢ tiêu chuẩn PHẢI tuân thủ. Và tôi không chắc tại sao bạn lại bận tâm với thứ gì đó "đơn giản" hơn ... dù sao bạn cũng sẽ sao chép và dán nó;)

Thông thường khi lưu trữ địa chỉ email trong cơ sở dữ liệu, tôi đặt chúng thành chữ thường và trong thực tế, regex thường có thể được đánh dấu không phân biệt chữ hoa chữ thường. Trong những trường hợp này, nó hơi ngắn hơn:

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

Đây là một ví dụ về nó đang được sử dụng trong JavaScript (với cờ không phân biệt chữ hoa chữ thường iở cuối).

var emailCheck=/^[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?$/i;
console.log( emailCheck.test('some.body@domain.co.uk') );

Lưu ý :
Về mặt kỹ thuật, một số email có thể bao gồm dấu ngoặc kép trong phần trước @biểu tượng có ký tự thoát bên trong dấu ngoặc kép (vì vậy người dùng email của bạn có thể đáng ghét và chứa nội dung như @"..."miễn là nó được viết trong dấu ngoặc kép). NOBODY LÀM ĐIỀU NÀY! Nó đã lỗi thời. Nhưng, nó được bao gồm trong tiêu chuẩn RFC 2822 thực sự , và được bỏ qua ở đây.

Thêm thông tin: http://www.THER-expressions.info/email.html


@Kondal mã javascript không phân biệt chữ hoa chữ thường vì /icờ ở cuối biểu thức chính quy. Tôi đề cập đến thực tế rằng nó cần phải là một so sánh không phân biệt chữ hoa chữ thường, nhưng tôi sẽ nói rõ hơn.
Ryan Taylor

Làm việc cho tôi như một cơ duyên
Alex

40

Tôi thực sự mong muốn giải quyết vấn đề này. Vì vậy, tôi đã sửa đổi biểu thức xác thực email thường xuyên ở trên

  • Nguyên
    /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

  • Sửa đổi
    /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()\.,;\s@\"]+\.{0,1})+[^<>()\.,;:\s@\"]{2,})$/

để vượt qua các ví dụ trong Địa chỉ Email Wikipedia .

Và bạn có thể thấy kết quả ở đây .

nhập mô tả hình ảnh ở đây


Đây có vẻ là một giải pháp tốt, nó cũng hoạt động với các TLD mới và 1 email thư
Mark Hughes

Tại sao john..doe@example.comkhông nên sửa? Đó là một trường hợp góc hợp lệ.
Valerio Bozz

24

Bạn không nên sử dụng các biểu thức thông thường để xác thực chuỗi đầu vào để kiểm tra xem đó có phải là email không. Nó quá phức tạp và sẽ không bao gồm tất cả các trường hợp.

Bây giờ vì bạn chỉ có thể bao gồm 90% các trường hợp, hãy viết một cái gì đó như:

function isPossiblyValidEmail(txt) {
   return txt.length > 5 && txt.indexOf('@')>0;
}

Bạn có thể tinh chỉnh nó. Chẳng hạn, 'aaa @' là hợp lệ. Nhưng nhìn chung bạn có được ý chính. Và đừng mang đi ... Một giải pháp 90% đơn giản tốt hơn giải pháp 100% không hiệu quả.

Thế giới cần mã đơn giản hơn ...


15
Điều này cho phép nhập rất nhiều địa chỉ email không hợp lệ, đó là lời khuyên vô ích.
cazlab

3
Nó không phải là không thể gỡ lỗi cả. Có nhiều ví dụ hay trong chủ đề này xác thực hơn là "nó có '@' trong đó. Ví dụ của bạn cho phép" u @ "được coi là một địa chỉ email hợp lệ. Ít nhất là đánh giá xem có tên miền hay thứ gì đó không có thể là một miền. Bản thân bạn là một ví dụ về cái mà tôi gọi là "mã hóa lười biếng tích cực". Tôi không chắc tại sao bạn lại bảo vệ nó vì đó là câu trả lời được đánh giá thấp nhất trong chuỗi.
cazlab

3
@cazlab có lẽ bạn đúng. Sau tất cả tôi đã được bỏ phiếu xuống. Khác với bạn Tôi không nghĩ mặc dù bất kỳ đoạn mã nào ở trên cho thấy đoạn trích dễ dàng. Cách tiếp cận 'lười biếng' của tôi ít nhất có thể được cải thiện nếu được yêu cầu.
Zo72

3
Điều này khác với việc sử dụng regex như thế nào? (.+)@(.*)làm điều tương tự, và ngắn hơn.
snostorm

4
+1 - Nếu mục tiêu là đảm bảo rằng người dùng ít nhất đã cố gắng đặt địa chỉ e-mail, sau đó kiểm tra xem liệu có thể xác định rằng địa chỉ e-mail chắc chắn KHÔNG phải là e-mail giải pháp tuyệt vời. Một ví dụ điển hình là nếu bạn muốn tên người dùng là địa chỉ email. Nếu người dùng gõ vào 'sexy_chick_23', thì biểu thức chính quy này có thể được sử dụng để cung cấp cho họ thông báo rằng một e-mail được mong đợi. Nếu một cái gì đó được nhập vào trông giống như một e-mail, nhưng không phải, thì người dùng sẽ không bao giờ nhận được e-mail 'xác nhận' và quá trình đăng ký sẽ không bao giờ được xác thực.
Chris Dutrow

23

Chỉ cần kiểm tra xem địa chỉ email đã nhập có hợp lệ hay không sử dụng HTML.

<input type="email"/>

Không cần phải viết một hàm để xác nhận.


4
IE <10 không hỗ trợ điều này và trình duyệt của Android cũng không.
Frank Conijn

7
Nâng cao. IE <10 đã chết.
Michael Scheper

19

Thật khó để có được một trình xác nhận email chính xác 100%. Cách thực sự duy nhất để làm cho nó chính xác là gửi email kiểm tra đến tài khoản. Điều đó nói rằng, có một vài kiểm tra cơ bản có thể giúp đảm bảo rằng bạn đang nhận được một cái gì đó hợp lý.

Một số điều cần cải thiện:

Thay vì mới RegExp, chỉ cần thử viết regexpra như thế này:

if (reg.test(/@/))

Thứ hai, kiểm tra để đảm bảo rằng một khoảng thời gian xuất hiện sau @dấu hiệu và đảm bảo rằng có các ký tự giữa @s và dấu chấm.


19

Đây là cách trình xác nhận nút thực hiện:

/^(?:[\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])\]))$/

14

Sử dụng mã này trong chức năng trình xác nhận của bạn:

var emailID = document.forms["formName"]["form element id"].value;
atpos = emailID.indexOf("@");
dotpos = emailID.lastIndexOf(".");
if (atpos < 1 || ( dotpos - atpos < 2 ))
{
    alert("Please enter correct email ID")
    return false;
}

Khác bạn có thể sử dụng jQuery . Quy tắc bên trong xác định:

eMailId: {
    required: true,
    email: true
}

1
abc@xyzlà một email hoàn toàn hợp lệ mà regex của bạn không nhận ra.
Toto

3
Không, không. Mẫu email chính xác là Something@s Something.s Something, abc @ xyz không khớp với mẫu đó. Vì vậy, nó không phải là một địa chỉ hợp lệ.
lan


5
Bạn có trang wikipedia không? Một TLD là một tên máy chủ hợp lệ. Vậy abc@tldlà một địa chỉ email hợp lệ.
Toto

2
Cách duy nhất để xác thực một địa chỉ email là gửi email sau đó chờ phản hồi. Ngoài ra, đây là một url nơi bạn có thể kiểm tra xem địa chỉ của bạn có tuân thủ RFC822 hay không : mystic-beasts.com/~pdw/cgi-bin/emailvalidate . Bạn có thể thấy rằng abc @ xyz là một địa chỉ hợp lệ cho RFC822.
Toto

14

Cập nhật Regex 2018! thử cái này

let val = 'email@domain.com';
if(/^[a-z0-9][a-z0-9-_\.]+@([a-z]|[a-z0-9]?[a-z0-9-]+[a-z0-9])\.[a-z0-9]{2,10}(?:\.[a-z]{2,10})?$/.test(val)) {
   console.log('passed');
}

hoàn thành phiên bản typscript

//
export const emailValid = (val:string):boolean => /^[a-z0-9][a-z0-9-_\.]+@([a-z]|[a-z0-9]?[a-z0-9-]+[a-z0-9])\.[a-z0-9]{2,10}(?:\.[a-z]{2,10})?$/.test(val);

thêm thông tin https://git.io/vhEfc


Đây thất bại cho một email@domain.com chuẩn
Ricks

1
@RickS điều này chỉ đơn giản là không đúng sự thật. Vui lòng kiểm tra lại
malimo

13

Một giải pháp không kiểm tra sự tồn tại của TLD là không đầy đủ.

Hầu như tất cả các câu trả lời cho câu hỏi này đề nghị sử dụng Regex để xác thực địa chỉ email. Tôi nghĩ Regex chỉ tốt cho việc xác nhận thô sơ. Có vẻ như việc kiểm tra xác thực địa chỉ email thực sự là hai vấn đề riêng biệt:

1- Xác thực định dạng email: Đảm bảo nếu email tuân thủ định dạng và mẫu email trong RFC 5322 và nếu TLD thực sự tồn tại. Một danh sách tất cả các TLD hợp lệ có thể được tìm thấy ở đây .

Ví dụ: mặc dù địa chỉ example@example.cccsẽ vượt qua regex, nhưng đó không phải là một email hợp lệ, bởi vì cccIANA không phải là một tên miền cấp cao nhất.

2- Đảm bảo email thực sự tồn tại: Để thực hiện việc này, tùy chọn duy nhấtgửi email cho người dùng .


13

Regex để xác nhận địa chỉ email

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

Tôi không thấy regrec của bạn trong RFC5322: tools.ietf.org/html/rfc5322 - có lỗi gì không?
Kamil Kiełczewski

"Regex tốt nhất bao giờ hết"? Có thể một số loại giải thích ở đây?
Connectyourcharger

Tại sao yo nói rằng đó là giải pháp tốt nhất trong tất cả, bạn có thể giải thích thêm một chút không?
nancoder

Tôi không thể nhớ lại lý do tại sao tôi đã viết "regex tốt nhất từng có". Xin lỗi các bạn nếu điều đó làm phiền bạn.
Bohhat Kasera

12

Đây là một cuộc thảo luận rất tốt về việc sử dụng các biểu thức thông thường để xác nhận địa chỉ email; " So sánh địa chỉ email xác thực biểu thức chính quy "

Đây là biểu thức hàng đầu hiện tại, tương thích với JavaScript, cho mục đích tham khảo:

/^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'?]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+)*\.(aero|arpa|biz|com|coop|edu|gov|info|int|mil|museum|name|net|org|pro|travel|mobi|[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i

9
-1 Danh sách trắng để lại nhiều điều mong muốn - đáng chú ý là bạn đã bỏ lỡ .jobs. Ngoài ra, có IDN trực tiếp (hầu hết trong số đó, tôi thừa nhận, chỉ được phê duyệt về mặt chính thức sau bài đăng của bạn - ví dụ: .中國vào tháng 6 năm 2010; nhưng hầu hết đã hoạt động trong nhiều năm).
Piskvor rời khỏi tòa nhà

2
-1 không sử dụng tên miền cấp cao nhất không đổi. Luôn luôn có (và sẽ có ví dụ 2013) có thể được thêm tld mới.
miho

Đã có xác nhận 100 của TLD mới. Câu trả lời này không hợp lệ và không bao giờ nên được sử dụng.
Dean Meehan

Vâng Tôi đã nói điều đó vào năm 2011 và tôi sẽ nói lại một lần nữa: danh sách trắng các tên miền "đặc biệt" sẽ chỉ trở nên tồi tệ hơn theo thời gian, khi nhiều TLD được phê duyệt. Có hơn 100 TLD hoàn toàn hợp lệ không phù hợp với danh sách trắng ở trên: en.wikipedia.org/wiki/List_of_INET_top-level_domains
Piskvor rời khỏi tòa nhà vào

Đó là năm 2015. Biểu hiện của bạn không thực tế. Bạn nên bỏ câu trả lời này xuống, nhưng có lẽ bạn quá bận rộn để sửa tất cả các trang bạn đặt biểu thức này. Đúng?
Eric Leroy


12

Ngược lại với squirtle , đây là một giải pháp phức tạp, nhưng nó thực sự rất tốt trong việc xác nhận email đúng cách:

function isEmail(email) { 
    return /^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))$/i.test(email);
} 

Sử dụng như vậy:

if (isEmail('youremail@yourdomain.com')){ console.log('This is email is valid'); }

10
Bạn không cần == trueví dụ của bạn.
Luke Alderton

11

Kiến thức của tôi về biểu thức chính quy là không tốt. Đó là lý do tại sao tôi kiểm tra cú pháp chung bằng một biểu thức chính quy đơn giản trước và kiểm tra các tùy chọn cụ thể hơn với các hàm khác sau đó. Đây có thể không phải là giải pháp kỹ thuật tốt nhất, nhưng theo cách này tôi linh hoạt hơn và nhanh hơn.

Các lỗi phổ biến nhất mà tôi gặp phải là khoảng trắng (đặc biệt là ở đầu và cuối) và đôi khi là một dấu chấm kép.

function check_email(val){
    if(!val.match(/\S+@\S+\.\S+/)){ // Jaymon's / Squirtle's solution
        // Do something
        return false;
    }
    if( val.indexOf(' ')!=-1 || val.indexOf('..')!=-1){
        // Do something
        return false;
    }
    return true;
}

check_email('check@thiscom'); // Returns false
check_email('check@this..com'); // Returns false
check_email(' check@this.com'); // Returns false
check_email('check@this.com'); // Returns true

10
<form name="validation" onSubmit="return checkbae()">
    Please input a valid email address:<br />

    <input type="text" size=18 name="emailcheck">
    <input type="submit" value="Submit">
</form>

<script language="JavaScript1.2">
    var testresults
    function checkemail(){
        var str = document.validation.emailcheck.value
        var filter = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i
        if (filter.test(str))
            testresults = true
        else {
            alert("Please input a valid email address!")
            testresults = false
        }
        return (testresults)
    }
</script>

<script>
    function checkbae(){
        if (document.layers || document.getElementById || document.all)
            return checkemail()
        else
            return true
    }
</script>

Có lẽ nếu bạn thêm một lời giải thích hoặc mô tả để đi với nó? Tôi không nghĩ rằng bạn thực sự cần phải hiển thị bất kỳ html nào; tất cả mọi người quan tâm là javascript và regex. Nếu bạn giảm câu trả lời của mình xuống chỉ với jacascript và thêm một chút lúng túng đi kèm với nó, tôi sẽ cung cấp cho bạn một upvote.
bgmCoder

9

Tôi đang tìm kiếm một Regex trong JS vượt qua tất cả các trường hợp kiểm tra Địa chỉ Email:

  • email@example.com Email hợp lệ

  • firstname.lastname@example.com Email chứa dấu chấm trong trường địa chỉ

  • email@subdomain.example.com Email chứa dấu chấm với tên miền phụ

  • firstname+lastname@example.com Dấu cộng được coi là ký tự hợp lệ

  • email@192.0.2.123 Tên miền là địa chỉ IP hợp lệ

  • email@[192.0.2.123] Dấu ngoặc vuông quanh địa chỉ IP được coi là hợp lệ

  • “email”@example.com Báo giá xung quanh email được coi là hợp lệ

  • 1234567890@example.com Chữ số trong địa chỉ là hợp lệ

  • email@domain-one.example Dấu gạch ngang trong tên miền là hợp lệ

  • _______@example.com Gạch dưới trong trường địa chỉ là hợp lệ

  • email@example.name .name là tên miền cấp cao nhất hợp lệ

  • email@example.co.jpDấu chấm trong tên miền cấp cao nhất cũng được coi là hợp lệ (sử dụng co.jpví dụ ở đây)

  • firstname-lastname@example.com Dấu gạch ngang trong trường địa chỉ là hợp lệ

Ở đây chúng tôi đi:

http://regexr.com/3f07j

HOẶC regex:

Regex = /(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@[*[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+]*/

8

Biểu thức chính quy được cung cấp bởi Microsoft trong ASP.NET MVC

/^[\w-]+(\.[\w-]+)*@([a-z0-9-]+(\.[a-z0-9-]+)*?\.[a-z]{2,6}|(\d{1,3}\.){3}\d{1,3})(:\d{4})?$/

Mà tôi đăng ở đây trong trường hợp nó còn thiếu sót - mặc dù nó luôn hoàn hảo cho nhu cầu của tôi.


1
Không cho phép + trong phần tên của email.
Paul Go
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.