Jak zweryfikować adres e-mail w JavaScript

4370

Czy istnieje wyrażenie regularne do weryfikacji adresu e-mail w JavaScript?

pix0r
źródło
60
proszę dobrze to zrobić, zbyt wiele witryn nie lubi mojego adresu e-mail „[email protected]”, nie wszystkie domeny najwyższego poziomu kończą na 2 lub 3 litery.
Ian Ringrose
41
Jakiekolwiek wsparcie dla użycia wyrażeń regularnych dla wiadomości e-mail, z którymi jestem w 100%. Mam dość tego, że mój adres e-mail „[email protected]” jest nieprawidłowy. Najlepszą opcją jest poproszenie użytkownika o dwukrotne wpisanie wiadomości e-mail, a jeśli MUSISZ użyć narzędzia sprawdzania wyrażeń regularnych, to powiedz użytkownikowi, że jego adres e-mail nie jest prawidłowy i zapytaj, czy jest pewien, że go wpisał dobrze. Nawet posunąć się tak daleko, aby wskazać, CO nie zostało sprawdzone w wyrażeniu regularnym, ale NIE powstrzymuj ich przed przesłaniem formularza.
Soundfx4 15.03.16
17
@ Soundfx4: to powinna być odpowiedź i jako taka powinna zostać zaakceptowana. Sprawdzanie poprawności adresu to głupia rzecz - najlepszy sposób na frustrację klientów. Proszę dwukrotnie wpisać adres i wskazać, że istnieją pewne możliwe problemy (brakuje @, ;comitp.) I pozwolić użytkownikowi je poprawić, jeśli chcą (i zaakceptować wszystko, co mi przysłali)
WoJ
4
Całkowicie zgadzam się z odpowiedzią udzieloną przez WoJ. Format prawidłowego adresu e-mail jest zbyt skomplikowany, aby można go było sprawdzić za pomocą prostego wyrażenia regularnego. Jedynym sposobem, aby upewnić się, że adres jest prawidłowy, jest wypróbowanie go.
Nicole,

Odpowiedzi:

4940

Używanie wyrażeń regularnych jest prawdopodobnie najlepszym sposobem. Można zobaczyć kilka testów tutaj (zaczerpnięte z chromu )

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());
}

Oto przykład regularnej ekspresji, która akceptuje Unicode:

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

Pamiętaj jednak, że nie należy polegać wyłącznie na sprawdzaniu poprawności kodu JavaScript. JavaScript można łatwo wyłączyć. Należy to również zweryfikować po stronie serwera.

Oto przykład powyższego działania:

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>

Rnevius
źródło
574
Ten wyrażenie regularne eliminuje ważne, używane wiadomości e-mail. Nie używaj. Google dla „RFC822” lub „RFC2822”, aby uzyskać poprawne wyrażenie regularne.
Randal Schwartz,
42
To nawet nie akceptuje przykładów w RFC 822. Niektóre proste przypadki nie pasują do \ @ b @ c.com, a(b)@c.com. Zobacz RFC, aby uzyskać więcej. Oto regex, który nie odrzuci żadnych prawidłowych adresów [^ @] + @ [^ @] + \. [^ @] + I chroni przed typowymi błędami.
Vroo
126
@GoodPerson Właśnie próbowałem wysłać e-mail do n @ ai, aby powiedzieć mu, że mają fajny adres e-mail. Ale niestety, Gmail nie pozwoliłby mi. Podejrzewam, że ktokolwiek to ma większe problemy z komunikowaniem się z innymi za pośrednictwem poczty elektronicznej niż tylko sprawdzanie poprawności javascript w mojej witrynie! Ale dziękuję za podjęcie wyzwania.
Ben Roberts,
26
Jest to rozwiązanie, które wydaje się dobre dla większości rodzimych użytkowników języka angielskiego, ale nie przejdzie testu Turcji (patrz Joel Spolsky). Większość liter Unicode jest dozwolona i na przykład w Argentynie adresy takie jak „ñoñó[email protected]” są całkowicie normalne. joelonsoftware.com/articles/Unicode.html
oligofren
139
Nie można zweryfikować adresów e-mail, kropka. Jedynym, który może zweryfikować adres e-mail, jest dostawca adresu e-mail. Na przykład w tej odpowiedzi %[email protected], "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, [email protected], [email protected] , [email protected]podano następujące adresy e-mail: wszystkie są prawidłowe, ale Gmail nigdy nie zezwala na żaden z tych adresów e-mail. Należy to zrobić, akceptując adres e-mail i wysyłając wiadomość e-mail na ten adres e-mail, z kodem / linkiem, który użytkownik musi odwiedzić, aby potwierdzić ważność.
Kevin Fegan
829

Lekko zmodyfikowałem odpowiedź Jaymona dla osób, które chcą naprawdę prostej weryfikacji w postaci:

anystring@anystring.anystring

Wyrażenie regularne:

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

Przykładowa funkcja JavaScript:

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

