Strumenti per sviluppatori · URL codificatore e decodificatore
Come codificare un mailto: collegamento con oggetto, interruzioni di riga del corpo e e commerciale
· Perché è importante
mailto codifica dell'URL html
Un collegamento mailto: con un oggetto e un corpo è un URL, quindi gli spazi, le interruzioni di riga e & devono essere codificati in percentuale. Questo post mostra cosa si interrompe quando non lo è e come creare un collegamento che si apra correttamente nei client di posta.
Il collegamento di contatto il cui oggetto si ferma al primo spazio: un mailto concreto interrotto e ciò che il client di posta ha ricevuto
I collegamenti ai contatti come <a href="mailto:test@example.com?subject=Support Inquiry">Send</a> si interrompono perché gli spazi in "Richiesta di supporto" terminano i collegamenti nei client di posta. Molti clienti ricevono solo "Supporto" come oggetto. Ciò si verifica perché i collegamenti mailto: seguono RFC 6068, specificando che gli spazi e i caratteri speciali richiedono la codifica percentuale nei parametri di query. Le e commerciali necessitano della codifica %26 per evitare di essere separatori di parametri.
Mailto interrotto: i collegamenti dimostrano chiaramente il problema. I collegamenti costruiti come <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">Contact</a> restituiscono solo messaggi con oggetto "Supporto". I test su diversi client di posta rivelano tolleranze diverse: Apple Mail gestisce parzialmente i collegamenti, Gmail mostra solo "Supporto", Outlook fallisce completamente.
mailto: è uno schema URL — RFC 6068 in breve e quali parti sono la stringa di query
RFC 6068 definisce gli schemi mailto: URL con regole di codifica specifiche del componente. A differenza degli URL normali, mailto: ha regole specifiche per componente. Le parti dell'indirizzo (test@example.com) rimangono non codificate; @ e i domini sono strutturali. I parametri della query (oggetto, corpo, cc, bcc) devono essere codificati. RFC 6068 riferimenti RFC 3986 per le regole, imponendo la codifica percentuale per spazi e caratteri speciali. Le e commerciali all'interno dei valori diventano %26 quando vengono visualizzate come dati, non come delimitatori.
Comprendere mailto: la struttura dello schema previene errori di codifica. Il formato è: mailto:indirizzo?parametro1=valore1¶metro2=valore2. I punti interrogativi introducono sezioni di query. I parametri di separazione delle e commerciali rimangono non codificati; solo le e commerciali all'interno dei valori codificano come %26. Se gli oggetti contengono "Tom e Jerry", codificarli come Tom%20%26%20Jerry. Le e commerciali tra soggetto e corpo rimangono non codificate. Questa codifica annidata è soggetta a errori.
Codifica l'oggetto e il corpo: spazi come %20, interruzioni di riga come %0D%0A e & come %26 all'interno dei valori
La codifica di soggetti e corpi richiede un'attenta gestione degli spazi e dei caratteri speciali. Gli spazi diventano %20 nei collegamenti mailto: non segni più a differenza dei moduli HTML. Questa differenza fondamentale fa inciampare gli sviluppatori che hanno familiarità con i moduli web. Le interruzioni di riga vengono codificate come %0D%0A (terminazioni di riga CRLF nell'e-mail). Le e commerciali diventano %26. I segni di percentuale diventano %25. Gli oggetti in genere contengono spazi, accenti e parentesi. I corpi contengono spazi, accenti, interruzioni di riga.
Codifiche comuni in mailto: i collegamenti includono: spazi come %20, ritorni a capo come %0D%0A, e commerciale come %26, percentuale come %25, hash come %23, domanda come %3F. Gli accenti non simili a ASCII vengono prima convertiti in UTF-8 byte, quindi codificati in percentuale. "Über report" diventa %C3%9ber%20report. "Ciao! Arrivederci" diventa Hello%21%0D%0AAddio. Codificare solo valori, non strutturali? e & caratteri.
Esempio realizzato: creazione di un collegamento con oggetto, corpo di due righe e cc: il risultato codificato e come appare in un client di posta
Esempio realizzato: creazione di collegamenti con oggetto "Ordine del giorno della riunione (settembre)", corpo "Discutiamo: Obiettivi trimestrali" e cc "manager@example.com" dimostrano la codifica completa. Gli oggetti richiedono: spazi come %20, parentesi come %28 e %29. Gli enti necessitano di: "Discutiamo:" per lo più invariato (lo spazio è %20), interruzioni di riga come %0D%0A, "Obiettivi trimestrali" per lo più invariati. Il campo cc non richiede codifica.
Il collegamento risultante è mailto:contact@example.com?subject=Meeting%20agenda%20%28Sept%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com. I test nei browser mostrano interpretazioni diverse tra i client di posta. Gmail apre la finestra di composizione con oggetto, corpo su due righe e CC corretti. Outlook mostra risultati simili. Apple Mail richiede le autorizzazioni. I client meno recenti possono non supportare il corpo del messaggio.
Perché + è sbagliato qui - mailto: segue RFC 3986, non la codifica del modulo, quindi + rimane un vantaggio
Perché i segni più sono sbagliati—mailto: segue RFC 3986, non la codifica del modulo, quindi più rimane letterale—chiarisce le distinzioni critiche. La codifica del modulo HTML utilizza il segno più per gli spazi nelle stringhe di query. RFC 3986 e RFC 6068 specificano entrambi %20 per gli spazi. Un mailto: with object="Meeting+Agenda" crea oggetti con segni più letterali, non spazi. Questo errore si verifica copiando la logica di codifica del modulo in mailto: generation. Plus significa più, non spazio.
Perché è importante: gli sviluppatori copiano la logica di invio del modulo GET a mailto: collegamenti di interruzione della generazione. Un argomento "Agenda della riunione" diventa "Riunione+Agenda" nei moduli. In mailto: links, crea "Meeting+Agenda" con vantaggi letterali. Gli utenti correggono manualmente le righe dell'oggetto. Testare mailto: i collegamenti richiedono di fare clic su di essi o di esaminare i collegamenti generati, non di analizzare le regole del modulo.
Errori comuni: dimenticare di HTML-escape i separatori & nell'href e codificare in percentuale la @ nell'indirizzo
Mailto comune: gli errori di creazione includono l'omissione di HTML e l'escape della e commerciale negli attributi href. In HTML, la e commerciale negli attributi deve essere & per XHTML valido. href="mailto:address?subject=Test&body=Test" non è valido HTML; dovrebbe essere href="mailto:address?subject=Test&body=Test". Ciò rappresenta una codifica diversa dalla codifica URL. I parser HTML interpretano & come e prima che i browser elaborino gli URL.
Per verificare la presenza di questi errori è necessario esaminare il codice sorgente HTML e le console del browser. Fare clic con il tasto destro e selezionare "Ispeziona elemento" per visualizzare i valori href effettivi. Copia e incolla i valori href nelle barre degli indirizzi (con prefisso mailto:) e controlla i client di posta. Alcuni collegamenti e-mail funzionano in determinati browser ma non in altri. I test automatizzati sono difficili perché mailto: coinvolge clienti esterni, rendendo comune la verifica manuale.
Cosa non copre: differenze nel supporto dei client di posta e destinatari multipli in modo approfondito
Ciò che non copre include le differenze nel supporto dei client di posta e i destinatari multipli. Non tutti i client supportano ugualmente i parametri RFC 6068. Il parametro body ha un ampio supporto ma alcuni client meno recenti lo ignorano. I parametri cc e bcc hanno supporto variabile. Più destinatari richiedono indirizzi e-mail separati da virgole, codificando le virgole come %2C per indirizzi complessi. Locali diverse richiedono la codifica UTF-8 corretta per la visualizzazione.
L'evoluzione del client di posta influisce sul comportamento di mailto su tutte le piattaforme. I moderni client di posta web (Gmail, Outlook.com) hanno una migliore conformità RFC 6068 rispetto ai client desktop meno recenti. I client mobili a volte hanno un'analisi più rigorosa. Alcuni supportano il testo RTF mentre altri supportano solo il testo normale. Gli sviluppatori dovrebbero testare i client di posta effettivamente utilizzati dal loro pubblico. Le implementazioni reali variano nonostante le specifiche RFC 6068.
Conclusione: codifica ogni valore, mantieni la struttura: in che modo la modalità a valore singolo del codificatore e decodificatore URL ti fornisce l'oggetto codificato e il corpo da incollare
Conclusione: codifica ogni valore, mantieni la struttura: la modalità a valore singolo URL codificatore e decodificatore produce soggetti e corpi codificati pronti da incollare nei collegamenti. Lo strumento accetta valori non codificati come "Agenda della riunione (settembre)" e produce "Meeting%20agenda%20%28settembre%29". Copia l'output direttamente negli attributi mailto: href. Per corpi su più righe, incolla le versioni in testo normale con interruzioni di riga, ottenendo versioni con codifica %0D%0A.
Le migliori pratiche assemblano mailto: collegamenti da parti codificate anziché da costruzioni manuali. Quando crei HTML dinamicamente in JavaScript o modelli, codifica ciascun parametro separatamente prima di concatenarlo con i separatori &. Per il codificatore e decodificatore HTML statico, URL verifica in modo affidabile la codifica prima della scrittura a mano. Processi di codifica dei documenti nei commenti del codice. Testare i collegamenti mailto: risultanti facendo clic su di essi con i client di posta effettivi prima della distribuzione.