Pytanie Jak sprawdzić poprawność adresu e-mail w JavaScript?


W jaki sposób można zweryfikować adres e-mail w JavaScript?


3259


pochodzenie


Chociaż to rozwiązanie może być proste, jestem pewien, że jest to jedna z tych przydatnych rzeczy, na które ludzie będą szukać w Google i zasługuje na własny wpis na stronie Gdyby tylko Google byłby pierwszym miejscem do patrzenia :) Wystarczy spojrzeć na duplikaty tego zamkniętego co jakiś czas. - Esteban Küber
Jestem pewien, że jest to jedna z tych przydatnych rzeczy, za które ludzie będą szukać Googlowania  lol, tak naprawdę właśnie natknąłem się na to pytanie! - Peter C
możliwy duplikat Jakie jest najlepsze wyrażenie regularne do sprawdzania poprawności adresów e-mail? - Brad Mace
proszę, masz rację, zbyt wiele stron internetowych nie podoba mi się mój adres e-mail "firstName@secondName.name", nie wszystkie domeny najwyższego poziomu kończą go 2 lub 3 litery. - Ian Ringrose
Jakakolwiek obsługa sprawdzeń regex dla wiadomości e-mail, z którymi jestem w 100% przeciw. Jestem zmęczony otrzymaniem informacji, że mój adres e-mail "foo+bar@gmail.com" jest nieprawidłowy. Najlepszym rozwiązaniem jest poproszenie użytkownika o dwukrotne wpisanie swojej wiadomości e-mail, a jeśli MUSISZ skorzystać z modułu sprawdzania poprawności, powiedz użytkownikowi, że jego adres e-mail nie jest poprawny i zapytaj, czy jest pewien, że go wpisali. dobrze. Nawet posunąć się do stwierdzenia, CO nie sprawdził w sprawdzaniu regexp, ale NIE przeszkadzać im w przesłaniu formularza. - Soundfx4


Odpowiedzi:


Za pomocą wyrażenia regularne to prawdopodobnie najlepszy sposób. Możesz zobaczyć kilka testów tutaj (pochodzi z chrom)

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

Oto przykład regularnego wyrażenia, które akceptuje kod Unicode:

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

Należy jednak pamiętać, że nie należy polegać wyłącznie na sprawdzaniu poprawności JavaScriptu. JavaScript można łatwo wyłączyć. To powinno być również sprawdzone po stronie serwera.

Oto przykład powyższych działań:

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



To wyrażenie eliminuje prawidłowe, używane wiadomości e-mail. Nie używaj. Google dla "RFC822" lub "RFC2822", aby uzyskać prawidłowe wyrażenie regularne. - Randal Schwartz
@Randall: Czy możesz podać przykład adresu e-mail, na który to nie pozwoli? - rossipedia
@GoodPerson Próbowałem wysłać e-mail na adres n @ ai, aby poinformować go, że ma fajny adres e-mail. Ale niestety, gmail mi nie pozwolił. Podejrzewam, że ktokolwiek ma większe problemy z komunikowaniem się z innymi za pośrednictwem poczty e-mail niż tylko moja strona javascript walidacji! Ale dzięki za podjęcie wyzwania. - Ben Roberts
Dla wszystkich ludzi, którzy komentują, że jest to "wystarczająco dobre": spójrz, po prostu myślisz o tym problemie. W porządku. To wybór, który możesz wybrać dla swoich użytkowników. Nie jestem na to zły. Ale, wiesz, technicznie rzecz biorąc, jesteś demonstracyjnie, prawdopodobnie źle. - Wayne Burkett
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 ta odpowiedź mówi o tych adresach e-mail: %2@gmail.com, "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, _@gmail.com, 1@gmail.com , 1_example@something.gmail.com są poprawne, ale Gmail nigdy nie zezwoli na żaden z tych adresów e-mail. Powinieneś 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


Tylko dla kompletności, tutaj masz inne wyrażenie regularne zgodne z RFC 2822

Oficjalny standard jest znany jako RFC 2822. Opisuje składnię, do której muszą się stosować prawidłowe adresy e-mail. Możesz (ale nie powinieneś - Czytaj) implementuj to za pomocą tego wyrażenia regularnego:

(?:[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. Wciąż będzie pasował 99,99% wszystkich adresów e-mail w rzeczywistej eksploatacji już dziś.

[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ą możliwą zmianą jest zezwolenie na stosowanie dwuliterowej domeny najwyższego poziomu dla kodu kraju i tylko określonych ogólnych domen najwyższego poziomu. Ten regex filtruje fałszywe adresy e-mail, takie jak asdf@adsf.adsf. ty będzie musiał zaktualizować go, gdy zostaną dodane nowe domeny 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 po spełnieniu oficjalnych standardów, wciąż istnieją kompromisy. Nie wolno ślepo kopiować wyrażeń regularnych z bibliotek internetowych lub forów dyskusyjnych. Zawsze testuj je na własnych danych i własnych aplikacjach.

Podkreśl moje


612



NB: "W rzeczywistym użyciu dzisiaj"może być ważne, gdy kod został zapisany, wraca w 200x. Kod będzieprawdopodobnie pozostaną w użyciu poza tym konkretnym rokiem. (Gdybym miał centa za każde "meh, nikt nigdy nie użyje 4 + -letniej TLD z wyjątkiem tych konkretnych" musiałem naprawić, mogłem zakręcić światowym rynkiem miedzi i niklu;)) - Piskvor
W celu praktycznej implementacji RFC 2822, zakończenie powinno zostać nieco zmodyfikowane, aby zapobiec rozszerzeniom pojedynczej domeny. / [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
Pierwsza część powinna być (?: [A-z wielką literą A, aby uniknąć fałszywych negatywów, gdy użytkownik kapitalizuje swój adres e-mail. - Don Rolling
Dzięki specyfikacji, d._.___d@gmail.com nie jest prawidłowym adresem e-mail, ale nadal wykrywa, że ​​jest poprawny - Raptor
@DonRolling Nie rób tego. To nie znaczy tylko "od A do Z, a do z", ale oznacza także "[\] ^ _` ", ponieważ takie są pomiędzy "Z" i "a". Posługiwać się \wlub lepiej, po prostu wpisz adres e-mail, zanim zrobisz cokolwiek, ponieważ i tak jest to konwencja. - kirb


Lekko zmodyfikowałem odpowiedź Jaymona dla ludzi, którzy 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);
}

551



/\S+@\S+\.\S+/.test('name@again@example.com')  true - neoascetic
@neoascetic Shazam! /[^\s@]+@[^\s@]+\.[^\s@]+/.test('name@again@example.com') // false - n0nag0n
Możesz zaimplementować coś 20 razy, co może spowodować problemy dla kilku użytkowników i może nie być ważne w przyszłości, lub możesz pobrać wersję ImmortalFirefly, aby upewnić się, że przynajmniej starają się, aby wyglądała prawdziwie. W zależności od aplikacji może być bardziej prawdopodobne, że ktoś się wścieknie, ponieważ nie akceptujesz niekonwencjonalnej wiadomości e-mail, a nie osoby, która powoduje problemy, wprowadzając adresy e-mail, które tak naprawdę nie istnieją (które mogą mimo wszystko zrobić, wprowadzając w 100% prawidłowy adres e-mail RFC2822, ale przy użyciu niezarejestrowanej nazwy użytkownika lub domeny). Rewizja! - user83358
@ImmortalFirefly, podane przez Ciebie wyrażenie regularne będzie pasować name@again@example.com. Spróbuj wkleić linię do konsoli JavaScript. Uważam, że twoim zamiarem było dopasowanie tylko całego tekstu, który wymagałby początku tekstu "^" i końca tekstu operatorów "$". Ten, którego używam, jest /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com') - OregonTrail
Czy ludzie przestaną narzekać na fałszywe alarmy? Jest to proste regex do złapania 95% błędów. Jeśli chcesz używać naprawdę OGROMNYCH wyrażeń regularnych i nadal są dalekie od doskonałościzobacz inne odpowiedzi. - André Chalella


Jest coś, co musisz zrozumieć, gdy zdecydujesz się użyć wyrażenia regularnego do sprawdzania poprawności e-maili: To chyba nie jest dobry pomysł. Kiedy już się z tym pogodzisz, istnieje wiele implementacji, które mogą cię w tym miejscu osiągnąć, ten artykuł ładnie je podsumowuje.

Krótko mówiąc, jest to jedyny sposób, aby być absolutnie, pozytywnie pewnym, że to, co podał użytkownik, jest w istocie e-mailem, który polega na wysłaniu e-maila i zobaczeniu, co się stanie. Poza tym wszystko to tylko domysły.


293



-1 dlaczego chciałbym spędzać czas sprawdzając poprawność adresu e-mail, który nie przekazuje nawet kontroli regex? - kommradHomer
@PaoloBergantino Po prostu nie wykluczam, że regex to zły pomysł i tylko zgadnij. Nieprawidłowy adres regularny to% 100 i nieprawidłowy adres. - kommradHomer
@kommradHomer - adres "regex invalid" prawie zawsze jest prawidłowy, ponieważ każde wyrażenie regularne używane do sprawdzania poprawności adresu e-mail jest prawie na pewno błędne i wyklucza poprawne adresy e-mail. Adres e-mail to name_part@domain_part i praktycznie wszystko, włącznie z na @, jest ważny w name_part; Adres foo@bar@machine.subdomain.example.museum jest legalne, chociaż musi zostać usunięte jako foo\@bar@machine..... Gdy e-mail dotrze do domeny, np. "example.com" ta domena może trasować pocztę "lokalnie", więc "dziwne" nazwy użytkowników i hosty mogą istnieć. - Stephen P
Drugie wyrażenie w odpowiedzi na odpowiedź voyagera stackoverflow.com/a/1373724/69697jest praktyczny w użyciu i nie powinien zawierać 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ń i chęci zachowania prostoty kodu, ale jest to kilka linii kodu, które mogą zaoszczędzić serwerowi wiele kłopotów, natychmiast usuwając elementy, które są zdecydowanie nieważne. Samo wyrażenie regularne nie jest pomocne, ale służy jako dobre uzupełnienie sprawdzania poprawności serwerów. - Ben Regenspan
@dmur Zgadzam się, że "prawie zawsze ważny" to prawdopodobnie przesada, ale moje (całkowicie poprawne i działające) adresy e-mail zostały odrzucone przez strony internetowe zbyt często, tylko dlatego, że mam .us domeny lub ponieważ użyłem a + na lewo od @ - wiele miejsc naprawiło te rażące błędy, ale lokalna część (po lewej stronie) może być byle co właściciel domeny chce. -> "foo@bar.com"@example.com <- jest prawidłowym adresem e-mail. - Stephen P


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

\S+@\S+

Zwykle przechwytuje najbardziej oczywiste błędy, jakie popełnia użytkownik, i zapewnia, że ​​formularz jest w większości prawidłowy, o to właśnie chodzi w przypadku sprawdzania poprawności JavaScriptu.


282



+1 jako wysyłanie wiadomości e-mail i sprawdzanie, co się dzieje, jest jedynym naprawdę pewnym sposobem sprawdzania poprawności adresu e-mail, nie ma potrzeby robienia czegoś więcej niż zwykłe dopasowanie do wyrażenia regularnego. - kommradHomer
Nadal możesz zachować prostotę, ale zrób trochę więcej, aby mieć "." gdzieś po znaku @, po którym następują tylko cyfry lub cyfry, więc rzeczy takie jak ja @ tutaj, mnie @ tutaj @ i ja @ herecom są nieprawidłowe ... ^ \ S + @ \ \ S + [\.] [0-9a-z ] + $ - Tim Franklin
Myślę, że adresy e-mail mogą zawierać spacje. Prawdopodobnie lepiej jest użyć .+@.+ - Sam
/\S+@\S+/.test("áéíóúý@ÁÉÍÓÚÝð")  true - gtournie
@ Gtournie Nikt nie dba. Nikt nie będzie wchodził w to w pole e-mail przez przypadek, a to wszystko jest sprawdzianem front-endowym: Aby zapobiec przypadkowemu wprowadzeniu przez przypadek niewłaściwego fragmentu informacji, na przykład jego nazwiska, w polu e-mail. - meagar♦


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

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

jsFiddle połączyć

Od Specyfikacja HTML5:

ZA Poprawny adres email jest łańcuchem pasującym do emailprodukcja następującego ABNF, którego zestaw znaków to 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 to umyślne naruszenie RFC 5322, który definiuje składnię dla adresów e-mail, która jest jednocześnie zbyt ścisła (przed znakiem "@"), zbyt niejasna (po znaku "@") i zbyt luźna (pozwalająca na komentarze, znaki odstępu i cytowane łańcuchy w sposób nieznajomy większości użytkowników), aby były tutaj przydatne.

Następujące 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])?)*$/