C. Lee
źródło
69
Możesz wdrożyć coś 20-krotnie dłuższego, co może powodować problemy dla kilku użytkowników i może być nieważne w przyszłości, lub możesz pobrać wersję ImmortalFirefly, aby upewnić się, że przynajmniej starają się, aby wyglądało to naprawdę. W zależności od aplikacji może być bardziej prawdopodobne, że ktoś się wścieknie, ponieważ nie akceptujesz jego niekonwencjonalnych wiadomości e-mail, a nie kogoś, kto powoduje problemy, wprowadzając adresy e-mail, które tak naprawdę nie istnieją (co i tak może zrobić, wprowadzając 100% prawidłowy adres e-mail RFC2822, ale przy użyciu niezarejestrowanej nazwy użytkownika lub domeny). Pozytywne!
user83358
82
@ImmortalFirefly, podany regex będzie faktycznie pasował name@[email protected]. Spróbuj wkleić wiersz w konsoli JavaScript. Uważam, że Twoim zamiarem było dopasowanie tylko całego tekstu, co wymagałoby początku operatora „^” i końca tekstu „$”. Ten, którego używam to/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@[email protected]')
OregonTrail
8
W oparciu o tę weryfikację ten e-mail jest ważny: sprawdź @ this..com
Ehsan
4
Hm Wikipedia twierdzi, że "[email protected]"@example.comjest to prawidłowy adres e-mail. /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('"[email protected]"@example.com') // false. Ups
Bacon Bits,
3
Czy to też nie pozwala @@@.@? : D
hfossli,
762

Dla kompletności, oto kolejny regex zgodny z RFC 2822

Oficjalny standard jest znany jako RFC 2822 . Opisuje składnię, której muszą przestrzegać prawidłowe adresy e-mail. Możesz ( ale nie powinieneś - czytaj dalej ) zaimplementować to z tym wyrażeniem regularnym:

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

(...) Otrzymujemy bardziej praktyczną implementację RFC 2822, jeśli pominiemy składnię za pomocą podwójnych cudzysłowów i nawiasów kwadratowych. Nadal będzie odpowiadać 99,99% wszystkich obecnie używanych adresów e-mail.

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

Kolejną zmianą, którą możesz wprowadzić, jest zezwolenie na dowolną dwuliterową domenę najwyższego poziomu z kodem kraju i tylko określone ogólne domeny najwyższego poziomu. To wyrażenie regularne filtruje fałszywe adresy e-mail, takie jak[email protected] . Będziesz musiał go zaktualizować w miarę dodawania nowych domen najwyższego poziomu .

