Должен ли плюс быть закодирован в mailto: hyperlinks?

При размещении адреса электронной почты с тегом адреса (он же подадресация ) в гиперссылку mailto …

<a href="mailto:username+foo@example.com">mail us now!</a>

… Должен ли плюс в письме быть закодирован URL?

<a href="mailto:username%2Bfoo@example.com">mail us now!</a>

Я не могу понять это, и документация противоречива. Наши тесты в реальном мире также дали смешанные результаты, что делает его еще более запутанным.

Плюс используется для кодирования пробелов в URL, а не в HTML и не в SMTP (RFC2821). Однако, поскольку mailto:address@server.comэто URI (у него есть протокол, разделитель протокола и адрес протокола), его следует рассматривать как URI и кодировать его в процентах .

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

Вы должны применять кодировку URL к mailto: URL, встроенным в HTML, если символы в адресе электронной почты зарезервированы. Это гарантирует, что вы делаете правильные вещи. Клиент должен самостоятельно декодировать URI, откуда он был получен. Да, this+address@gmail.comэто очень правильный адрес электронной почты; да this%2Baddress@gmail.comтакже действует. Да, эти два разные, но будут ли они рассматриваться по-разному, зависит от клиента ...

Как вы ранее заметили, не все клиенты отдают это правильно. Я предлагаю найти наиболее вероятный клиент (gmail, клиенты на основе браузера, Outlook), который ваши пользователи будут использовать, и делать то, что делает этот клиент. Вы сказали, что тестировали на GMail? Как вы это проверили? При использовании «mailto: client» на основе браузера (например, надстройки для Firefox и предложения Gmail) URI, скорее всего, не декодируется (как и должно быть).

Вы МОЖЕТЕ кодировать +, но не обязаны.

Во-первых, мы должны согласиться, что mailtoэто пример универсального URI, указанного в RFC 2396 . (Это то, что используют XHTML и HTML 4).

Теперь давайте выясним список зарезервированных символов в RFC 2396.

reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
              "$" | ","

URI разделяется на абсолютные и относительные:

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

И поскольку схема mailto:указана, это абсолютный URI:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

И поскольку оба шаблона для hier_partначала /, mailtoэто непрозрачная часть.

opaque_part   = uric_no_slash *uric

uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                "&" | "=" | "+" | "$" | ","

uric          = reserved | unreserved | escaped

Таким образом, ограничение заключается в том, что вам нужно бежать, /если речь идет о первом символе, но после этого вы можете добавить зарезервированные символы, включая +и @.

Вот еще один RFC, чтобы поддержать это. В последних RFC почтовой схемы, опубликованной в 2010 году под названием RFC 6068 , говорится:

Программное обеспечение, создающее 'mailto'URI, также должно быть осторожно, чтобы закодировать любые зарезервированные символы, которые используются. HTML-формы являются одним из видов программного обеспечения, которое создает 'mailto'URI. Текущие реализации кодируют пространство как '+', но это создает проблемы, потому что такое '+'положение для пространства нельзя отличить от реального '+'в 'mailto' URI. При создании 'mailto'URI все пробелы ДОЛЖНЫ быть закодированы как %20, а '+'символы МОГУТ быть закодированы как %2B. Обратите внимание, что '+' символы часто используются как часть адреса электронной почты для указания подадреса, как, например, в <bill+ietf@example.org>.

Строгое чтение соответствующего RFC говорит о том, что «+» должно быть закодировано.

Раздел 2, начало страницы 2 на http://tools.ietf.org/html/rfc2368, гласит:

«Обратите внимание, что все зарезервированные символы URL в« to »должны быть закодированы: в частности, круглые скобки, запятые и знак процента («% »), которые обычно встречаются в синтаксисе« почтового ящика ».»

RFC для URI (http://tools.ietf.org/html/rfc3986#section-2.2) перечисляет «+» как зарезервированный символ.

Тем не менее, то, что является «правильным», не обязательно то, что будет работать во всех браузерах. Некоторые браузеры, очевидно, всегда будут обрабатывать правильные вещи, как если бы они были неправы, а неправильные - как если бы они были правы.

Изменить: Что касается RFC6068 и его "МОЖЕТ", я бы прочитал это как контекстно-зависимый. Если вы пишете URL для чтения текста, тогда «+» имеет больше смысла, однако, если вы пишете его в HTML, тогда более строгая интерпретация RFC3986 будет в большей степени соответствовать идеям «правильного HTML», и поэтому все, что использует значение, должно ожидайте, что это будет закодировано.

По новому RFC http://tools.ietf.org/html/rfc6068#section-5

  ... '+' MAY BE encoded as %2B

Так что я думаю, что ответ - нет, но может быть?

Я думаю, что кодирование это или нет, ничего не изменит. Проблема в почтовых клиентах. Например, Yahoo Mail использует дефис только для подадресации, тогда как gMail использует плюс.

Это мои 2 цента ...

РЕДАКТИРОВАТЬ: ответ ниже имеет сплошную точку.

RFC1738

3.5. MAILTO

Схема mailto URL используется для обозначения почтового адреса в Интернете физического лица или службы. Никакой дополнительной информации, кроме почтового адреса в Интернете, нет или подразумевается.

URL-адрес mailto принимает форму:

    mailto:<rfc822-addr-spec>

где (кодировка) addr-spec, как указано в RFC 822 . В почтовых URL-адресах нет зарезервированных символов.

Обратите внимание, что знак процента («%») обычно используется в адресах RFC 822 и должен быть закодирован.

В отличие от многих URL-адресов, схема mailto не представляет объект данных, к которому осуществляется прямой доступ; нет никакого смысла, в котором он обозначает объект. Он имеет другое использование, чем тип сообщения / внешнего тела в MIME.

Поскольку нет зарезервированных символов, они должны быть закодированы.

Согласно RFC 6068, как указано в ответах, вы МОЖЕТЕ кодировать знак плюс как %2B.

Причина путаницы в том, что преобразование пробела в плюс на самом деле не является частью стандартного кодирования URL, а является частью кодирования параметров формы (т.е. application/x-www-form-urlencoded)

Это как разница между PHP rawurlencode()и urlencode().

Итак, что говорит RFC 6068, так это то, что mailto:URL должен использовать «стандартную» стандартную кодировку URL (согласно RFC 3986 ), а знак «плюс», который появляется в URL, всегда должен рассматриваться как буквенный знак плюс, а не как пробел, имеющий был закодирован в форме.

Если локальный клиент преобразует плюс в пробел, он ломается.