Як перевірити електронну адресу в JavaScript


4372

Чи є регулярний вираз для підтвердження електронної адреси в JavaScript?



60
будь ласка, отримайте це право, занадто багато веб-сайтів не люблять мою адресу електронної пошти "firstName@secondName.name", не всі домени верхнього рівня закінчують це 2 або 3 букви.
Ян Рінроуз

41
Будь-яка підтримка використання регулярних чеків для електронних листів я проти 100%. Мені набридло говорити, що моя електронна адреса "foo+bar@gmail.com" недійсна. Найкращим варіантом є попросити користувача ввести свою електронну пошту двічі, а якщо ОБОВ'ЯЗКОВО використовувати перевірочну систему, то скажіть користувачеві, що їх адреса електронної пошти не є дійсною, і запитайте, чи впевнені вони, що вони ввели її. правильно. Навіть заходьте так далеко, щоб зауважити, ЩО не перевірили у чеку регулярного вибору, але НЕ зупиняйте їх у поданні форми.
Soundfx4

17
@ Soundfx4: ця відповідь повинна бути і прийнята як така. Тестування на правильність адреси - це найголовніше - найкращий спосіб розчарувати клієнтів. Я прошу ввести адресу двічі і натякніть, що існують деякі можливі проблеми (відсутні @і ;comт.д.), і дозвольте користувачу виправити їх, якщо він захоче (і прийме все, що він мені надішле)
WoJ

4
Я повністю згоден з відповіддю, наданим WoJ. Формат дійсної адреси електронної пошти є надто складним, щоб перевірити її простим регулярним виразом. Єдиний спосіб бути впевненим, що адреса є дійсною - спробувати її.
Ніколь

Відповіді:


4941

Використання регулярних виразів , мабуть, найкращий спосіб. Ви можете побачити купу тестів тут (взято з хрому )

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

Ось приклад регулярного виразу, який приймає unicode:

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

Але майте на увазі, що не слід покладатися лише на перевірку JavaScript. JavaScript легко відключити. Це також має бути підтверджено і на стороні сервера.

Ось приклад вищезазначеного в дії:

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>


574
Цей регулярний вираз усуває дійсні електронні листи, які використовуються. Не використовувати. Google для "RFC822" або "RFC2822", щоб отримати правильний регулярний вираз.
Рандаль Шварц

42
Це навіть не сприймає прикладів в RFC 822. Деякі прості випадки не відповідають a \ @ b @ c.com, a(b)@c.com. Більше див. У RFC. Ось регулярний вираз, який не відхиляє жодних дійсних адрес [^ @] + @ [^ @] + \. [^ @] + І захищає від поширених помилок.
Vroo

126
@GoodPerson Я просто намагався надіслати електронною поштою n @ ai, щоб сказати йому / їй, що вони мають цікаву адресу електронної пошти. Але на жаль, Gmail не дозволив мені. Я підозрюю, що хтось у кого має більше проблем з спілкуванням з іншими електронною поштою, ніж просто перевірка javascript мого сайту! Але дякую за те, що виклик на виклик.
Бен Робертс

26
Це рішення, яке здається гарним для більшості носіїв англійської мови, але воно не відповідає тесту Туреччини (див. Джоел Спольський). Дозволено більшість літер унікоду, і, наприклад, в Аргентині такі адреси, як "ñoñó1234@server.com", є цілком нормальними. joelonsoftware.com/articles/Unicode.html
oligofren

139
Ви не можете перевірити адреси електронної пошти, періодично. Єдиний, хто може підтвердити адресу електронної пошти - це постачальник електронної адреси. Наприклад, у цій відповіді зазначено, що ці адреси електронної пошти: %2@gmail.com, "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, _@gmail.com, 1@gmail.com , 1_example@something.gmail.comвсі дійсні, але Gmail ніколи не дозволить жодну з цих електронних адрес. Ви повинні зробити це, прийнявши адресу електронної пошти та відправивши повідомлення на цю електронну адресу з кодом / посиланням, який користувач повинен відвідати, щоб підтвердити дійсність.
Кевін Феган

829

Я трохи змінив відповідь Джеймона для людей, які хочуть дійсно простої перевірки у вигляді:

anystring@anystring.anystring

Регулярний вираз:

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

Приклад функції JavaScript:

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