[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

Tak więc nawet jeśli przestrzegamy oficjalnych standardów, nadal trzeba dokonać kompromisów. Nie ślepo kopiuj wyrażeń regularnych z bibliotek internetowych lub forów dyskusyjnych. Zawsze testuj je na własnych danych i we własnych aplikacjach.

Podkreśl moje

podróżnika
źródło
84
Uwaga: „W dzisiejszym użyciu dzisiaj ” mogło być ważne, gdy kod został napisany, z powrotem w 200x. Kod będzie prawdopodobnie w dalszym ciągu wykorzystywane poza tym konkretnym roku. (Gdybym miał ani grosza za każde „meh, nikt nigdy nie użyłby TLD 4+ z wyjątkiem tych konkretnych”, które musiałem naprawić, mógłbym
zakryć
7
W celu praktycznej implementacji RFC 2822 zakończenie należy nieco zmodyfikować, aby zapobiec rozszerzeniu domeny z pojedynczym 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] /
czy Farrell
5
Pierwszą częścią powinna być również (?: [Az z dużą literą A, aby uniknąć fałszywych negatywów, gdy użytkownik kapitalizuje swój adres e-mail.
Don Rolling
9
@DonRolling Nie rób tego. To nie oznacza tylko „od A do Z, od a do z”, ale oznacza także „[\] ^ _ '”, ponieważ są one pomiędzy „Z” a „a”. Użyj \w, lub lepiej, po prostu małych liter adresu e-mail, zanim cokolwiek z nim zrobisz, ponieważ i tak jest to konwencja.
kirb
5
„Będziesz musiał go zaktualizować w miarę dodawania nowych domen najwyższego poziomu”. Cóż, tyle na teraz - istnieje ponad 1500 uznanych TLD.
Nathan Osman,
377

Wow, tutaj jest dużo złożoności. Jeśli wszystko, co chcesz zrobić, to po prostu złapać najbardziej oczywiste błędy składniowe, zrobiłbym coś takiego:

^\S+@\S+$

Zwykle wychwytuje najbardziej oczywiste błędy popełniane przez użytkownika i zapewnia, że ​​formularz jest w większości poprawny, na tym właśnie polega walidacja JavaScript.

Jaymon
źródło
70
+1, ponieważ wysyłanie wiadomości e-mail i sprawdzanie, co się dzieje, to jedyny naprawdę pewny sposób na sprawdzenie adresu e-mail, nie trzeba robić więcej niż proste dopasowanie wyrażenia regularnego.
kommradHomer
20
Nadal możesz zachować prostotę, ale zrób trochę więcej, aby upewnić się, że ma „”. gdzieś po @, po których następują tylko cyfry lub cyfry, więc rzeczy takie jak ja @ tutaj, ja @ tutaj @ i ja @ herecom są nieprawidłowe ... ^ \ S + @ \ S + [\.] [0-9a-z ] + $
Tim Franklin
14
Myślę, że adresy e-mail mogą zawierać spacje. Prawdopodobnie lepiej jest go użyć.+@.+
Sam
11
/\S+@\S+/.test("áéíóúý@ÁÉÍÓÚÝð") true
gtournie
110
@gtournie Nikogo to nie obchodzi. Nikt nie wchodzi to w polu e-mail przez przypadek , i że wszystko jest front-end dla walidacji: Aby zapobiec przypadkowemu wprowadzeniu złego bit informacji, takich jak ich nazwy, w polu e-mail.
meagar
330

Jest coś, co musisz zrozumieć, gdy tylko zdecydujesz się użyć wyrażenia regularnego do sprawdzania poprawności wiadomości e-mail: Prawdopodobnie nie jest to dobry pomysł . Po tym, jak się z tym pogodzisz, istnieje wiele implementacji, które mogą doprowadzić cię do połowy, ten artykuł ładnie je podsumowuje.

Krótko mówiąc, jedynym sposobem na uzyskanie absolutnej, pozytywnej pewności, że to, co wpisał użytkownik, jest w rzeczywistości wiadomości e-mail, to wysłanie wiadomości e-mail i zobaczenie, co się stanie. Poza tym wszystko to tylko domysły.

Paolo Bergantino
źródło
112
-1 dlaczego miałbym chcieć spędzać czas na sprawdzaniu poprawności adresu e-mail, który nawet nie przechodzi kontroli wyrażeń regularnych?
kommradHomer
63
@kommradHomer - adres „wyrażenie regularne niepoprawne” jest prawie zawsze prawidłowy, ponieważ każde wyrażenie regularne użyte do sprawdzenia poprawności adresu e-mail jest prawie na pewno nieprawidłowe i wyklucza prawidłowe adresy e-mail. Adres e-mail jest name_part@domain_parti praktycznie wszystko, w tym adres @, jest ważny w name_part; Adres foo@[email protected]jest legalny, chociaż należy go zmienić jako foo\@bar@machine..... Gdy wiadomość e-mail dotrze do domeny, np. „Example.com”, ta domena może kierować pocztę „lokalnie”, aby istniały „dziwne” nazwy użytkowników i hostów.
Stephen P
6
Drugi regex w odpowiedzi voyagera na stackoverflow.com/a/1373724/69697 jest praktyczny w użyciu i nie powinien mieć prawie żadnych fałszywych negatywów. Zgadzam się z @kommradHomer tutaj - po co wysyłać e-mail, jeśli nie musisz? Rozumiem odruchową niechęć do niezrozumiałych wyrażeń regularnych i chęć uproszczenia kodu, ale jest to kilka wierszy kodu, które mogą zaoszczędzić serwerowi wielu kłopotów, natychmiast usuwając elementy, które są zdecydowanie nieprawidłowe. Wyrażenie regularne samo w sobie jest nieprzydatne, ale służy jako dobre uzupełnienie walidacji na serwerze.
Ben Regenspan
6
@dmur Przyznaję, że „prawie zawsze ważny” prawdopodobnie przesadza, ale moje (idealnie ważne i działające) adresy e-mail były odrzucane przez strony internetowe zbyt często, tylko dlatego, że mam .usdomenę lub dlatego, że użyłem adresu +po lewej stronie że @- w wielu miejscach mają stałe te skandaliczne błędy, ale część lokalnego (na lewo od @) może być cokolwiek właściciel domeny nie chce. -> „[email protected]"@example.com <- to prawidłowy adres e-mail.
Stephen P
8
@kommradHomer „Niepoprawny adres wyrażenia regularnego to% 100 nieprawidłowy adres”. Przepraszam ... przepraszam? Czy wiesz, ile razy mówiono mi, że [email protected] NIE jest prawidłowym adresem e-mail, skoro w rzeczywistości jest on WAŻNIE WAŻNY ?! Twoja logika jest BARDZO błędna. Przesłałem formularze z e-mailami jako takimi: thisisafakeemailbutit przekaże twó[email protected] I zgadnij co? KTÓRE PODLEGA czekowi REGEX ... ale to NIE jest prawidłowy e-mail (chociaż technicznie JEST, ale obiecuję, że nie istnieje ... ale drapie się po brodzie ). Jak wielu powiedziało, TO JEST ZŁA POMYSŁ ....
Soundfx4
211

Sam HTML5 ma weryfikację adresu e-mail. Jeśli Twoja przeglądarka obsługuje HTML5, możesz użyć następującego kodu.

<form><input type="email" placeholder="[email protected]" required>
    <input type="submit">
</form>

Link do jsFiddle

Ze specyfikacji HTML5 :

Prawidłowy adres e-mail jest ciąg, który pasuje do emailprodukcji następujących ABNF, zestaw znaków, dla których jest 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 >

To wymaganie jest umyślnym naruszeniem RFC 5322, który określa składnię adresów e-mail, która jest jednocześnie zbyt surowa (przed znakiem „@”), zbyt niejasna (po znaku „@”) i zbyt luźna (zezwalająca na komentarze , białych znaków i cytowanych ciągów w sposób nieznany większości użytkowników), które mogą być tutaj przydatne.

Poniższe wyrażenie regularne zgodne z JavaScript i Perl jest implementacją powyższej definicji.

/^[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])?)*$/
Anoop
źródło
29
to dobrze, ale problem polega na tym, że musi znajdować się wewnątrz formtagu i przesłany przez dane submitwejściowe, co nie każdy ma luksus. Ponadto nie można tak naprawdę stylizować komunikatu o błędzie.
Jason
3
Poniżej dodałem odpowiedź, która uwalnia cię od formularza i przesłania. Ale tak, przeglądarki zwykle stosują tylko pewną kontrolę wiarygodności, a nie pełną weryfikację RFC 822.
Boldewyn,
8
@ br1: nie jest nieprawidłowy tylko dlatego, że nie istnieje domena najwyższego poziomu „a”. co jeśli twój intranet ma jakiś adres IP?
latające owce
7
Typ pola e-mail HTML5 przyjmuje wiadomości e-mail takie jak użytkownik @ e
Puce
1
Uwaga @ komentarz Puce'a: e-mail HTML 5 akceptuje, user@emailpodczas gdy na przykład PHP filter_varnie. Może to powodować problemy.
texelate
136

Uważam, że jest to najlepsze rozwiązanie:

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

Umożliwia następujące formaty:

1. [email protected]
2. [email protected]
3. [email protected]
4. [email protected]
9. #!$%&'*+-/=?^_`{}|[email protected]
6. "() []:,; @ \\\"! # $% & '* + - / =? ^ _ `{} | ~ .a "@ example.org
7. „” @ example.org (spacja między cudzysłowami)
8. üñîçøðé@example.com (znaki Unicode w części lokalnej)
9. üñîçøðé@üñîçøðé.com (znaki Unicode w części domeny)
10. Pelé@example.com (łacina)
11. δοκιμή@παράδειγμα.δοκιμή (grecki)
12. 我 買 @ 屋企. 香港 (chiński)
13. 甲 斐 @ 黒 川. 日本 (japoński)
14. чебурашка@ящик-с-апельсинами.рф (cyrylica)

Jest wyraźnie wszechstronny i pozwala na korzystanie ze wszystkich najważniejszych znaków międzynarodowych, przy jednoczesnym egzekwowaniu podstawowego formatu [email protected]. Będzie blokować spacje, które technicznie są dozwolone przez RFC, ale są one tak rzadkie, że cieszę się, że to robię.

Andrzej
źródło
9
Właśnie to robię. Wszystkie te „skomplikowane” odpowiedzi powodują problemy: albo nie zezwalają na IDN z kodem puszystym, albo używają ustalonego zestawu TLD lub niepotrzebnie ograniczają użytkownika, aby nie używał znaków takich jak [@ çµ.ö w prefiksie e-maila (przed @) lub nazwa domeny. JavaScript we froncie (nie do backendowego użycia przyczyny) nie jest wystarczający do sprawdzenia poprawności ze względów bezpieczeństwa. Dlaczego więc nie pomóc użytkownikowi w uniknięciu podstawowych literówek? Podstawowe literówki to: zapomnij TLD lub prefiks użytkownika (przed @) lub część domeny lub wpisz błąd @jako .(lub odwrotnie). Oczywiście musimy być bardziej restrykcyjni po stronie serwera.
Hafenkranich,
Z jakichś dziwnych powodów [email protected]nie działa z tym wzorcem
einstein
2
Zgodnie z wyrażeniem regularnym „_____...... [email protected]” jest ważny, co nie powinno być!
Kamal Nayan
1
Oto Reg
ryanm
7
Ten wyrażenie regularne jest poprawne. Jeśli ktoś podaje swój adres e-mail w taki sposób, a@b@[email protected][email protected]to może zasługuje na zły czas? : D
corysimmons,
94

W nowoczesnych przeglądarkach możesz budować na podstawie odpowiedzi @ Sushil z czystym JavaScript i 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);
}