165



to jest dobre, ale problem polega na tym, że musi być wewnątrz form tag i przesłany przez a submit wkład, którego nie każdy ma luksus robić. Poza tym nie można tak naprawdę zaprojektować komunikatu o błędzie. - Jason
Dodałem poniżej odpowiedź, która zwalnia Cię z formularza i przesyła. Ale tak, przeglądarki zazwyczaj stosują tylko pewną kontrolę wiarygodności, a nie pełną weryfikację RFC 822. - Boldewyn
@ br1: nie jest nieprawidłowy tylko dlatego, że nie istnieje żadna "domena". jaki jest twój intranet na jakiś adres IP? - flying sheep
Typ pola e-mail w formacie HTML5 akceptuje wiadomości e-mail, takie jak użytkownik @ e-mail - Puce
To nie działa w Safari - Mr Wilde


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

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

Pozwala na następujące formaty:

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 (odstęp między cytatami)
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. чебурашка@ящик-с-апельсинами.рф (Cyrillic)

Jest wszechstronny i pozwala na najważniejsze postacie międzynarodowe, a jednocześnie egzekwuje podstawowy format wszystkiego. Będzie blokować miejsca, które są technicznie dozwolone przez RFC, ale są tak rzadkie, że cieszę się z tego.


95



Właśnie to robię. Wszystkie te "skomplikowane" odpowiedzi powodują problemy: albo nie pozwalają na małe numery IDN, albo używają ustalonego zestawu TLD, albo niepotrzebnie ograniczają użytkownika, aby nie używał znaków takich jak [@ çμ.ö w swoim przedrostku e-mail (przed @) lub nazwa domeny. JavaScript w interfejsie użytkownika (nie dla backendu użycia przyczyny) nie jest wystarczający do sprawdzania poprawności ze względów bezpieczeństwa. Dlaczego więc nie tylko pomóc użytkownikowi zapobiec podstawowej literówki. Podstawowe literówki to: zapomnij o TLD lub prefiksie użytkownika (przed @) lub o domenie lub pomyłce @ tak jak . (lub odwrotnie). Ponieważ musimy być bardziej restrykcyjni po stronie serwera. - Hafenkranich
Z jakichś dziwnych powodów username@domain.com nie działa z tym wzorcem - einstein
@einstein To pasuje do twojego przykładu: regex101.com/r/vX2eJ0/1 - Andrew
Zgodnie z twoim wyrażeniem "_.............. kamal@gmail.com" jest prawidłowe, co nie powinno być! - Kamal Nayan
Oto podane RegEx z przykładami, jeśli chcesz majstrować przy tym rozwiązaniu: regex101.com/r/AzzGQU/2 - ryanm


W nowoczesnych przeglądarkach możesz zbudować na podstawie odpowiedzi @ Sushila za pomocą czystego JavaScriptu 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 skrzypcach http://jsfiddle.net/boldewyn/2b6d5/. W połączeniu z wykrywaniem cech i uwierzytelnianiem gołym okiem od Odpowiedź Squirtle'a, uwalnia cię od masakry regularnych wyrażeń i nie przepada za starymi przeglądarkami.


76



Jest to sprytny pomysł, aby wykreślić problem, ale nie działa, ponieważ przeglądarki mają również fałszywą walidację. Na przykład. .@a sprawdza jako true w aktualnych wersjach Chrome, Firefox i Safari. - Hank
@HenryJackson Niestety, w tym przypadku tak. Wynika to z faktu, że zgodnie z RFC jest to prawidłowy adres e-mail (intranetowe). Przeglądarki zostałyby upieczone, gdyby sprawdzały zbyt wąskie i generowały fałszywe negatywy. - Boldewyn
Zaktualizowano, aby zawierał funkcję wykrywania cech i pełną wdzięku degradację, teraz nie pęka w nowych przeglądarkach, ale używa dowolnego wyrażenia regularnego, które lubisz. - Ronny
Ładne rozwiązanie. Niestety jest to tylko dla HTML5 +. - Edward Olamisan
Jest to zdecydowanie najlepsze rozwiązanie pierwotnego pytania. Tak, korzysta z HTML5, ale większość aplikacji, które wymagają takiego poziomu dokładności, z pewnością już i tak będzie polegać na HTML5 w jakiś inny sposób, więc kwestia sporna. Nie jesteśmy w stanie określić, czy czyjś adres e-mail jest prawidłowy, ale i tak nie możemy go zweryfikować, więc naprawdę nie powinniśmy inwestować tak wiele czasu ani wysiłku, aby go zweryfikować. Szybkie sprawdzenie jakiejkolwiek oczywistej składni lub próby złej gry to wysiłek, który powinniśmy wydać. - Woody Payne


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

emailAddress.match( / some_regex /);

Oto jest RFC22 wyrażenie regularne dla e-maili:

^((?>[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)>)$

63



Węzeł nie może skompilować tego wyrażenia regularnego - Kato
@Kato: Używa niektórych niekompatybilnych rozszerzeń, w tym (?> aby zatrzymać cofanie i (?<angle><)…(?(angle)>) aby uniknąć zapewniania długiego czasu |. - Ry-♦


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

60



Fuj. To może zadziałać, ale to trochę brzydkie, nie sądzisz? - bgmCoder
"Forma" tej funkcji bardziej pokazuje, co robi :-) - Bob van Luijt
Dziękujemy za wersję, która działa z obiektem RegExp. - Thomas
@BGM: Czy wolisz mieć piękną funkcję, która nie działa? - Piskvor
@BGM: Dalej i edytuj. Odpowiedź jest przecież oznaczona jako "community wiki". - Piskvor


Prawidłowe sprawdzanie poprawności adresu e-mail zgodnie z RFC nie jest czymś, co można osiągnąć za pomocą jedno-liniowego wyrażenia regularnego. Artykuł z najlepszym rozwiązaniem, jakie znalazłem w PHP Co to jest poprawny adres e-mail?. Oczywiście został przeniesiony na Javę. Myślę, że ta funkcja jest zbyt skomplikowana, aby można ją było przenieść i używać w JavaScript.

Dobrą praktyką jest sprawdzanie poprawności danych na kliencie, ale dwukrotnie 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 klienta i wykonać ścisłą kontrolę na serwerze.

Oto funkcja JavaScript, której używam, aby sprawdzić, 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, ubiegły, zeszły @ powinien być przedostatni . od @ nie może być częścią nazwy serwera (o ile wiem).

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

  • str.indexOf('@@') == -1: Nie powinno być @@ w adresie. Choćby @ pojawia się jako ostatni znak w nazwie użytkownika e-mail, należy go podać w ten sposób " będzie między tym @ i ostatni @ w adresie.

  • lastDotPos > 2: Na przykład powinno być co najmniej trzy znaki przed ostatnią kropką a@b.com.

  • (str.length - lastDotPos) > 2: Po ostatniej kropce powinno być wystarczająco dużo znaków, aby utworzyć domenę dwuznakową. Nie jestem pewien, czy klamry są konieczne.


47



Ten fn wygląda ładnie, ale czy jest lepszy niż regex napisany w górnej odpowiedzi? - Atul Goyal
Wątpię. Używam go tylko do sprawdzenia, czy ciąg wygląda jak e-mail i pozostawić szczegóły kodu po stronie serwera. - Miloš Rašić
Potwierdza OK dowolny ciąg taki jak "aaaa", tj. Bez "@" i "." - Gennady Shumakher
Nie powinno. lastIndexOf () powinien zwrócić -1, jeśli nie znajdzie igły. - Miloš Rašić
"Choćby @ pojawia się jako ostatni znak w nazwie użytkownika e-mail, należy go podać w ten sposób " będzie między tym @ i ostatni @ w adresie. " Co powiesz na "@@"@example.com? - Ry-♦