Чи слід плюс кодувати в mailto: гіперпосилання?

При розміщенні адреси електронної пошти з адресою тегом (акой подадресаціі) в 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. Це забезпечує те, що ви робите правильно. Клієнт повинен розшифрувати 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-адреси символів у" до "повинні бути закодовані: зокрема, дужки, коми та знак відсотка ("% "), які зазвичай зустрічаються в синтаксисі" поштової скриньки "."

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 копійки ...

EDIT: Відповідь, наведена нижче, має суттєвий результат.

RFC1738

3.5. МАЙЛТО

Схема URL-адреси mailto використовується для позначення поштової адреси в Інтернеті фізичної особи чи послуги. Ніякої додаткової інформації, окрім Інтернет-поштової адреси, немає або мається на увазі.

URL-адреса пошти має форму:

    mailto:<rfc822-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-адресі, завжди повинен розглядатися як буквальний знак плюс, а не як пробіл, у якому є були закодовані форми.

Якщо локальний клієнт перетворить плюс у простір, він порушений.