Złożyłem przykład w skrzypce http://jsfiddle.net/boldewyn/2b6d5/ . W połączeniu z wykrywaniem funkcji i sprawdzaniem poprawności gołych kości w odpowiedzi Squirtle's , uwalnia cię od masakry wyrażeń regularnych i nie zawodzi w starych przeglądarkach.

Boldewyn
źródło
4
Jest to sprytny pomysł, aby rozwikłać problem, ale nie działa, ponieważ przeglądarki mają również kiepską weryfikację. Np. .@aSprawdza się jak truew aktualnych wersjach Chrome, Firefox i Safari.
Hank
13
@HenryJackson Niestety, w tym przypadku tak. Jest tak, ponieważ zgodnie z RFC, który jest prawidłowym adresem e-mail (pomyśl intranety). Przeglądarki byłyby z grilla, gdyby sprawdzały zbyt wąsko i produkowały fałszywe negatywy.
Boldewyn
3
Zaktualizowano, aby zawierał wykrywanie funkcji i płynną degradację, teraz nie działa w nowych przeglądarkach, ale używa wyrażeń regularnych, które lubisz.
Ronny,
Niezłe rozwiązanie. Niestety dotyczy to tylko HTML5 +.
Edward Olamisan
3
Jest to zdecydowanie najlepsze rozwiązanie pierwotnego pytania. Tak, używa HTML5, ale większość aplikacji, które wymagają tego poziomu dokładności, z pewnością i tak będzie już polegać na HTML5 w inny sposób, więc kwestia sporna. Nie jest możliwe, abyśmy kiedykolwiek ustalili, czy czyjś e-mail jest prawidłowy, nie zmuszając go do zweryfikowania go, więc naprawdę nie powinniśmy poświęcać tyle czasu lub wysiłku na jego weryfikację. Szybkie sprawdzenie jakiejkolwiek oczywistej składni lub próby niegrzeczności to wysiłek, który powinniśmy poświęcić.
Woody Payne
69