69
Ви можете реалізовувати щось 20 разів, що може створити проблеми у кількох користувачів і може бути недійсним у майбутньому, або ви можете захопити версію ImmortalFirefly, щоб переконатися, що вони принаймні намагаються зробити це справді реальним. Залежно від вашої заявки може бути більше шансів на те, що хтось зійде з розуму, оскільки ви не приймаєте їх нетрадиційну електронну пошту, а не хтось, хто викликає проблеми, вводячи адреси електронної пошти, які насправді не існують (що вони все одно можуть зробити, ввівши 100% дійсна електронна адреса RFC2822, але з використанням незареєстрованого імені користувача або домену). Оголошено!
користувач83358

82
@ImmortalFirefly, вказаний вами регулярний вираз дійсно буде відповідати name@again@example.com. Спробуйте вставити лінію в консоль JavaScript. Я вважаю, що ваш намір полягав у тому, щоб зіставити лише весь текст, який потребував би початку операторів тексту "^" та кінця тексту "$". Я використовую/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com')
OregonTrail

8
На підставі цієї перевірки цей електронний лист є дійсним: перевірити @ this..com
Ehsan

4
Гм. У Вікіпедії сказано, що "very.unusual.@.unusual.com"@example.comце дійсна адреса електронної пошти. /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('"very.unusual.@.unusual.com"@example.com') // false. На жаль
Шматочки бекону

3
Це також не дозволяє @@@.@? : D
hfossli

762

Просто для повноти, тут у вас є ще один регулярний вирівнювання, сумісний з RFC 2822

Офіційний стандарт відомий як RFC 2822 . Він описує синтаксис, якого повинні дотримуватися дійсні адреси електронної пошти. Ви можете ( але не слід - читати далі ) реалізувати це за допомогою цього регулярного виразу:

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

(...) Ми отримуємо більш практичну реалізацію RFC 2822, якщо опустити синтаксис, використовуючи подвійні лапки та квадратні дужки. Сьогодні він буде відповідати 99,99% усіх адрес електронної пошти.

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

Наступні зміни, які ви можете внести, - це дозволити будь-який двобуквенний код країни домену верхнього рівня та лише конкретні загальні домени верхнього рівня. Цей регекс фільтрує фіктивні адреси електронної пошти, якasdf@adsf.adsf . Вам потрібно буде оновити його, як додаються нові домени верхнього рівня .

