Какие символы разрешены в адресе электронной почты?

Question

Какие символы разрешены в адресе электронной почты?

Могут ли скобки быть вложенными?

Если нет: \[([^]]+)\] соответствует одному элементу, включая квадратные скобки. Backreference \1 будет содержать элемент, который будет соответствовать. Если ваш regex-аромат поддерживает lookaround, используйте

(?<=\[)[^]]+(?=\])

Это будет соответствовать только элементам внутри скобок.

554

email-address email forms email-validation

задан kevinarpe 19 March 2017 в 10:06

8 ответов

Gmail разрешает только знак + как специальный символ, а в некоторых случаях (.), Но любые другие специальные символы не разрешены в Gmail. В RFC говорится, что вы можете использовать специальные символы, но вам следует избегать отправки почты в Gmail со специальными символами.

-2

ответ дан Mohammed 19 March 2017 в 10:06

Имя:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

Сервер:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

11

ответ дан ThinkingStiff 19 March 2017 в 10:06

Принятый ответ относится к статье в Википедии при обсуждении действительной локальной части адреса электронной почты, но Википедия не является авторитетом в этом.

IETF RFC 3696 является авторитетом по этому вопросу, и с ним следует ознакомиться в разделе 3. Ограничения для адресов электронной почты на странице 5:

Современные адреса электронной почты состоят из «локальной части», отделенной от «доменной части» (полного доменного имени) знаком at-sign ( "@"). Синтаксис доменной части соответствует синтаксису в предыдущем разделе. Проблемы, выявленные в этом разделе в отношении фильтрации и списков имен, относятся также к доменным именам, используемым в контексте электронной почты. Имя домена также может быть заменено IP-адресом в квадратных скобках, но эта форма настоятельно не рекомендуется, за исключением случаев тестирования и устранения неполадок.

Локальная часть может появляться с использованием соглашений о цитировании, описанных ниже. Указанные формы редко используются на практике, но необходимы для некоторых законных целей. Следовательно, они не должны быть отклонены в процедурах фильтрации, но вместо этого должны быть переданы в систему электронной почты для оценки хостом назначения.

Точное правило заключается в том, что любой символ ASCII, включая управляющие символы, может отображаться в кавычках или в строке в кавычках. Когда необходимо заключить в кавычки, символ обратной косой черты используется для цитирования следующего символа. Например,
  Abc\@def@example.com
является действительной формой адреса электронной почты. Также могут появляться пробелы, как в
  Fred\ Bloggs@example.com
Символ обратной косой черты может также использоваться для цитирования, например,
  Joe.\\Blow@example.com
В дополнение к цитированию с использованием символа обратной косой черты, обычный двойной Символы-кавычки могут использоваться для окружения строк. Например,
  "Abc@def"@example.com

  "Fred Bloggs"@example.com
являются альтернативными формами первых двух примеров выше. Эти цитируемые формы редко рекомендуются и на практике встречаются редко, но, как обсуждалось выше, должны поддерживаться приложениями, обрабатывающими адреса электронной почты. В частности, цитируемые формы часто появляются в контексте адресов, связанных с переходами из других систем и контекстов; эти переходные требования все еще возникают, и, поскольку система, которая принимает предоставленный пользователем адрес электронной почты, не может «знать», связан ли этот адрес с устаревшей системой, формы адреса должны быть приняты и переданы в среду электронной почты.

Без кавычек локальные части могут состоять из любой комбинации
алфавитных символов, цифр или любого из специальных символов
  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~
точка (".") Также может появляться , но не может использоваться для начала или окончания локальной части, а также не могут появляться два или более последовательных периода. Иными словами, любой символ ASCII (печатный), отличный от знака-символа ("@"), обратной косой черты, двойной кавычки, запятой или квадратных скобок, может отображаться без кавычек. Если появляется какой-либо из этого списка исключенных символов, они должны быть заключены в кавычки. Такие формы, как
  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com
действительны и видны довольно регулярно, но разрешены любые из перечисленных выше символов.

Как и другие, я отправляю регулярное выражение для PHP и JavaScript для проверки адресов электронной почты:

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

5

ответ дан Mac 19 March 2017 в 10:06

Короткий ответ: есть 2 ответа. Существует один стандарт того, что вы должны делать. то есть поведение, которое является мудрым и будет держать вас от неприятностей. Существует другой (гораздо более широкий) стандарт поведения, которое вы должны принять, не создавая проблем. Эта двойственность работает для отправки и приема электронной почты, но имеет широкое применение в жизни.

Для хорошего руководства по адресам, которые вы создаете; см .: http://www.remote.org/jochen/mail/info/chars.html

Чтобы отфильтровать действительные электронные письма, просто передайте что-нибудь достаточно понятное, чтобы увидеть следующий шаг. Или начните читать кучу RFC, будьте осторожны, будьте драконами.

5

ответ дан Michael JAMES 19 March 2017 в 10:06

В Википедии есть хорошая статья об этом , и официальная спецификация здесь . Из Википедии:

Местная часть адреса электронной почты может использовать любой из этих ASCII символов:

Прописные и строчные английские буквы (a-z, A-Z)

Цифры от 0 до 9

Символы ! # $ % & ' * + - / = ? ^ _ ` { | } ~

Характер. (точка, точка, точка) при условии, что он не является первым или последним символом, а также при условии, что он не появляется два или более раз подряд.

