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

39

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

<a href="mailto:[email protected]">mail us now!</a>

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

<a href="mailto:username%[email protected]">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.

hyperlink url-encoding mailto Jeff Atwood
źródło
Czy możesz bardziej szczegółowo określić metody i wyniki swoich testów w świecie rzeczywistym? Czy niektórzy klienci / usługi poczty elektronicznej traktują to poprawnie, a inni dławią się? Czy mógłbyś to sprecyzować?
Bryson,
1
@bryson Wiem, że rozszerzenie chrome „wyślij za pomocą Gmaila” miało problemy z niezakodowanym plusem w mailto: na przykład, ale być może to jest błąd.
Jeff Atwood
2
Po prostu użyj dowolnego, który działa z chromem.
Hardwareguy,

Odpowiedzi:

22

Znak plus służy do kodowania spacji w adresach URL, a nie w HTML i nie w SMTP (RFC2821). Ponieważ jednak mailto:[email protected]jest 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, [email protected]to bardzo ważny adres e-mail; tak this%[email protected]jest 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).

Wez Furlong
źródło
Czy ktoś ma jakieś dane na temat tego, co działa gdzie?
Wez Furlong
no cóż, zwróciłem szczególną uwagę na to, co Microsoft potwierdza, że ​​działa ...
jcolebrand,
To jest na miejscu. Gmail nie obsługuje ich poprawnie, ale ponieważ Google ignoruje zgłoszenia błędów użytkowników, niewiele można z tym zrobić.
Matthew przeczytał
5
Jeśli masz kodowanie +w URI, @również należy go zakodować, ponieważ jest to również znak zastrzeżony. Jeśli dokładnie przeczytasz RFC, przekonasz się, że w nieprzejrzystej części +jest legalne.
Eugene Yokota,
Mogę się mylić, ale czy nie jest zarezerwowane oddzielanie nazwy użytkownika od hosta (na przykład w [email protected]/path )? Następnie umieściłby swoje miejsce w adresie, ponieważ oddziela nazwę użytkownika od hosta.
Maciej Piechotka
8

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 <[email protected]>.

Eugene Yokota
źródło
Nie jestem do końca zaznajomiony z tą gramatyką, jednak wyświetla ona znaki jako oddzielne od niezarezerwowanej puli, co wskazuje, że + jest znakiem zarezerwowanym. Nie oznacza to, że należy go zakodować. Microsoft mówi, aby go zakodować. C'est la vie, czekam, aby zobaczyć.
jcolebrand
1
Kiedy część nie zaczyna się /, +nie staje się już postacią zarezerwowaną.
Eugene Yokota,
Nie zgadzam się. „adresy e-mail” są bardzo szczegółowo zdefiniowane i muszą być traktowane z pewną ostrożnością. Ten standard jest bardzo mylący. Na szczęście możemy się tutaj nie zgodzić.
jcolebrand
8

Ś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.

IBBoard
źródło
2
W RFC 3986 mailtobyłby traktowany jako path-rootless, co pozwala na sekwencję pcharzdefiniowaną przez (unreserved / pct-encoded / sub-delims / ":" / "@"). +jest częścią sub-delims. Czytanie ścisłe mówi, +że nie wymaga kodowania procentowego.
Eugene Yokota,
3

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.

Bruno
źródło
prawda, dobra uwaga, że ​​istnieje pewna wariancja podadresowania e-maili - ale e-maile w tym przypadku są hostowane przez Gmaila, więc wiem, że plus jest poprawny i zadziała po otrzymaniu przez serwer, zakładając, że e-mail dostaje się przez klienta.
Jeff Atwood
Problem polega na tym, że aplikacja analizuje żądanie URI. Jeśli spodziewa się odebrać dane zakodowane w URLE, wówczas dekoduje dane, ale nie jest to ani uczciwe wobec ciebie (w przypadku fałszywego kodowania), ani wobec klienta (w celu przyjęcia założeń). Protokół nie określa oczekiwanego kodowania, tak robi klient. Zobacz kolejne zmiany, które wprowadzam do A przez @Wez
jcolebrand,
3

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ć.

S.Skov
źródło
a jednak według tools.ietf.org/html/rfc6068 „Podczas tworzenia identyfikatorów URI„ mailto ”wszystkie spacje POWINNY być zakodowane jako% 20, a znaki„ + ”MUSZĄ być zakodowane jako% 2B”
Jeff Atwood
1
Since there are no reserved characters it should be encoded.ummmm, to nie ma sensu.
jcolebrand
@jcolebrand '+' jest znakiem specjalnym w schemacie URL i dlatego musi zostać zakodowany, gdy nie pełni specjalnej roli - tj. kiedy nie jest zarezerwowane.
S.Skov
@Jeff Rzeczywiście - moje złe życie w starszym świecie RFC. Następnie tools.ietf.org/html/rfc2119 w zasadzie mówi ci, abyś robił to, co według ciebie pasuje najlepiej.
S.Skov
to wydaje się .... w duchu wstecz do sposobu, w jaki początkowo czytałem instrukcje.
jcolebrand
3

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.

Alnitak
źródło