a

Câu hỏi Làm cách nào để xác thực địa chỉ email bằng JavaScript?


Làm cách nào để xác thực địa chỉ email trong JavaScript?


3259


gốc


Mặc dù giải pháp này có thể đơn giản, tôi chắc chắn đây là một trong những điều hữu ích mà mọi người sẽ là Googling và xứng đáng với mục nhập riêng của mình trên trang web Nếu chỉ Google sẽ là nơi đầu tiên để nhìn :) Chỉ cần nhìn vào các bản sao của điều này đóng cửa mỗi một thời gian. - Esteban Küber
Tôi chắc chắn đây là một trong những điều hữu ích mà mọi người sẽ là Googling cho  lol, như một vấn đề của thực tế đó là cách tôi chỉ cần đi qua câu hỏi này! - Peter C
có thể trùng lặp Biểu thức chính quy tốt nhất để xác thực địa chỉ email là gì? - Brad Mace
xin vui lòng nhận được quyền này, 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 bằng 2 hoặc 3 chữ cái. - Ian Ringrose
Bất kỳ sự hỗ trợ nào cho việc sử dụng séc regex cho e-mail tôi đều chống lại 100%. Tôi mệt khi được thông báo địa chỉ e-mail của tôi là "foo+bar@gmail.com" 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, thì hãy cho người dùng biết địa chỉ email của họ có vẻ không hợp lệ và hỏi xem họ có chắc chắn rằng họ đã nhập nó hay không đúng. Thậm chí đi xa như vậy để chỉ ra những gì không kiểm tra trong kiểm tra regexp, nhưng không ngăn chặn chúng từ trình mẫu. - Soundfx4


Các câu trả lời:


Sử dụng cụm từ thông dụ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 (được lấy từ crôm)

function validateEmail(email) {
    var 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());
}

Dưới đây là ví dụ về expresion thông thường chấp nhận unicode:

var 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 thực ở phía máy chủ.

Dưới đây là ví dụ về hành động trên:

function validateEmail(email) {
  var 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() {
  var $result = $("#result");
  var 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").bind("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>


3795



Regex này loại bỏ các email hợp lệ, đang sử dụng. Không được dùng. Google cho "RFC822" hoặc "RFC2822" để có được regex phù hợp. - Randal Schwartz
@Randall: Bạn có thể cho ví dụ về địa chỉ email mà địa chỉ này không cho phép không? - rossipedia
@ GoodPerson Tôi vừa 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 tôi. Tôi nghi ngờ bất cứ ai có vấn đề lớn hơn giao tiếp với người khác thông qua email hơn là chỉ xác thực javascript trang web của tôi! Nhưng cảm ơn vì đã vượt qua thử thách. - Ben Roberts
Đối với tất cả mọi người bình luận rằng điều này là "đủ tốt": hãy nhìn xem, bạn chỉ đơn giản là suy nghĩ về vấn đề này sai. Vậy là được rồi. Đó là lựa chọn bạn có thể tạo cho người dùng của mình. Tôi không giận nó. Nhưng, bạn biết đấy, về mặt kỹ thuật, bạn đang chứng minh, có vẻ sai. - Wayne Burkett
Bạn không thể xác thực địa chỉ email, thời gian. Người duy nhất có thể xác thực đị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 sau: %2@gmail.com, "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, _@gmail.com, 1@gmail.com , 1_example@something.gmail.com tấ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 một 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


Chỉ để hoàn thành, ở đây bạn có một regex tương thích 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 cụm từ thông dụng 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 một thực hiện thực tế hơn của RFC 2822 nếu chúng ta bỏ qua cú pháp bằng cách sử dụ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 thực tế sử dụng 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 khác 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 hai chữ cái nào của mã quốc gia và chỉ các miền cấp cao nhất chung chung cụ thể. Regex này lọc các địa chỉ email giả asdf@adsf.adsf. Bạn sẽ cần phải cập nhật nó như là 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ó những sự đánh đổi được thực hiện. Đừng sao chép một cách mù quáng các biểu thức chính quy 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.

Mỏ nhấn mạnh


612



NB: "Trong thực tế sử dụng hôm nay"có thể đã hợp lệ khi mã được viết, quay lại 200x. Mã sẽ có thể vẫn được sử dụng ngoài năm cụ thể đó. (Nếu tôi có một xu cho mỗi "meh, không ai sẽ sử dụng một TLD 4 bản sao trừ những người cụ thể" Tôi đã phải sửa chữa, tôi có thể góc thị trường đồng và niken của thế giới;)) - Piskvor
Để thực hiện thực tế RFC 2822, kết thúc nên được sửa đổi một chút để ngăn chặn các phần mở rộng miền đơ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] / - will Farrell
Ngoài ra, phần đầu tiên phải là (?: [A-z với số vốn A để tránh âm bản sai khi người dùng tận dụng địa chỉ email của họ. - Don Rolling
Với thông số kỹ thuật, d._.___d@gmail.com không phải là một email hợp lệ, nhưng điều này vẫn phát hiện nó là một email chính xác - Raptor
@ DonRolling Đừng làm thế. Điều đó không chỉ có nghĩa là "A đến Z, a đến z", nó cũng có nghĩa là "[\] ^ _` "bởi vì đó là ở giữa "Z" và "a". Sử dụng \whoặc tốt hơn, chỉ cần viết thường địa chỉ email trước khi làm bất cứ điều gì với nó vì đó là quy ước. - kirb


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

Cụm từ thông dụng:

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

Hàm JavaScript mẫu:

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

551



/\S+@\S+\.\S+/.test('name@again@example.com')  true - neoascetic
@neoascetic Shazam! /[^\s@]+@[^\s@]+\.[^\s@]+/.test('name@again@example.com') // false - n0nag0n
Bạn có thể thực hiện điều gì đó dài 20x có thể gây ra sự cố cho một vài 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 họ ít nhất nỗ lực làm cho nó trông thật. Tùy thuộc vào ứng dụng của bạn, có thể có nhiều người sẽ phát điên vì bạn không chấp nhận email độc đáo của họ, chứ không phải là người 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 mọi thứ 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ý). Đã bỏ phiếu! - user83358
@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, điều này sẽ yêu cầu bắt đầu văn bản '^' và kết thúc của các toán tử '$'. Cái tôi đang sử dụng là /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com') - OregonTrail
Mọi người sẽ ngừng phàn nàn về những mặt tích cực sai? Đây là một regex SIMPLE để bắt được 95% số lỗi. Nếu bạn muốn sử dụng các regex thực sự HUGE và vẫn còn xa hoàn hảo, xem các câu trả lời khác. - André Chalella


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

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


293



-1 tại sao tôi muốn dành thời gian của tôi xác nhận địa chỉ email mà thậm chí không vượt qua kiểm soát regex? - kommradHomer
@PaoloBergantino Tôi chỉ không ngoại trừ rằng regex là một ý tưởng tồi và chỉ là một đoán. Địa chỉ không hợp lệ regex là% 100 địa chỉ không hợp lệ. - kommradHomer
@ kommradHomer - địa chỉ "regex không hợp lệ" hầu như 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 sai và sẽ loại trừ các địa chỉ email hợp lệ. Địa chỉ email là name_part@domain_part và thực tế mọi thứ, kể cả một @, có giá trị trong name_part; Địa chỉ foo@bar@machine.subdomain.example.museum là 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
Regex thứ hai trong câu trả lời của chuyến đi stackoverflow.com/a/1373724/69697 là thực tế để sử dụng và hầu như không có âm bản sai. Tôi đồng ý với @kommradHomer ở ​​đâ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 hợp cho các regex 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ể lư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 trên riêng của nó là vô ích, nhưng phục vụ như là một bổ sung tốt để xác nhận serverside. - Ben Regenspan
@ dmur Tôi thừa nhận "hầu như luôn luôn hợp lệ" có lẽ là phóng đại nó, nhưng tôi đã có địa chỉ email của tôi (hoàn toàn hợp lệ và làm việc) bị từ chối bởi các trang web quá thường xuyên, chỉ vì tôi có một .us tên miền hoặc vì tôi đã sử dụng + bên trái của @ - nhiều nơi đã khắc phục các lỗi nghiêm trọng này, nhưng phần địa phương (bên trái của @) có thể là bất cứ điều gì chủ sở hữu tên miền muốn. -> "foo@bar.com"@example.com <- là địa chỉ email hợp lệ. - Stephen P


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à nắm bắt các 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 bắt các lỗi rõ ràng nhất mà người dùng thực hiện và đảm bảo rằng biểu mẫu hầu như là đúng, đó là điều xác thực JavaScript là gì.


282



+1 như gửi email và xem điều gì xảy ra là cách duy nhất thực sự chắc chắn để xác thực địa chỉ email, điều đó không cần phải làm nhiều hơn so với một kết hợp regex đơn giản. - kommradHomer
Bạn vẫn có thể giữ nó đơn giản nhưng làm nhiều hơn một chút để đảm bảo nó có một "." một nơi nào đó sau khi @ theo sau bởi chỉ 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
Tôi nghĩ rằng địa chỉ e-mail có thể chứa không gian. Nó có thể tốt hơn để sử dụng .+@.+ - Sam
/\S+@\S+/.test("áéíóúý@ÁÉÍÓÚÝð")  true - gtournie
@gtournie Không ai quan tâm. Không ai sẽ nhập nội dung đó vào trường email vô tìnhvà đó là tất cả xác thực front-end dành cho: Để ngăn mọi người vô tình nhập sai thông tin, chẳng hạn như tên của họ, trong trường email. - meagar♦


Bản thân HTML5 có 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">
    <input type="submit">
</form>

jsFiddle liên kết

Từ Thông số HTML5:

A địa chỉ e-mail hợp lệ là một chuỗi khớp với emailsản xuất ABNF sau, bộ ký tự 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ố ý của RFC 5322, định nghĩa cú pháp cho đị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, ký tự trắng và trích dẫn) chuỗi trong cách cư xử không quen thuộc với hầu hết người dùng) để đượ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à việc thực hiện đị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])?)*$/

