Czy plus należy zakodować w mailto: hiperłączach?

Podczas umieszczania adresu e-mail z tagiem adresu (inaczej podadresowaniem) w hiperłączu mailto …

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

… Czy plus w e-mailu powinien być zakodowany w adresie URL?

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

Nie mogę tego rozgryźć, a dokumentacja jest w konflikcie. Nasze testy w prawdziwym świecie przyniosły również mieszane wyniki, co czyni go jeszcze bardziej zagmatwanym.

Znak plus służy do kodowania spacji w adresach URL, a nie w HTML i nie w SMTP (RFC2821). Ponieważ jednak mailto:address@server.comjest to URI (ma protokół, separator protokołu i adres protokołu), powinien być traktowany jako URI i powinien być zakodowany w procentach .

Dlatego to klient musi dokładnie rozwiązać zakodowaną reprezentację i zdekodować ją w miarę potrzeb. Oto oficjalne stanowisko Microsoft w tej sprawie .

Powinieneś zastosować kodowanie adresu URL w mailto: Adresy URL osadzone w HTML, jeśli znaki w adresie e-mail są zarezerwowane dla URI. To gwarantuje, że postępujesz właściwie. Klient musi odpowiednio zdekodować identyfikator URI, skąd został odebrany. Tak, this+address@gmail.comto bardzo ważny adres e-mail; tak this%2Baddress@gmail.comjest również ważne. Tak, te dwa są różne, ale to, czy zostaną potraktowane inaczej, zależy od klienta ...

Jak wspomniano wcześniej, nie wszyscy klienci renderują to poprawnie. Sugeruję znalezienie najbardziej prawdopodobnego klienta (Gmaila? Przeglądarki opartej na przeglądarce? Outlooka?), Którego będą używać Twoi użytkownicy, i robienia tego, co robi ten klient. Powiedziałeś, że testowałeś na Gmailu? Jak to przetestowałeś? W przypadku „klienta mailto: opartego na przeglądarce (takiego jak dodatki do firefox i oferta Gmaila) najprawdopodobniej identyfikator URI nie jest dekodowany (tak jak powinien).

MOŻESZ kodować +, ale nie musisz.

Po pierwsze, musimy się zgodzić, że mailtojest to przykład ogólnego identyfikatora URI, określonego przez RFC 2396 . (Właśnie tego używają XHTML i HTML 4).

Teraz poznajmy listę zarezerwowanych znaków w RFC 2396.

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

URI dzieli się na bezwzględne i względne:

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

A ponieważ mailto:określono schemat, jest to bezwzględny identyfikator URI:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

A od obu wzorów na hier_partpoczątek /, mailtojest nieprzezroczysta część.

opaque_part   = uric_no_slash *uric

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

uric          = reserved | unreserved | escaped

Ograniczeniem jest to, że musisz uciec, /jeśli chodzi o pierwszą postać, ale potem możesz wstawić zastrzeżone znaki, w tym +i @.

Oto kolejny RFC, który to obsługuje. W najnowszej wersji RFC programu mailto opublikowanej w 2010 r. O nazwie RFC 6068 napisano:

Oprogramowanie tworzące 'mailto'identyfikatory URI również musi ostrożnie kodować wszelkie używane znaki zastrzeżone. Formularze HTML to jeden rodzaj oprogramowania, które tworzy 'mailto'identyfikatory URI. Obecne implementacje kodują spację jako '+', ale stwarza to problemy, ponieważ takiej pozycji '+'dla spacji nie można odróżnić od rzeczywistej '+'w 'mailto' URI. Podczas tworzenia 'mailto'identyfikatorów URI wszystkie spacje POWINNY być zakodowane jako %20, a '+'znaki MUSZĄ być zakodowane jako %2B. Należy pamiętać, że '+' znaki są często używane jako część adresu e-mail do wskazania podadresu, na przykład w <bill+ietf@example.org>.

Ścisła lektura odpowiedniego dokumentu RFC mówi, że znak „+” należy zakodować.

Sekcja 2, góra strony 2 na http://tools.ietf.org/html/rfc2368 mówi:

„Uwaga: wszystkie znaki zastrzeżone w adresie URL w„ do ”muszą być zakodowane: w szczególności nawiasy, przecinki i znak procentu („% ”), które zwykle występują w składni„ skrzynki pocztowej ”.”

RFC dla identyfikatorów URI (http://tools.ietf.org/html/rfc3986#section-2.2) wymienia „+” jako znak zastrzeżony.

To powiedziawszy, „poprawne” niekoniecznie musi działać we wszystkich przeglądarkach. Niektóre przeglądarki będą oczywiście zawsze obsługiwały prawidłowe rzeczy, tak jakby były one błędne, a te niepoprawne, jakby miały rację.

Edycja: Jeśli chodzi o RFC6068 i jego „MAY”, czytałbym to jako zależne od kontekstu. Jeśli piszesz adres URL do czytania tekstu, wtedy „+” miałoby większy sens, jednak jeśli piszesz go w HTML, bardziej rygorystyczna interpretacja RFC3986 byłaby bardziej zgodna z ideami „poprawnego HTML”, a więc wszystko, co używa tej wartości, powinno spodziewaj się, że zostanie zakodowany.

Zgodnie z nowym RFC http://tools.ietf.org/html/rfc6068#section-5

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

Myślę, że odpowiedź brzmi „nie”, ale może?

Myślę, że to kodowanie czy nie, nie zrobi żadnej różnicy. Problemem są klienci pocztowi. Na przykład, Yahoo Mail używa tylko myślnika do podadresowania, podczas gdy gMail używa plus.

To moje 2 centy ...

EDYCJA: Poniższa odpowiedź ma solidny punkt.

RFC1738

3.5 MAILTO

Schemat adresu URL mailto służy do wyznaczenia internetowego adresu pocztowego osoby lub usługi. Żadne dodatkowe informacje poza adresem do korespondencji internetowej nie są obecne ani dorozumiane.

Adres URL mailto ma postać:

    mailto:<rfc822-addr-spec>

gdzie jest (kodowanie) specyfikacji addr, jak określono w RFC 822 . W adresach URL mailto nie ma znaków zastrzeżonych.

Zauważ, że znak procentu („%”) jest powszechnie używany w adresach RFC 822 i musi być zakodowany.

W przeciwieństwie do wielu adresów URL, schemat mailto nie reprezentuje obiektu danych, do którego można uzyskać bezpośredni dostęp; nie ma sensu, w jakim określa obiekt. Ma inne zastosowanie niż typ wiadomości / treści zewnętrznej w MIME.

Ponieważ nie ma znaków zastrzeżonych, należy go zakodować.

Zgodnie z RFC 6068, jak wspomniano w odpowiedziach, MOŻESZ zakodować znak plus jako %2B.

Powodem zamieszania jest to, że przekształcenie spacji w plus nie jest tak naprawdę częścią standardowego kodowania adresu URL, lecz częścią kodowania parametrów formularza (tj. application/x-www-form-urlencoded)

To jest jak różnica między PHP rawurlencode()a urlencode().

Zatem RFC 6068 mówi, że mailto:adres URL powinien używać „surowego” standardowego kodowania adresu URL (zgodnie z RFC 3986 ), a znak plus wyświetlany w adresie URL powinien zawsze być traktowany jako dosłowny znak plus, a nie jako spacja, która ma zostały zakodowane w formie.

Jeśli klient lokalny przekształci plus na spację, zostanie on zepsuty.