Разрешено ли содержать адреса электронной почты не буквенно-цифровые символы?
Я создаю сайт, используя `Django. Сайт может иметь значительных пользователей из неанглоязычных стран.
Я просто хочу знать, существуют ли какие-либо технические ограничения на типы символов, которые может содержать адрес электронной почты.
Разрешено ли содержать только адреса электронной почты, английские алфавиты, цифры, "_", "@" и "."?
Разрешено ли им содержать неанглийские алфавиты, такие как "é" или "ü"?
Разрешено ли им содержать китайские, японские или другие символы Юникода?
7 ответов
Адрес электронной почты состоит из двух частей local
до @ и domain
это идет после.
Правила к этим частям разные:
За local part
Вы можете использовать ASCII:
- Латинские буквы A - Z a - z
- цифры 0 - 9
- специальные символы!#$%&'*+-/=?^_`{|}~
- точка., что это не первый или последний, и не в последовательности
- пробел и символы "(),:;<>@[] допускаются с ограничениями (они допускаются только внутри строки в кавычках, обратной косой черты или двойной кавычки должна предшествовать обратная косая черта)
- Плюс с 2012 года вы можете использовать международные символы выше
U+007F
, закодированный как UTF-8.
Domain part
более ограничен:
- Латинские буквы A - Z a - z
- цифры 0 - 9
- дефис - то есть не первый или последний, допускается несколько дефисов в последовательности.
Регулярное выражение для проверки
^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})
Надеюсь, это сэкономит вам время.
Ну да. Прочитайте (по крайней мере) эту статью из Википедии.
Я живу в Аргентине, и здесь разрешены электронные письма, такие как ñoñó1234@server.com
Разрешенный синтаксис в адресе электронной почты описан в RFC 3696 и довольно сложен.
Точное правило [для локальной части; часть перед '@'] заключается в том, что любой символ ASCII, включая управляющие символы, может отображаться в кавычках или в строке в кавычках. Когда необходимо заключить в кавычки, символ обратной косой черты используется, чтобы заключить в кавычки следующий символ
[...]
Без кавычек локальные части могут состоять из любой комбинации букв, цифр или любых специальных символов! # $% & '* + - / =? ^ _ `. {| } ~
[...]
Любые символы или комбинации битов (в виде октетов) разрешены в именах DNS. Тем не менее, есть предпочтительная форма, которая требуется для большинства приложений...
... и так далее, в некоторой глубине.
Вместо того, чтобы беспокоиться о том, что адреса электронной почты могут и не могут содержать, что вас действительно не волнует, проверьте, может ли ваша установка отправлять им электронные письма или нет - это то, что вас действительно волнует! Это фактически означает отправку подтверждающего электронного письма.
В противном случае вы не сможете обнаружить гораздо более распространенный случай случайных опечаток, которые остаются в пределах любого набора символов, который вы разработали. (Быстрый: является ли random@mydomain.com действительным адресом, который я могу использовать на вашем сайте, или нет?) Он также позволяет избежать ненужного и необоснованного отчуждения любых пользователей, когда вы говорите им, что их совершенно действительный и правильный адрес неверен. Вы все еще не сможете обработать некоторые адреса (это необходимо отчуждение), как говорят другие ответы: обработка адресов электронной почты не тривиальна; но это то, что им нужно выяснить, хотят ли они предоставить вам адрес электронной почты!
Все, что вам нужно проверить, это то, что пользователь вводит текст перед @, текст после него, а адрес не слишком длинный (скажем, 1000 символов). Если вы хотите выдать предупреждение ("это похоже на проблему! Есть ли опечатка? Перепроверьте перед продолжением"), это нормально, но это не должно блокировать процесс добавления адреса электронной почты.
Конечно, если вы не хотите когда-либо отправлять им электронные письма, просто берите все, что они вводят. Например, адрес может использоваться исключительно для Gravatar, но Gravatar в любом случае проверяет все адреса электронной почты.
Существует возможность иметь адреса электронной почты не-ASCII, как показано в этом RFC: http://tools.ietf.org/html/rfc3490 но я думаю, что это не было установлено для всех стран, и из того, что я понимаю, только один Код языка будет разрешен для каждой страны, и есть также способ превратить его в ASCII, но это не будет тривиальной проблемой.
Я встречал адреса электронной почты с одинарными кавычками, и нередко тоже. Мы отклоняем пробел (хотя, строго говоря, это разрешено), более одного знака "@" и адресных строк короче, чем пять символов. Я полагаю, что это решает больше проблем, чем создает, и на протяжении десяти лет и нескольких сотен тысяч адресов он работал, чтобы отвергать много мусорных адресов. Также есть триггер для отключения всех адресов электронной почты при вставке или обновлении.
При этом невозможно проверить электронную почту без обратной связи с владельцем, но, по крайней мере, мы можем отклонить данные, которые являются чрезвычайно подозрительными.
Я взглянул на регулярное выражение в ответе pooh17 и заметил, что он позволяет локальной части быть больше 64 символов, если они разделены точками (он просто проверил бит до того, как первый период станет меньше 64 символов). Вы можете использовать положительный взгляд вперед, чтобы улучшить это, вот мое предложение, если вам действительно нужно регулярное выражение для этого
^(((?=.{1,64}@)[^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|((?=.{1,66}@)\".+\"))@(?=.{1,255}$)(\[(IPv6:)?[\dA-Fa-f:.]+\]|(?!.*?\.\.)(([^\s!\"#$%&'()*+,./:;<=>?@[\]^_`{|}~]+\.?)+[^\s!\"#$%&'()*+,./:;<=>?@[\]^_`{|}~]{2,}))$
Опираясь на ответ @ Matas Vaitkevicius: я исправил регулярное выражение в Python, чтобы оно соответствовало действительным адресам электронной почты, как определено на этой странице и на этой странице википедии, с использованием этого замечательного веб-сайта regex101: https://regex101.com/r/uP2oL7/26
Надеюсь, это поможет кому-то!:)