165



điều này là tốt, nhưng vấn đề với điều này là nó phải ở bên trong form thẻ và được gửi bởi submit đầu vào, mà không phải ai cũng có sự sang trọng làm. Ngoài ra, bạn không thể thực sự phong cách thông báo lỗi. - Jason
Tôi đã thêm câu trả lời bên dưới để 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à một xác nhận RFC 822 đầy đủ. - Boldewyn
@ br1: nó không phải là không hợp lệ chỉ vì không có "a" toplevel tên miền tồn tại. whatif mạng nội bộ của bạn có a.a giải quyết cho một số IP? - flying sheep
Loại trường email html 5 chấp nhận email như email của người dùng @ - Puce
Điều này không hoạt động trong Safari - Mr Wilde


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. prettyandsimple@example.com
2. very.common@example.com
3. disposable.style.email.with+symbol@example.com
4. other.email-with-dash@example.com
9. #!$%&'*+-/=?^_`{}|~@example.org
6. "() []:,; @ \\\"! # $% & '* + - / =? ^ _ `{} | ~ .a "@ example.org
7. "" @ example.org (dấu cách giữa dấu ngoặc kép)
8. üñîçøðé@example.com (Ký tự Unicode trong phần địa phương)
9. üñîçøðé@üñîçøðé.com (Ký tự Unicode trong phần tên miền)
10. Pelé@example.com (tiếng Latinh)
11. δοκιμή@παράδειγμα.δοκιμή (Tiếng Hy Lạp)
12. 我 買 @ 屋企. 香港 (Trung Quốc)
13. 甲 斐 @ 黒 川. 日本 (Tiếng Nhật)
14. чебурашка@ящик-с-апельсинами.рф (Cyrillic)

Nó rõ ràng là linh hoạt và cho phép tất cả các nhân vật quốc tế quan trọng, trong khi vẫn thực thi định dạng anything@anything.anything cơ bản. Nó sẽ chặn 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.


95



Đâ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 tạo ra các vấn đề: chúng không cho phép IDN mã hóa hoặc sử dụng một tập hợp TLD cố định hoặc không nhất thiết hạn chế người dùng không sử dụng các ký tự như [@ çµ.ö trong tiền tố email của họ (trước @) hoặc tên miền. JavaScript trong giao diện người dùng (không phải để sử dụng nguyên nhân 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 chặn lỗi chính tả cơ bản. 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 miền-phần hoặc nhập sai @ như . (hoặc ngược lại). Vì lý do chúng ta phải có cách hạn chế hơn ở phía máy chủ. - Hafenkranich
Vì một số lý do kỳ lạ username@domain.com không hoạt động với mẫu này - einstein
@einstein Nó phù hợp với ví dụ của bạn: regex101.com/r/vX2eJ0/1 - Andrew
Theo regex của bạn "_.............. kamal@gmail.com" là hợp lệ, không nên! - Kamal Nayan
Dưới đây là RegEx đã nêu với các ví dụ, nếu bạn muốn tinker với giải pháp này: regex101.com/r/AzzGQU/2 - ryanm