To jest poprawna wersja RFC822.

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);
}
bvl
źródło
Adresy IDN nie są sprawdzane (info@üpöü.com)
DAH
66

JavaScript może pasować do wyrażenia regularnego:

emailAddress.match( / some_regex /);

Oto wyrażenie regularne RFC22 dla wiadomości e-mail:

^((?>[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)>)$
Ben Scheirman
źródło
1
@Kato: Używa niekompatybilnych rozszerzeń, w tym (?>do zatrzymania powrotu i (?<angle><)…(?(angle)>)unikania długich |.
Ry-
60

Wszystkie adresy e-mail zawierają symbol „at” (tj. @). Sprawdź ten konieczny warunek:

email.indexOf("@") > 0

Nie przejmuj się niczym bardziej skomplikowanym. Nawet jeśli potrafisz doskonale ustalić, czy wiadomość e-mail jest poprawna pod względem składniowym RFC, nie powiedziałbyś, czy należy ona do osoby, która ją dostarczyła. To jest naprawdę ważne.

Aby to przetestować, wyślij wiadomość sprawdzającą poprawność.

Panika pułkownika
źródło
3
co jeśli będzie więcej niż jeden symbol „@”? inne ograniczone symbole? Tej weryfikacji nie można ufać ...
eatmypants
56

Prawidłowe sprawdzenie poprawności adresu e-mail zgodnie z RFC nie jest czymś, co można osiągnąć za pomocą wyrażenia regularnego jednowierszowego. Artykuł z najlepszym rozwiązaniem, które znalazłem w PHP, to: Jaki jest prawidłowy adres e-mail? . Oczywiście został przeniesiony na Javę. Myślę, że ta funkcja jest zbyt złożona, aby można ją było przenieść i używać w JavaScript. Port JavaScript / node.js: https://www.npmjs.com/package/email-addresses .

Dobrą praktyką jest sprawdzanie poprawności danych na kliencie, ale dokładnie sprawdź poprawność na serwerze. Mając to na uwadze, możesz po prostu sprawdzić, czy ciąg znaków wygląda na prawidłowy adres e-mail na kliencie i wykonać ścisłą kontrolę na serwerze.

Oto funkcja JavaScript, której używam do sprawdzania, czy ciąg znaków wygląda na prawidłowy adres e-mail:

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);
}

Wyjaśnienie:

  • lastAtPos < lastDotPos: Ostatni @powinien być przedostatni, .ponieważ @nie może być częścią nazwy serwera (o ile wiem).

  • lastAtPos > 0: Powinno być coś (nazwa użytkownika e-maila) przed ostatnim @.

  • str.indexOf('@@') == -1: Nie powinno być @@adresu. Nawet jeśli @pojawia się jako ostatni znak w e-mailowej nazwie użytkownika, należy go zacytować, tak "aby znajdował się między tym @a ostatnim @adresem.

  • lastDotPos > 2: Na przykład powinny być co najmniej trzy znaki przed ostatnią kropką [email protected].

  • (str.length - lastDotPos) > 2: Po ostatniej kropce powinno być wystarczającej liczby znaków, aby utworzyć domenę dwóch znaków. Nie jestem pewien, czy nawiasy są konieczne.

Miloš Rašić
źródło
Ta fn wygląda ładnie, ale czy jest lepsza niż regex napisany w najwyższej odpowiedzi?
Atul Goyal
4
Wątpię. Używam go tylko do sprawdzania, czy ciąg znaków wygląda jak wiadomość e-mail, i zostawiam szczegóły kodowi po stronie serwera.
Miloš Rašić
Sprawdza poprawność OK każdego łańcucha, takiego jak „aaaa”, tzn. Bez „@” i „.”
Giennadij Shumakher
1
Nie powinno. lastIndexOf () powinien zwrócić -1, jeśli nie znajdzie igły.
Miloš Rašić
„Nawet jeśli @pojawia się jako ostatni znak w e-mailowej nazwie użytkownika, należy go zacytować, tak "aby znajdował się między tym @a ostatnim @adresem”. Co "@@"@example.com?
Ry-
47

