Plus dovrebbe essere codificato in mailto: hyperlink?

39

Quando si inserisce un indirizzo e-mail con un tag di indirizzo (noto anche come indirizzo secondario) in un collegamento ipertestuale mailto ...

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

... il plus nell'email deve essere codificato nell'URL?

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

Non riesco a capirlo e la documentazione è in conflitto. Anche i nostri test sul mondo reale hanno prodotto risultati contrastanti, rendendolo ancora più confuso.

hyperlink url-encoding mailto

— Jeff Atwood
fonte

Puoi essere più specifico sui metodi e sui risultati dei tuoi test nel mondo reale? Alcuni client / servizi di posta elettronica lo trattano correttamente e altri soffocano? Può essere più preciso?

— Bryson,

1

@bryson So che l'estensione di Chrome "invia usando gmail" ha avuto problemi con il plus non codificato nel mailto: per esempio, ma forse è un bug.

— Jeff Atwood,

2

Basta usare quello che funziona con Chrome.

— Hardwareguy,

22

Il plus viene utilizzato per codificare gli spazi negli URL, non in HTML e non in SMTP (RFC2821). Tuttavia, poiché mailto:address@server.comè un URI (ha un protocollo, il separatore di protocollo e l'indirizzo del protocollo), allora dovrebbe essere trattato come un URI e dovrebbe essere codificato in percentuale .

Pertanto, spetta al cliente risolvere con precisione la rappresentazione codificata e decodificarla nella misura appropriata. Ecco la versione ufficiale di Microsoft sull'argomento .

Dovresti applicare la codifica URL su mailto: URL incorporati in HTML se i caratteri nell'indirizzo email sono riservati all'URI. Questo assicura che stai facendo la cosa giusta. Spetta al cliente decodificare l'URI in modo appropriato da dove viene ricevuto. Sì, this+address@gmail.comè un'e-mail molto valida; sì this%2Baddress@gmail.comè anche valido. Sì, quei due sono diversi, ma se saranno trattati in modo diverso dipende dal cliente ...

Come notato in precedenza, non tutti i client eseguono il rendering correttamente. Suggerisco di trovare il client più probabile (gmail? Client basati su browser? Outlook?) Che gli utenti useranno e fare ciò che fa quel client. Hai detto di aver provato su GMail? Come lo hai provato? Con un "client mailto: client basato su browser (come componenti aggiuntivi dell'offerta firefox e gmail) è molto probabile che l'URI non venga decodificato (come dovrebbe essere).

— Wez Furlong
fonte

Qualcuno ha dei dati reali su ciò che funziona dove?

— Wez Furlong,

beh, ho fatto una nota specifica di ciò che Microsoft afferma funziona ...

— jcolebrand,

Questo è perfetto. Gmail non li gestisce correttamente, ma poiché Google ignora le segnalazioni di bug degli utenti non c'è molto che puoi fare al riguardo.

— Matthew Leggi il

5

Se hai codificato +in URI, devi @anche essere codificato perché è anche un carattere riservato. Se leggi attentamente la RFC, scoprirai che in una parte opaca +è legale.

— Eugene Yokota,

Potrei sbagliarmi, ma non è riservato separare il nome utente dall'host (come in esempio@esempio.com/percorso )? Quindi si posizionerebbe nell'indirizzo poiché separa il nome utente dall'host.

— Maciej Piechotka,

8

Potresti codificare +, ma non è necessario.

Innanzitutto, dobbiamo concordare che si mailtotratta di un esempio di URI generico, specificato da RFC 2396 . (Questo è ciò che usano XHTML e HTML 4).

Ora scopriamo l'elenco dei caratteri riservati in RFC 2396.

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

L'URI si divide in assoluto e relativo:

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

E poiché lo schema mailto:è specificato, questo è un URI assoluto:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

E poiché entrambi i motivi per hier_partcominciare /, mailtoè una parte opaca.

opaque_part   = uric_no_slash *uric

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

uric          = reserved | unreserved | escaped

Quindi la restrizione è che devi scappare /se si tratta del primo personaggio, ma dopo puoi inserire personaggi riservati tra cui +e @.

Ecco un altro RFC per supportare questo. Negli ultimi RFC dello schema mailto pubblicato nel 2010 chiamato RFC 6068 , si afferma:

'mailto'Allo stesso modo, il software che crea gli URI deve fare attenzione a codificare tutti i caratteri riservati utilizzati. I moduli HTML sono un tipo di software che crea 'mailto'URI. Le attuali implementazioni codificano uno spazio come '+', ma questo crea problemi perché una tale '+'posizione per uno spazio non può essere distinta da un reale '+'in un 'mailto' URI. Quando si producono 'mailto'URI, tutti gli spazi DOVREBBERO essere codificati come %20e i '+'caratteri POSSONO essere codificati come %2B. Si noti che i '+' caratteri vengono spesso utilizzati come parte di un indirizzo e-mail per indicare un indirizzo secondario, come ad esempio in <bill+ietf@example.org>.

— Eugene Yokota
fonte

Non ho ancora familiarità con quella grammatica, tuttavia, elenca i caratteri come separati dal pool senza prenotazione, il che indica che + è un carattere riservato. Non indica che deve essere codificato. Microsoft dice di codificarlo. C'est la vie, aspetto di vedere.

— jcolebrand,

1

Quando una parte non inizia con /, +non diventa più un personaggio riservato.

— Eugene Yokota,

Non sono d'accordo. Gli "indirizzi e-mail" sono definiti in modo molto particolare e devono essere trattati con una certa cura in primo luogo. Tale standard è molto confuso. Fortunatamente, non possiamo essere d'accordo qui.

— jcolebrand,

8

Una lettura rigorosa della RFC pertinente afferma che il "+" dovrebbe essere codificato.

La sezione 2, all'inizio della pagina 2 su http://tools.ietf.org/html/rfc2368 dice:

"Nota che tutti i caratteri riservati URL in" a "devono essere codificati: in particolare, parentesi, virgole e il segno di percentuale ("% "), che si verificano comunemente nella sintassi" mailbox "."

RFC for URIs (http://tools.ietf.org/html/rfc3986#section-2.2) elenca "+" come carattere riservato.

Detto questo, ciò che è "corretto" non è necessariamente ciò che funzionerà in tutti i browser. Alcuni browser ovviamente gestiranno sempre le cose giuste come se fossero sbagliate e quelle errate come se fossero giuste.

Modifica: per quanto riguarda RFC6068 e il suo "MAGGIO", lo leggerei come dipendente dal contesto. Se stai scrivendo l'URL per la lettura del testo, allora "+" avrebbe più senso, tuttavia se lo scrivessi in HTML, l'interpretazione più rigorosa di RFC3986 sarebbe più in linea con idee "HTML valide" e quindi qualsiasi cosa che usi il valore dovrebbe aspettarsi che sia codificato.

— IBBoard
fonte

2

In RFC 3986, mailtoverrebbe trattato come path-rootless, il che consente una sequenza pchardefinita da (unreserved / pct-encoded / sub-delims / ":" / "@"). +fa parte di sub-delims. Quindi una lettura rigorosa dice +che non richiede la codifica percentuale.

— Eugene Yokota,

6

Per il nuovo RFC http://tools.ietf.org/html/rfc6068#section-5

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

Quindi immagino che la risposta sia no, ma forse?

— yuriismaster
fonte

3

Penso che codificarlo o no, non farà davvero la differenza. Il problema sono i client di posta. Ad esempio, Yahoo Mail utilizza il trattino solo per i sub-indirizzi, mentre gMail usa il plus.

Sono i miei 2 centesimi ...

EDIT: la risposta di seguito ha un punto solido.

— Bruno
fonte

vero, il punto positivo è che c'è una certa varianza nell'indirizzamento secondario delle e-mail, ma le e-mail in questo caso sono ospitate da gmail, quindi so che il plus è corretto e funzionerà quando ricevuto dal server, supponendo che l'e-mail passi attraverso il client.

— Jeff Atwood,

Il problema è l'applicazione che analizza la richiesta URI. Se si aspetta di ricevere dati con codifica URLE, decodificherà i dati, ma ciò non è né giusto per te (codificare in modo errato) né per il cliente (per fare ipotesi). Il protocollo non impone la codifica prevista, lo fa il client. Guarda le ulteriori modifiche apportate alla A di @Wez

— jcolebrand il

3

il RFC1738

3.5. MAILTO

Lo schema URL mailto viene utilizzato per designare l'indirizzo postale Internet di un individuo o di un servizio. Nessuna informazione aggiuntiva diversa da un indirizzo postale Internet è presente o implicita.

Un URL mailto ha la forma:
    mailto:<rfc822-addr-spec>
dove si trova (la codifica di un) addr-spec, come specificato in RFC 822 . All'interno degli URL mailto, non ci sono caratteri riservati.

Si noti che il segno di percentuale ("%") viene comunemente utilizzato negli indirizzi RFC 822 e deve essere codificato.

A differenza di molti URL, lo schema mailto non rappresenta un oggetto dati a cui accedere direttamente; non ha senso designare un oggetto. Ha un uso diverso rispetto al tipo messaggio / corpo esterno in MIME.

Poiché non ci sono caratteri riservati, è necessario codificarlo.

— S.Skov
fonte

e tuttavia per tools.ietf.org/html/rfc6068 "Quando si producono URI 'mailto', tutti gli spazi DOVREBBERO essere codificati come% 20 e i caratteri '+' POSSONO essere codificati come% 2B"

— Jeff Atwood,

1

Since there are no reserved characters it should be encoded.ummmm che non ha alcun senso.

— jcolebrand,

@jcolebrand '+' è un carattere speciale nello schema URL e quindi deve essere codificato quando non ha un ruolo speciale, ad es. quando non è riservato.

— S.Skov,

@Jeff In effetti - il mio male per vivere in un vecchio mondo RFC. Quindi tools.ietf.org/html/rfc2119 ti dice sostanzialmente di fare ciò che ritieni più adatto a te.

— S.Skov,

quello sembra ... all'indietro nello spirito del modo in cui ho letto le istruzioni inizialmente.

— jcolebrand,

3

Per RFC 6068 come indicato nelle risposte, PUOI codificare il segno più come %2B.

Il motivo della confusione è che la conversione di uno spazio in un plus non fa effettivamente parte della codifica URL standard, ma fa parte della codifica dei parametri del modulo (ovvero application/x-www-form-urlencoded)

È come la differenza tra PHP rawurlencode()e urlencode().

Quindi ciò che RFC 6068 sta dicendo è che un mailto:URL dovrebbe usare una codifica URL "grezza" (secondo RFC 3986 ), e un segno più che appare nell'URL dovrebbe sempre essere trattato come un segno più letterale, e non come uno spazio che ha stato codificato in forma.

Se il client locale converte il plus in uno spazio, si rompe.

— Alnitak
fonte