Да. Email-адрес с апострофом может быть корректным, если символ стоит перед @. В o'neil@example.com имя перед @ называют локальной частью. Обычный ASCII-апостроф входит в число символов, разрешенных RFC 5322.
Если форма отклоняет такой адрес, найдите шаг, на котором срабатывает проверка или возникает ошибка сохранения. Удаление символа меняет адрес. Допустимый формат сам по себе не доказывает, что провайдер создал такой ящик и он может принимать письма.
Проверьте символ и его положение
Прямой апостроф ' имеет код U+0027, а изогнутый символ ’ — U+2019. В поле они могут выглядеть похоже, но это разные символы. Второй не входит в набор ASCII, на котором основаны обычные правила записи локальной части.
| Пример | Что он показывает |
|---|---|
o'neil@example.com |
Прямой апостроф допустим в такой локальной части |
o’neil@example.com |
Введен другой Unicode-символ; поддержку международных адресов нужно проверять отдельно |
o'neil@exam'ple.com |
В домене есть символ, который обычные правила записи почтовых доменов не допускают |
o'neil..sales@example.com |
Две точки подряд делают эту локальную часть без кавычек некорректной |
Правила записи адресов в SMTP определяют допустимые домены и разделение локальной части точками. Здесь используется зарезервированный для документации домен; примеры не обозначают работающие ящики.
Если в поле оказался изогнутый символ, попросите человека подтвердить написание адреса. Не заменяйте символ незаметно и не удаляйте знаки препинания. Остальные ограничения формата описаны в справке о синтаксисе email-адресов.
Найдите шаг, на котором адрес отклоняют
Начните с поля в браузере. HTML-поле <input type="email"> допускает прямой апостроф в локальной части. Дополнительный pattern, JavaScript-валидатор или библиотека форм могут вводить более строгие правила. Спецификация HTML-поля для email задает правила, которые отличаются от синтаксиса SMTP.
Запустите этот код в консоли браузера, чтобы проверить только встроенные ограничения формата. Он создает поле вне документа и не отправляет запросов:
const field = document.createElement("input");
field.type = "email";
field.required = true;
console.table([
"o'neil@example.com",
"o’neil@example.com",
"o'neil@exam'ple.com",
"o'neil..sales@example.com"
].map(value => {
field.value = value;
return { value, formatAccepted: field.checkValidity() };
}));
Результаты по порядку: true, false, false, true. Последний показывает, почему важно различать проверки: браузер принимает две точки подряд перед @, хотя SMTP-правила для локальной части без кавычек этого не допускают. Успешная проверка поля не заменяет проверку на сервере.
Если первый пример проходит этот тест, но не вашу форму, проверьте дополнительные правила. Если форма принимает адрес, сравните отправленное значение с тем, что получает сервер. Затем проверьте серверный парсер и его сообщение об ошибке. В примере формы с JavaScript показано, как давать понятные подсказки и независимо проверять ввод на сервере.
Сохраняйте адрес без изменений
После того как сервер примет формат, убедитесь, что запись и чтение не меняют локальную часть. o'neil@example.com и oneil@example.com — разные введенные адреса. У приложения нет оснований считать удаление символа исправлением.
При работе с SQL передавайте адрес как параметр через драйвер базы данных. Не собирайте запрос, подставляя адрес прямо в строку SQL. OWASP рекомендует параметризованные запросы, чтобы отделять входные данные от SQL-кода. Удаление апострофов эту задачу не решает.
Проверьте каждую функцию, которая читает сохраненный контакт. Даже если регистрация прошла успешно, при входе, редактировании профиля, экспорте или сбросе пароля может сработать другой валидатор. Для воспроизводимого отчета об ошибке запишите вымышленный адрес, проблемный шаг, сообщение и значение после сохранения и повторной загрузки. Не включайте в отчет реальные адреса клиентов.
Если подключенный сервис не принимает адрес, объясните ограничение и предложите человеку указать другой. Не придумывайте замену, меняя имя ящика.
Проверьте адрес после исправления ошибки
Передайте сохраненный без изменений адрес с вашего сервера в API проверки email-адресов. Так можно получить свидетельства о домене и, когда они доступны, о получателе. Ключи API оставьте на сервере. Emvero сохраняет локальную часть, включая знаки препинания.
Результат unknown означает, что имеющихся свидетельств недостаточно для вывода. При pending проверка еще не завершена. Ни один из этих результатов не устанавливает постоянную причину отклонить адрес. Если нужно убедиться, что человек управляет ящиком, попросите его подтвердить доступ по ссылке или коду. Статья о разнице между проверкой адреса и подтверждением почты объясняет, почему допустимый символ и принятый сервером получатель еще не отвечают на этот вопрос.