Zostało to skradzione z 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;}
Adam McKee
źródło
7
To odfiltrowuje zawsze popularne .museumi .traveldomeny (ze względu na limit 4 .
znaków
4
Zmiana {2,4} na {2,6} nie będzie problemem
Anton N
11
@Anton N: Ma też około miliarda innych problemów; finał {2,4}jest jedynie użytecznym wskaźnikiem tego (jak w „gdy zobaczysz ten błąd, inni prawdopodobnie będą w pobliżu”). Najbardziej podstawowe z nich jest brak +w lokalnej części; to pole komentarza jest zbyt małe, aby wskazać wszystkie błędy popełnione powyżej.
Piskvor opuścił budynek
37
Dlaczego nie możesz tego zrobić return filter.test(email.value);?
MT.
3
@AntonN: Teraz mamy ponad 10 znaków TLD ( xn--clchc0ea0b2g2a9gcd). Nadal nie ma problemu?
Piskvor opuścił budynek
42

Zrób to:

[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])?

Dlaczego? Opiera się na RFC 2822 , który jest standardowym WSZYSTKIM adresem e-mail, do którego MUSI się stosować. I nie jestem pewien, dlaczego zawracasz sobie głowę czymś „prostszym” ... i tak skopiujesz i wkleisz;)

Często, gdy przechowuję adresy e-mail w bazie danych, robię je małymi literami, a w praktyce wyrażenia regularne można zwykle oznaczać bez rozróżniania wielkości liter. W takich przypadkach jest to nieco krótsze:

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

Oto przykład użycia go w JavaScript (z flagą bez rozróżniania wielkości liter ina końcu).

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('[email protected]') );

Uwaga :
Technicznie niektóre wiadomości e-mail mogą zawierać cudzysłowy w sekcji przed @symbolem ze znakami zmiany znaczenia w cudzysłowach (aby użytkownik poczty e-mail mógł być wstrętny i zawierać elementy takie jak @i "..."tak długo, jak jest napisane w cudzysłowach). NIKT NIE ROBI TEGO! To jest przestarzałe. Ale JEST zawarty w prawdziwym standardzie RFC 2822 i tutaj pominięty.

Więcej informacji: http://www.regular-expressions.info/email.html

Ryan Taylor
źródło
@Kondal w kodzie javascript nie jest rozróżniana wielkość liter z powodu /iflagi na końcu wyrażenia regularnego. Wspominam o tym, że musi to być porównanie bez rozróżniania wielkości liter, ale ja to wyjaśnię.
Ryan Taylor,
Pracował dla mnie jako urok
Alex
40

Naprawdę nie mogę się doczekać rozwiązania tego problemu. Zmodyfikowałem więc wyrażenie regularne sprawdzania poprawności wiadomości e-mail powyżej

  • Oryginalny
    /^(([^<>()\[\]\\.,;:\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,}))$/

  • Zmodyfikowano
    /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()\.,;\s@\"]+\.{0,1})+[^<>()\.,;:\s@\"]{2,})$/

przekazać przykłady z adresu e-mail Wikipedii .

Możesz zobaczyć wynik tutaj .

wprowadź opis zdjęcia tutaj

Keith Lee
źródło
To wydaje się być dobrym rozwiązaniem, działa również z nowymi TLD i 1-mailowymi e-mailami
Mark Hughes
Dlaczego nie [email protected]powinno być poprawne? To ważna walizka narożna.
Valerio Bozz
24

Nie należy używać wyrażeń regularnych do sprawdzania poprawności ciągu wejściowego w celu sprawdzenia, czy jest to wiadomość e-mail. Jest to zbyt skomplikowane i nie obejmuje wszystkich przypadków.

Teraz, ponieważ możesz pokryć tylko 90% przypadków, napisz coś takiego:

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

Możesz to udoskonalić. Na przykład poprawne jest „aaa @”. Ale ogólnie masz sedno. I nie daj się zwieść ... Proste 90% rozwiązanie jest lepsze niż 100% rozwiązanie, które nie działa.

Świat potrzebuje prostszego kodu ...