Дополнительно допускается использование строк в кавычках (т.е. "John Doe"@example.com), что позволяет использовать символы, которые в противном случае были бы запрещены, однако они не появляются в общепринятой практике. RFC 5321 также предупреждает, что "хост, который ожидает получить почту, ДОЛЖЕН избежать определения почтовых ящиков, где Локальная часть требует (или использует) форму в виде кавычек".

21

ответ дан 22 November 2019 в 22:05

Вы можете начать со статьи в википедии :

Прописные и строчные английские буквы (a-z, A-Z)
Цифры от 0 до 9
Символов! # $ % & ' * + - / = ? ^ _ ` { | } ~
Характер. (точка, точка, точка) при условии, что он не является первым или последним символом, а также при условии, что он не появляется два или более раз подряд.

12

ответ дан 22 November 2019 в 22:05

Смотрите! В этой теме есть куча знаний в этой теме (материал, который был правдой и сейчас не).

Чтобы избежать ложноположительных отклонений фактических адресов электронной почты в текущем и будущем мире, и из любой точки мира вам нужно знать, по крайней мере, концепцию высокого уровня RFC 3490 , «Интернационализация Доменные имена в приложениях (IDNA) ». Я знаю, что люди в нас, и чаще не в этом, но это уже в широко распространенном и быстро растущем применении по всему миру (в основном, не имеющие участие в английском языках).

Гист состоит в том, что теперь вы можете использовать такие адреса, как (скрытые) и (скрытые) Нет, это еще не совместимо со всем там (как многие посетовали выше, даже простые адреса qmail + идентичные адреса часто часто ошибочны отклоненный). Но есть RFC, есть спецификация, теперь он поддерживается IETF и ICANN, и - что более важно, - есть большое и растущее количество реализации, поддерживающих это улучшение, которое в настоящее время в обслуживании.

Я не знал много об этой разработке себя, пока не вернулся в Японию и не начал видеть адреса электронной почты, такие как (скрытые) и URL-адреса Amazon, как это:

http://www.amazon.co.jp/ エレクトロニクス - デジタルカメラ - ポータブルオーディオ / b / ref = topnav_storetab_e? IE = utf8 & node = 3210981

Я знаю, что вы не хотите ссылки на спецификации, но если вы полагаетесь исключительно на устаревшие знания о хакеров на интернет-форумах, ваш валидатор электронной почты в конечном итоге отклоняют адрес электронной почты, что неанглоязычные пользователи все чаще ожидают работать. Для тех пользователей такая проверка будет так же, как раздражающая, как обычная форма мозга мозга, которую мы все ненавидим, тот, который не может обрабатывать + или одночасовое доменное имя или что-то еще.

Итак, я не говорю, что это не хлопот, но полный список персонажей «допускается под некоторыми / любыми / нет условиями» (почти) все символы на всех языках. Если вы хотите «принять все действующие адреса электронной почты (и многие недействительные тоже)», то вам необходимо воспользоваться IDN, что в основном делает подход на основе персонажа бесполезным (извините), если вы сначала Преобразовать интернационализированные адреса электронной почты к PunyCode .

После этого вы можете следовать (большую часть) совета выше.

308

ответ дан 22 November 2019 в 22:05

Другие вопросы по тегам:

email-address email forms email-validation

Похожие вопросы:

score 752 · Accepted Answer

См. RFC 5322: Internet Message Format и, в меньшей степени, RFC 5321: Простой протокол передачи почты.

RFC 822 также охватывает адреса электронной почты, но в нем рассматривается в основном их структура:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

И, как обычно, в Википедии есть приличная статья об адресах электронной почты:

Локальная часть адреса электронной почты может использовать любой из этих символов ASCII:

прописные и строчные латинские буквы A - Z и a - z;

цифры 0 - 9;

специальные символы ! #$%&'*+-/=?^_`{|}~;

dot . , при условии, что он не является первым или последним символом, если не заключен в кавычки, а также при условии, что он не появляется последовательно, если не заключен в кавычки (например, John..Doe@example.com не разрешен, но "John..Doe"@example. com разрешено);

пробел и "(),:;<>@[\] символы разрешены с ограничениями (они разрешены только внутри кавычек, как описано в параграфе ниже, и, кроме того, перед обратной косой чертой или двойной кавычкой должна стоять обратная косая черта);

комментарии разрешены с круглыми скобками в любом конце локальной части; например. например, john.smith(comment)@example.com и (comment)john.smith@example.com эквивалентны john.smith@example.com.

Помимо символов ASCII, по состоянию на 2012 год вы можете использовать международные символы выше U+007F, закодированные как UTF-8, как описано в RFC 6532 spec и объяснено в Wikipedia. Обратите внимание, что по состоянию на 2019 год эти стандарты все еще помечены как Proposed, но постепенно внедряются. Изменения в этой спецификации по существу добавили международные символы в качестве допустимых буквенно-цифровых символов (atext), не затрагивая правила о разрешенных и ограниченных специальных символах, таких как !# и @:.

О проверке см. раздел Использование регулярного выражения для проверки адреса электронной почты.

Часть домен определяется следующим образом:

Стандарты Интернета (запрос на комментарии) для протоколов предписывают, что метки имен хостов компонентов могут содержать только буквы ASCII a - z (без учета регистра), цифры 0 - 9 и дефис (-). Первоначальная спецификация имен хостов в RFC 952 предписывала, что метки не могут начинаться с цифры или дефиса и не должны заканчиваться дефисом. Однако последующая спецификация (RFC 1123) разрешила меткам имен хостов начинаться с цифр. Никакие другие символы, знаки препинания или пробелы не допускаются.