[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

Тож навіть дотримуючись офіційних стандартів, ще потрібно зробити компроміси. Не слід сліпо копіювати регулярні вирази з онлайн-бібліотек чи дискусійних форумів. Завжди перевіряйте їх на власних даних та у власних програмах.

Наголос мій


84
Примітка: " Сьогодні фактично використовується ", можливо, вона була дійсною, коли код був написаний ще в 200х. Код , ймовірно, залишиться в користуванні і після цього конкретного року. (Якби я мав копійку за кожен "мех", ніхто ніколи не використовуватиме 4 + -літерний TLD, окрім тих ", які я повинен був виправити, я міг би
розігнати світовий

7
Для практичного втілення RFC 2822 закінчення слід трохи змінити, щоб запобігти розширення одного домену 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] /
буде Фаррелл

5
Крім того, перша частина повинна бути (?: [Az із великою літерою A, щоб уникнути помилкових негативів, коли користувач використовує великі літери своєї електронної адреси.
Дон Ролінг

9
@DonRolling Не роби цього. Це не означає лише "A до Z, a to z", це також означає "[\] ^ _` ", оскільки вони знаходяться між " Z "і" a ". Скористайтеся \wабо, що краще, просто замініть малі адреси електронної пошти, перш ніж робити що-небудь з нею, тому що це все-таки умова.
kirb

5
"Вам потрібно буде оновити його, як додаються нові домени верхнього рівня." Ну, так багато для цього зараз - є понад 1500 визнаних TLD.
Натан Осман

377

Вау, тут багато складності. Якщо все, що ви хочете зробити, це просто зловити найочевидніші синтаксичні помилки, я б зробив щось подібне:

^\S+@\S+$

Зазвичай він фіксує найочевидніші помилки, які робить користувач, і запевняє, що форма здебільшого вірна, саме для цього і полягає перевірка JavaScript.


70
+1 як надсилання електронної пошти та перегляд того, що відбувається - це єдиний справжній вірний спосіб перевірити адресу електронної пошти, тому не потрібно робити більше, ніж простий збіг з регулярними виразками.
kommradHomer

20
Ви все ще можете зробити це простим, але зробити трохи більше, щоб забезпечити його "." десь після @, а лише цифри чи цифри, тому такі речі, як я @ тут, я @ тут @, і я @ herecom, не вірні ... ^ \ S + @ \ S + [\.] [0-9a-z ] + $
Тім Франклін

14
Я думаю, що адреси електронної пошти можуть містити пробіли. Це, мабуть, краще використовувати.+@.+
Сем

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

110
@gtournie Нікого не цікавить. Ніхто не збирається вводити це в поле електронної пошти випадково , і це все, що перевіряється на передній план: Для того, щоб запобігти випадковому введенню в поле електронної пошти інформації, наприклад, їх імені, неправильного шматочка інформації.
meagar

330

Ви повинні зрозуміти те, що ви вирішили використовувати регулярний вираз для перевірки електронних листів: це, мабуть, не дуже гарна ідея . Після того, як ви з цим погодилися, існує багато реалізацій, які можуть привести вас на півдорозі, ця стаття їх добре підводить.

Якщо коротко, то єдиний спосіб бути абсолютно впевненим у тому, що те, що ввів користувач, це насправді електронний лист - це фактично надіслати електронний лист і подивитися, що відбувається. Крім того, це все лише здогадки.


112
-1 чому я хотів би витратити свій час на перевірку адреси електронної пошти, яка навіть не передає регулятор регулярного вибору?
kommradHomer

63
@kommradHomer - адреса "повторної виразної помилки" майже завжди дійсна, тому що незалежно від регулярного вираження, який ви використовуєте для перевірки адреси електронної пошти, майже напевно є неправильним і виключатиме дійсні адреси електронної пошти. Адреса електронної пошти є name_part@domain_partі практично все, включаючи і @, дійсне в name_part; Адреса foo@bar@machine.subdomain.example.museumє законною, хоча її потрібно уникати як foo\@bar@machine..... Як тільки електронна пошта досягне домену, наприклад, 'example.com', цей домен може направляти пошту "локально", тому можуть існувати "дивні" імена користувачів та імена хостів.
Стівен П

6
Другий вираз у відповіді voyager в stackoverflow.com/a/1373724/69697 практичний для використання і не повинен мати майже помилкових негативів. Я згоден з @kommradHomer тут - навіщо надсилати електронний лист, якщо цього не потрібно? Я можу зрозуміти рефлексивну неприязнь до незрозумілих регулярних виразів та бажання тримати код простим, але це пара рядків коду, який може врятувати ваш сервер чимало клопотів, негайно відмивши елементи, які точно недійсні. Сам регулярний вираз не є корисним, але служить гарним доповненням до перевірки на сервері.
Бен Регенспан

6
@dmur Я визнаю "майже завжди дійсним", ймовірно, це завищує, але у мене (абсолютно дійсні та працюючі) адреси електронної пошти занадто часто відхиляються веб-сайтами, просто тому, що у мене є .usдомен або тому, що я використовував +ліворуч від що @- багато місць , усунули кричущі помилки, але локальна частина (зліва від @) може бути що - то власник домену хоче. -> "foo@bar.com"@example.com <- це дійсна адреса електронної пошти.
Стівен П

8
@kommradHomer "Недійсна адреса регулярного виразу -% 100 - недійсна адреса." Вибачте ... вибачте? Чи знаєте ви, скільки разів мені говорили, що foo+bar@gmail.com НЕ є дійсним повідомленням електронної пошти, коли насправді ВІДПОВІДНО ВІДПОВІДНО ?! Ваша логіка НАЙКРАЙНО помилкова. Я надсилав форми з такими електронними листами: thisisafakeemailbutitwillpassyourstupidregexcheck@regexchecksareretarded.com І здогадаєтесь, що? ЩО ПЕРЕМОЖЕ REGEX перевірити ... але це НЕ дійсний електронний лист (хоча технічно це Є, але я обіцяю вам, що його немає ... все-таки подряпини підборіддя ). Як багато хто казав, це - BAD IDEA ....
Soundfx4

211

Сам HTML5 має перевірку електронної пошти. Якщо ваш браузер підтримує HTML5, ви можете використовувати наступний код.

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

jsFiddle посилання

З специфікації HTML5 :

Дійсний адреса електронної пошти є рядком , яка відповідає emailвиробництву наступного ABNF, набір символів , для яких є 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 >

Ця вимога є умисним порушенням RFC 5322, який визначає синтаксис адрес електронної пошти, який є одночасно занадто суворим (перед символом "@"), занадто розпливчастим (після символу "@") і надто розпусним (дозволяє коментарі , символи пробілу та процитовані рядки у незнайомих для більшості користувачів манерах), щоб бути тут корисними.

Наступне регулярне вираження, сумісне з JavaScript і Perl, є реалізацією вищезазначеного визначення.

/^[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
це добре, але проблема з цим полягає в тому, що він повинен бути всередині formтегу і подаватися submitвхідними даними, що не всім властиво розкіш. Крім того, ви не можете дійсно стилізувати повідомлення про помилку.
Джейсон

3
Я додав відповідь нижче, що звільняє вас від форми та надсилайте. Але так, браузери зазвичай також застосовують лише перевірку правдоподібності, а не повну перевірку RFC 822.
Болдевін

8
@ br1: він недійсний лише тому, що не існує домену "a" з топовим рівнем. що ваш інтранет має дозвіл на якийсь IP?
літаючі вівці

7
Тип поля електронної пошти
Html5

1
Примітка @ Коментар Пуце: HTML 5 введення електронної пошти приймає, user@emailтоді як, наприклад, PHP filter_varне робить. Це може спричинити проблеми.
texelate

136

Я вважав це найкращим рішенням:

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

Це дозволяє наступні формати:

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 (пробіл між цитатами)
8. üñîçøðé@example.com (символи Unicode в локальній частині)
9. üñîçøðé@üñîçøðé.com (символи Unicode в частині домену)
10. Pelé@example.com (латинська)
11. δοκιμή@παράδειγμα.δοκιμή (грецька)
12. 我 買 @ 屋企. 香港 (китайська)
13. 甲 斐 @ 黒 川. 日本 (японська)
14. чебурашка@ящик-с-апельсинамі.рф (кирилиця)

Він чітко універсальний та дозволяє виконувати всі важливі міжнародні символи, при цьому все ж застосовуючи базовий формат something@anything.anything. Це заблокує пробіли, які технічно дозволено RFC, але вони настільки рідкісні, що я радий це зробити.


9
Це саме те, що я роблю. Усі ці "складні" відповіді створюють проблеми: вони або не дозволяють ID-код з карай-кодом, або використовують фіксований набір TLD, або необгрунтовано обмежують користувача не використовувати символи типу [@ çµ.ö у своєму префіксі електронної пошти (до @) або доменне ім’я. JavaScript у інтерфейсі (не для використання резервного приводу) недостатній для перевірки з міркувань безпеки. То чому б просто не допомогти користувачеві у запобіганні основних помилок. Основні помилки: забудьте TLD або призначений для користувача префікс (до @) або домену-частина, друкарської помилки в @якості .(або навпаки). Зважаючи на це, ми маємо бути набагато більш обмежуючими на стороні сервера.
Хафенкраніч

Чомусь username@domain.comце не працює з цією схемою
Ейнштейн

2
Згідно з вашим регулярним виразом "_.............. kamal@gmail.com" дійсно, чого не повинно бути!
Камал Наян

1
Ось наведений RegEx з прикладами, якщо ви хочете поцікавитися
ryanm

7
Цей регулярний вираз є правильним. Якщо хтось вводить свою електронну пошту так, a@b@c@d.x.y.@.zто, можливо, вони заслуговують на поганий час? : D
corysimmons

94

У сучасних браузерах ви можете базуватись на відповіді @ Sushil за допомогою чистого JavaScript та 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);
}

Я зібрав приклад у скрипці http://jsfiddle.net/boldewyn/2b6d5/ . У поєднанні з виявленням функцій та валідацією голих кісток з відповіді Squirtle це звільняє вас від різанини регулярних виразів і не обмежується на старих браузерах.


4
Це розумна ідея, щоб виправити проблему, але вона не спрацює, оскільки браузери також мають шалену перевірку. Наприклад, .@aперевіряється як trueу поточних версіях Chrome, Firefox та Safari.
Генк

13
@HenryJackson На жаль, у цьому випадку так. Це тому, що згідно з RFC це дійсна адреса електронної пошти (думайте, інтранет). Веб-браузери отримують на грилі, якщо вони перевірятимуть занадто вузько і створюють помилкові негативи.
Болдевін

3
Оновлено, щоб містити функції виявлення функцій та витончену деградацію, тепер вона не працює в нових браузерах, але використовує будь-який регулярний вираз.
Ронні

Приємне рішення. На жаль, це лише для HTML5 +.
Едвард Оламісан

3
Це, безумовно, найкраще рішення оригінального питання. Так, він використовує HTML5, але більшість застосунків, які вимагають цього рівня точності, безперечно, вже покладаються на HTML5 якимось іншим способом, тому суперечка. Нам неможливо ніколи визначити, чия електронна пошта є дійсною, не змушуючи їх перевірити її, так що ми дійсно не повинні вкладати стільки часу чи зусиль у її перевірку. Швидка перевірка будь-яких очевидних синтаксисів або спроб неслухняності - це всі зусилля, які ми повинні витратити.
Вуді Пейн

69

Це правильна версія 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);
}

Адреси IDN не підтверджені (info@üpöü.com)
DAH,

66

JavaScript може відповідати звичайному виразу:

emailAddress.match( / some_regex /);

Ось регулярний вираз RFC22 для електронних листів:

^((?>[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: Він використовує деякі несумісні розширення, включаючи, (?>щоб зупинити зворотний трек і (?<angle><)…(?(angle)>)уникати тривалого надання |.
Ри-

60

Усі адреси електронної пошти містять символ "at" (тобто @). Перевірте цю необхідну умову:

email.indexOf("@") > 0

Не турбуйтеся чимось складнішим. Навіть якби ви могли чудово визначити, чи є електронний лист синтаксично дійсним, це не означає, чи належить він тому, хто його постачав. Ось що насправді має значення.

Щоб перевірити це, надішліть повідомлення про перевірку.


3
що робити, якщо буде більше одного символу "@"? інші обмежені символи? Цю перевірку не можна довіряти ...
eatmypants

56

Правильна перевірка адреси електронної пошти відповідно до RFC - це не те, чого можна досягти за допомогою однорядного регулярного виразу. Стаття з найкращим рішенням, яку я знайшла в PHP, - Що таке дійсна адреса електронної пошти? . Очевидно, він був перенесений на Java. Я думаю, що ця функція є надто складною, щоб переноситись та використовуватись у JavaScript. Порт JavaScript / node.js: https://www.npmjs.com/package/email-addresses .

Доброю практикою є перевірка ваших даних на клієнті, але двічі перевірити перевірку на сервері. Зважаючи на це, ви можете просто перевірити, чи виглядає рядок як дійсна адреса електронної пошти на клієнті, і виконати сувору перевірку на сервері.

Ось функція JavaScript, яку я використовую, щоб перевірити, чи виглядає рядок як дійсна поштова адреса:

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

Пояснення:

  • lastAtPos < lastDotPos: Останнє @має бути до останнього, .оскільки @не може бути частиною імені сервера (наскільки я знаю).

  • lastAtPos > 0: До останнього має бути щось (ім’я користувача електронної пошти) @.

  • str.indexOf('@@') == -1: Не повинно бути жодної @@адреси. Навіть якщо він @відображається як останній символ у електронному імені користувача електронної пошти, він повинен бути цитований, так що "це буде між цим @і останнім @в адресі.

  • lastDotPos > 2: Перед останньою крапкою, наприклад, повинно бути не менше трьох символів a@b.com.

  • (str.length - lastDotPos) > 2: Після останньої крапки має бути достатньо символів, щоб сформувати домен з двома символами. Я не впевнений, чи потрібні дужки.


Цей fn виглядає приємно, але чи кращий він від регулярного вираження, написаного у верхній відповіді?
Атул Гоял

4
Я сумніваюся в цьому. Я використовую його лише для того, щоб перевірити, чи виглядає рядок як електронний лист, і залишити деталі кодом на стороні сервера.
Мілош Рашич

Він підтверджує ОК будь-який рядок типу "aaaa", тобто без "@" та "."
Геннадій Шумахер

1
Це не повинно. lastIndexOf () повинен повернути -1, якщо він не знайде голки.
Мілош Рашич

"Навіть якщо він @відображається як останній символ у імені користувача електронної пошти, він повинен бути цитований, так що "це буде між цим @і останнім @в адресі." Про що "@@"@example.com?
Ри-

47

Це було вкрадено з 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
Це фільтрує все популярні .museumта .travelдомени (через обмеження на 4 .
знаки

4
Зміна {2,4} на {2,6} не складе проблем
Антон N

11
@Anton N: У нього є також приблизно мільйон інших проблем; фінал {2,4}- це лише його корисний показник (як, наприклад, "коли ви бачите цю помилку, інші, ймовірно, будуть навколо"). Самі основні з них є відсутність +в локальній частині; це поле для коментарів занадто мало, щоб вказувати на всі помилки, допущені вище.
Пісквор вийшов з будівлі

37
Чому ти просто не можеш це зробити return filter.test(email.value);?
MT.

3
@AntonN: Зараз у нас є 10+ символів TLD ( xn--clchc0ea0b2g2a9gcd). Все ще не проблема?
Пісквор вийшов з будівлі

42

Зробити це:

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

Чому? Він заснований на RFC 2822 , який ПОВИНЕН дотримуватися ВСІ адреси електронної пошти. І я не впевнений, чому б ти потурбувався чимось "простішим" ... ти все одно скопіюєш і вставиш його;)

Часто під час зберігання адрес електронної пошти в базі даних я роблю їх малими літерами, і, як правило, регулярні вирази зазвичай можуть бути відмічені як нечутливі до регістру. У цих випадках це трохи коротше:

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

Ось приклад його використання в JavaScript (з прапорцем, нечутливим до регістру 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') );

Примітка .
Технічно деякі електронні листи можуть містити лапки в розділі перед @символом із символами втечі всередині лапок (щоб ваш користувач електронної пошти міг бути неприємним та містити такі речі, як @і до "..."тих пір, поки це написано в лапках). НІКОЛИ НЕ РОБИТЬ ЦІЙ! Це застаріло. Але він включений у справжній стандарт RFC 2822 і тут пропущений.

Більше інформації: http://www.regular-expressions.info/email.html


@Kondal код JavaScript не відрізняється від регістру через /iпрапор в кінці регулярного виразу. Я згадую той факт, що це має бути порівняно не залежним від обставин, але я зроблю це більш зрозумілим.
Райан Тейлор

Працював для мене як шарм
Алекс

40

Я дуже сподіваюся вирішити цю проблему. Тому я змінив регулярне вираз перевірки електронної пошти вище

  • Оригінал
    /^(([^<>()\[\]\\.,;:\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@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()\.,;\s@\"]+\.{0,1})+[^<>()\.,;:\s@\"]{2,})$/

щоб передати приклади у Вікіпедії .

І результат ви можете побачити тут .

введіть тут опис зображення


Це здається хорошим рішенням, воно працює і з новими TLD, і з 1 листів електронної пошти
Mark Hughes

Чому john..doe@example.comслід бути невірним? Це дійсний кутовий випадок.
Валеріо

24

Не слід використовувати регулярні вирази для перевірки рядка введення, щоб перевірити, чи це електронний лист. Це занадто складно і не охоплювало б усіх справ.

Тепер, оскільки ви можете покрити лише 90% випадків, напишіть щось на кшталт:

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

Ви можете його вдосконалити. Наприклад, "aaa @" є дійсним. Але в цілому ви отримуєте суть. І не захоплюйтесь ... Простий 90% -й розчин краще, ніж 100% -ний розчин, який не працює.

Світ потребує простішого коду ...


15
Це дозволяє вводити стільки недійсних адрес електронної пошти, що це марні поради.
cazlab

3
Це не обов'язково має бути неможливим налагодження. У цій темі є багато прекрасних прикладів, які підтверджують далі, ніж "чи є в ній" @ ". Ваш приклад дозволяє" u @ "вважати дійсною адресою електронної пошти. Принаймні оцініть, чи є домен чи щось таке, може бути домен. З вашим прикладом є те, що я б назвав "агресивно ледачим кодуванням". Я не впевнений, чому ви його захищаєте, оскільки це на сьогоднішній день найнижча відповідь у потоці.
cazlab

3
@cazlab, можливо, ти маєш рацію. Зрештою мене проголосували. На відміну від вас, я не думаю, що жоден з наведених вище кодів не дозволяє легко відлагодити фрагменти. Мій "агресивно-ледачий" підхід принаймні можна покращити, якщо потрібно.
Zo72

3
Чим це відрізняється від використання регексу? (.+)@(.*)робить те саме, і коротше.
snostorm

4
+1 - якщо мета - переконатися, що користувач хоча б намагався ввести адресу електронної пошти, то перевіряйте, чи можна визначити, що адреса електронної пошти точно НЕ є електронною поштою чудове рішення. Хорошим прикладом може бути, якщо ви хочете, щоб ім’я користувача було електронною адресою. Якщо користувач набирає "sexy_chick_23", цей регекс можна використовувати, щоб дати їм голову, що очікується повідомлення електронної пошти. Якщо щось введене, схоже на електронну пошту, але це не так, користувач ніколи не отримає електронну пошту "підтвердження", і процес реєстрації ніколи не буде підтверджений.
Кріс Дутроу

23

Просто перевірте, чи введена адреса електронної пошти дійсна чи не використовується HTML.

<input type="email"/>

Немає необхідності писати функцію для перевірки.


4
IE <10 не підтримує цього, а також власний браузер Android.
Френк Конійн

7
Оголошення. IE <10 мертвий.
Майкл Шепер

19

Важко отримати валідатор електронної пошти на 100% правильний. Єдиний реальний спосіб виправити це - надіслати тестовий лист на рахунок. Однак, є кілька основних перевірок, які допоможуть переконатися, що ви отримуєте щось розумне.

Деякі вдосконалення:

Замість нового RegExpспробуйте написати regexpтак:

if (reg.test(/@/))

По-друге, перевірте, чи настає @знак після знака, і переконайтеся, що між символами @s та періодами є символи .


19

Ось як це робить валідатор вузлів :

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

Використовуйте цей код у вашій функції валідатора:

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

Інакше ви можете використовувати jQuery . Правила всередині визначають:

eMailId: {
    required: true,
    email: true
}

1
abc@xyzце абсолютно дійсний електронний лист, який не розпізнається вашим регулярним виразом.
Toto

3
Ні це не так. Правильний шаблон електронної пошти - щось@something.something, abc @ xyz не відповідає цьому шаблону. Отже, це не дійсна адреса.
Орхідея


5
Ви були на сторінці вікіпедії? TLD - дійсне ім'я хоста. Це abc@tldдійсна адреса електронної пошти.
Тото

2
Єдиний спосіб підтвердити адресу електронної пошти - це надіслати електронний лист, а потім чекати відповіді. Крім цього, тут є URL-адреса, де ви можете перевірити, чи відповідає ваша адреса RFC822: mythic-beasts.com/~pdw/cgi-bin/emailvalidate . Ви можете бачити, що abc @ xyz є дійсною адресою для RFC822.
Тото

14

Оновлення Regex 2018! спробуйте це

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

версія машинопису завершена

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

більше інформації https://git.io/vhEfc


Це не вдалося для стандартної електронної пошти@domain.com
рик

1
@RickS це просто неправда. Перевірте ще раз
malimo

13

Рішення, яке не перевіряє існування TLD, є неповним.

Майже всі відповіді на ці запитання пропонують використовувати Regex для перевірки адрес електронної пошти. Я думаю, що Regex корисний лише для рудиментарної перевірки. Схоже, перевірка перевірки електронних адрес - це фактично дві окремі проблеми:

1- Перевірка формату електронної пошти: Переконайтесь, що відповідність електронному листу формату та шаблону електронних листів у RFC 5322 та чи TLD насправді існує. Список усіх дійсних TLD можна знайти тут .

Наприклад, хоча адреса example@example.cccпередасть регулярний вираз, він не є дійсним електронною поштою, оскільки cccIANA не є доменом вищого рівня.

2- Переконайтесь, що електронна пошта насправді існує: Для цього єдиний варіант - надіслати користувачам електронний лист .


13

Regex для підтвердження електронної адреси

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

Я не бачу вашого regexp в RFC5322: tools.ietf.org/html/rfc5322 - є якась помилка?
Kamil Kiełczewski

"Кращий регулярний вираз"? Можливо, тут якесь пояснення?
connectyourcharger

Чому ви сказали, що це найкраще рішення з усіх, ви можете пояснити трохи більше, будь ласка?
нанкодер

Я не в змозі пригадати, чому я написав «кращий реджекс за всю історію». Вибачте, хлопці, якщо це вас турбує.
Прабхат Касера

12

Ось дуже гарна дискусія щодо використання регулярних виразів для перевірки адрес електронної пошти; " Порівняння електронної адреси, що підтверджує регулярні вирази "

Ось поточний верхній вираз, який сумісний з JavaScript, для довідок:

/^[-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 Білий список залишає бажати кращого - особливо ви пропустили .jobs. Крім того, є прямі IDN-адреси (більшість з яких, я визнаю, були офіційно затверджені лише після вашої посади - наприклад, .中國у червні 2010 року, але більшість працювали роками).
Пісквор вийшов з будівлі

2
-1 не використовувати постійні домени верхнього рівня. Там завжди (а це буде, наприклад, 2013) можна було б додати новий tld.
miho

Там підтверджено 100 нових TLD. Ця відповідь не вірна і ніколи не повинна використовуватися.
Дін Мейхан

Так. Я говорив це в 2011 році, і я ще раз скажу: білий список "спеціальних" доменів з часом тільки погіршиться, оскільки буде затверджено більше TLD. Більше 100 повністю дійсних TLD не відповідають вищевказаному списку: en.wikipedia.org/wiki/List_of_Internet_top-level_domains
Piskvor покинув будівлю

Це 2015. Твій вираз не практичний. Ви повинні скористатися цією відповіддю, але ви, ймовірно, занадто зайняті виправленням усіх сторінок, на які ви покладете це вираження. Правильно?
Ерік Лерой


12

На відміну від squirtle , тут є складне рішення, але воно робить непогану роботу щодо перевірки електронних листів належним чином:

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

Використовуйте так:

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

10
Вам не потрібно == trueна прикладі.
Люк Олдертон

11

Моє знання регулярних виразів не так добре. Ось чому я перевіряю спершу загальний синтаксис з простим регулярним виразом і перевіряю більш конкретні параметри за допомогою інших функцій. Це може бути не найкращим технічним рішенням, але таким чином я набагато гнучкіший і швидший.

Найпоширеніші помилки, з якими я стикаюся, - це пробіли (особливо на початку та в кінці) та інколи подвійні крапки.

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>

Можливо, якщо ви додали пояснення чи опис, щоб продовжити це? Я не думаю, що вам дійсно не потрібно показувати будь-який html; всі люди переймаються - це JavaScript і регулярний вираз. Якщо ви зведете свою відповідь лише до jacascript і додасте трохи розмиття, щоб піти з нею, я дам вам підсумок.
bgmCoder

9

Я шукав Regex в JS, який передає всі тестові випадки електронної адреси:

  • email@example.com Дійсний електронний лист

  • firstname.lastname@example.com Електронна пошта містить крапки в адресному полі

  • email@subdomain.example.com Електронна пошта містить крапку з субдоменом

  • firstname+lastname@example.com Знак плюс вважається дійсним символом

  • email@192.0.2.123 Домен є дійсною IP-адресою

  • email@[192.0.2.123] Квадратна дужка навколо IP-адреси вважається дійсною

  • “email”@example.com Цитати навколо електронної пошти вважаються дійсними

  • 1234567890@example.com Цифри в адресі дійсні

  • email@domain-one.example Тире в доменному імені дійсне

  • _______@example.com Підкреслення в полі адреси є дійсним

  • email@example.name .name дійсне ім'я домену верхнього рівня

  • email@example.co.jpТочка в доменному домені верхнього рівня також вважається дійсною (використовуючи co.jpяк приклад тут)

  • firstname-lastname@example.com Тире в адресному полі є дійсним

Ось і ми :

http://regexr.com/3f07j

АБО регекс:

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

8

Регулярний вираз, що надається Microsoft в рамках ASP.NET MVC, - це

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

Я розміщую тут на випадок, коли це недосконало - хоча це завжди було ідеально для моїх потреб.


1
Не дозволяє + в іменній частині електронного листа.
Пол Іди
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.