Zo72
źródło
15
Umożliwia to wpisanie tak wielu nieprawidłowych adresów e-mail, że jest to bezużyteczna rada.
cazlab
3
Debugowanie wcale nie musi być niemożliwe. W tym wątku jest wiele dobrych przykładów, które sprawdzają się dalej niż „czy ma w nim znak„ @ ”. Twój przykład pozwala na uznanie„ u @ ”za prawidłowy adres e-mail. Przynajmniej oceń, czy istnieje domena, czy coś, co może być domenę Yours jest przykładem tego, co nazwałbym nie jestem pewien, dlaczego ty bronisz go, ponieważ jest zdecydowanie najniższy odpowiedź oceniane w wątku. „agresywnie leniwy kodowanie.”.
cazlab
3
@cazlab może masz rację. W końcu zostałem odrzucony. W przeciwieństwie do ciebie, nie sądzę, aby jakikolwiek z powyższych kodów zawierał łatwe do debugowania fragmenty. Moje podejście „agresywnie leniwe” można w razie potrzeby ulepszyć.
Zo72
3
Czym różni się to od używania wyrażenia regularnego? (.+)@(.*)robi to samo i krócej.
burza śnieżna
4
+1 - Jeśli celem jest upewnienie się, że użytkownik przynajmniej próbował podać adres e-mail, to sprawdź, czy można ustalić, czy adres e-mail zdecydowanie NIE jest adresem e-mail świetne rozwiązanie. Dobrym przykładem może być, jeśli chcesz, aby nazwa użytkownika była adresem e-mail. Jeśli użytkownik wpisze „sexy_chick_23”, można użyć tego wyrażenia regularnego, aby dać mu znać, że oczekuje się wiadomości e-mail. Jeśli wpisane zostanie coś, co wygląda jak wiadomość e-mail, ale tak nie jest, użytkownik nigdy nie otrzyma wiadomości e-mail z potwierdzeniem, a proces rejestracji nigdy nie zostanie zweryfikowany.
Chris Dutrow,
23

Wystarczy sprawdzić, czy podany adres e-mail jest prawidłowy, czy nie używa HTML.

<input type="email"/>

Nie ma potrzeby pisania funkcji do sprawdzania poprawności.

Uczeń
źródło
4
IE <10 nie obsługuje tego, podobnie jak własna przeglądarka Androida.
Frank Conijn
7
Upvoting. IE <10 nie żyje.
Michael Scheper,
19

Trudno jest uzyskać poprawność e-maila w 100% poprawną. Jedynym prawdziwym sposobem na poprawienie tego byłoby wysłanie testowego e-maila na konto. To powiedziawszy, istnieje kilka podstawowych kontroli, które mogą pomóc upewnić się, że otrzymujesz coś rozsądnego.

Niektóre rzeczy do poprawy:

Zamiast nowego RegExp, spróbuj napisać regexp:

if (reg.test(/@/))

Po drugie, sprawdź, czy po @znaku pojawia się kropka , i upewnij się, że między @s i kropkami są znaki .

jacobangel
źródło
19

Oto jak to robi walidator węzła :

/^(?:[\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])\]))$/
pera
źródło
14

Użyj tego kodu w funkcji sprawdzania poprawności:

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

W przeciwnym razie możesz użyć jQuery . Reguły wewnętrzne definiują:

eMailId: {
    required: true,
    email: true
}
Orchidea
źródło
1
abc@xyzjest idealnie poprawnym adresem e-mail, który nie jest rozpoznawany przez wyrażenie regularne.
Toto
3
Nie, nie jest. Prawidłowy wzorzec e-mail to coś@something.something, abc @ xyz nie pasuje do tego wzorca. To nie jest poprawny adres.
Orchidea
5
Czy byłeś na stronie wikipedia? TLD to poprawna nazwa hosta. Tak samo abc@tldjest prawidłowy adres e-mail.
Toto
2
Jedynym sposobem na sprawdzenie adresu e-mail jest wysłanie wiadomości e-mail, a następnie poczekanie na odpowiedź. Oprócz tego tutaj jest adres URL, na którym możesz sprawdzić, czy twój adres jest zgodny z RFC822: mythic-beasts.com/~pdw/cgi-bin/emailvalidate . Widać, że abc @ xyz jest prawidłowym adresem dla RFC822.
Toto
14

Aktualizacja Regex 2018! Spróbuj tego

let val = '[email protected]';
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');
}

pełna wersja maszynopisu

//
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);

więcej informacji https://git.io/vhEfc

Juan Pablo
źródło
Nie powiodło się to w przypadku standardowego adresu [email protected]
ricks
1
@ Ricki to po prostu nieprawda. Sprawdź ponownie
malimo
13

Rozwiązanie, które nie sprawdza istnienia TLD, jest niekompletne.

Prawie wszystkie odpowiedzi na te pytania sugerują użycie Regex do sprawdzania poprawności adresów e-mail. Myślę, że Regex nadaje się tylko do podstawowej weryfikacji. Wygląda na to, że sprawdzanie poprawności adresów e-mail to tak naprawdę dwa osobne problemy:

1- Sprawdzanie poprawności formatu wiadomości e-mail: Upewnij się, że wiadomość e-mail jest zgodna z formatem i wzorcem wiadomości e-mail w RFC 5322 i czy TLD faktycznie istnieje. Lista wszystkich prawidłowych TLD znajduje się tutaj .

Na przykład, mimo że adres [email protected]przejdzie wyrażenie regularne, nie jest to prawidłowy adres e-mail, ponieważccc nie jest domeną najwyższego poziomu przez IANA.

2- Upewnij się, że e-mail faktycznie istnieje: W tym celu jedyną opcją jest wysłanie użytkownikom wiadomości e-mail .

bman
źródło
13

Ponownie sprawdź poprawność adresu e-mail

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])+
Prabhat Kasera
źródło
Nie widzę Twojego wyrażenia regularnego w RFC5322: tools.ietf.org/html/rfc5322 - czy jest jakiś błąd?
Kamil Kiełczewski
„Najlepszy regex w historii”? Być może jakieś wyjaśnienie?
connectyourcharger
Dlaczego powiedziałeś, że to najlepsze rozwiązanie ze wszystkich, czy możesz wyjaśnić coś więcej, proszę?
nancoder
Nie jestem w stanie przypomnieć sobie, dlaczego napisałem „najlepszy regex w historii”. Przepraszam, jeśli wam to przeszkadza.
Prabhat Kasera
12

Oto bardzo dobra dyskusja na temat używania wyrażeń regularnych do sprawdzania poprawności adresów e-mail; „ Porównywanie adresu e-mail sprawdzającego poprawność wyrażeń regularnych

Oto aktualne najważniejsze wyrażenie, które jest kompatybilne z JavaScript, w celach informacyjnych:

/^[-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
Eric Schoonover
źródło
9
-1 Biała lista pozostawia wiele do życzenia - zwłaszcza że tęskniłeś .jobs. Ponadto istnieją IDN na żywo (z których większość, przyznaję, zostały oficjalnie zatwierdzone dopiero po twoim stanowisku - np. .中國W czerwcu 2010 r., Ale większość z nich działa od lat).
Piskvor opuścił budynek
2
-1 nie używaj stałych domen najwyższego poziomu. Zawsze (i będzie na przykład 2013) można dodawać nowe tld.
miho
Potwierdzono setki nowych TLD. Ta odpowiedź jest nieprawidłowa i nigdy nie powinna być używana.
Dean Meehan
Tak. Powiedziałem to w 2011 roku i powiem to jeszcze raz: biała lista „specjalnych” domen z czasem się pogorszy, ponieważ więcej TLD zostanie zatwierdzonych. Istnieje ponad 100 całkowicie prawidłowych TLD niezgodnych z powyższą białą
listą
Jest 2015. Twój wyraz nie jest praktyczny. Powinieneś usunąć tę odpowiedź, ale prawdopodobnie jesteś zbyt zajęty naprawianiem wszystkich stron, na których umieszczasz to wyrażenie. Dobrze?
Eric Leroy,
12

Najwyraźniej to wszystko:

/^([\w\!\#$\%\&\'\*\+\-\/\=\?\^\`{\|\}\~]+\.)*[\w\!\#$\%\&\'\*\+\-\/\=\?\^\`{\|\}\~]+@((((([a-z0-9]{1}[a-z0-9\-]{0,62}[a-z0-9]{1})|[a-z])\.)+[a-z]{2,6})|(\d{1,3}\.){3}\d{1,3}(\:\d{1,5})?)$/i

Zaczerpnięte z http://fightingforalostcause.net/misc/2006/compare-email-regex.php z 1 października 10.

Ale to oczywiście ignoruje internacjonalizację.

Félix Saparelli
źródło
12

W przeciwieństwie do squirtle , tutaj jest złożone rozwiązanie, ale wykonuje świetną robotę, sprawdzając poprawność wiadomości e-mail:

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);
} 

Użyj tak:

if (isEmail('[email protected]')){ console.log('This is email is valid'); }
steve
źródło
10
Nie potrzebujesz tego == truena swoim przykładzie.
Luke Alderton,
11

Moja znajomość wyrażeń regularnych nie jest zbyt dobra. Dlatego najpierw sprawdzam ogólną składnię za pomocą prostego wyrażenia regularnego, a następnie sprawdzam bardziej szczegółowe opcje z innymi funkcjami. To może nie być najlepsze rozwiązanie techniczne, ale w ten sposób jestem bardziej elastyczny i szybszy.

Najczęstsze błędy, które napotkałem, to spacje (szczególnie na początku i na końcu), a czasami podwójna kropka.

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('[email protected]'); // Returns false
check_email(' [email protected]'); // Returns false
check_email('[email protected]'); // Returns true
Linkmichiel
źródło
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>
Tugrul Asik
źródło
Może jeśli dodasz wyjaśnienie lub opis, aby do niego dołączyć? Nie sądzę, że naprawdę musisz pokazywać HTML; wszyscy ludzie są zainteresowani javascript i regex. Jeśli zredukujesz swoją odpowiedź do samego jacascript i dodasz do tego małą nutkę, dam ci głos.
bgmCoder
9

Szukałem Regex w JS, który przechodzi wszystkie przypadki testowe adresów e-mail:

No to ruszamy :

http://regexr.com/3f07j

LUB wyrażenie regularne:

Regex = /(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@[*[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+]*/
Negin
źródło
8

Wyrażenie regularne dostarczone przez Microsoft w ramach ASP.NET MVC to

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

Które zamieszczam tutaj na wypadek, gdyby był wadliwy - chociaż zawsze był idealny dla moich potrzeb.

Neil Thompson
źródło
1
Nie zezwala na + w części nazwy e-maila.
Paul Go