Outils de développement · Encodeur et décodeur d'URL
Comment encoder un mailto : lien avec le sujet, les sauts de ligne et les esperluettes
· Pourquoi c'est important
mailà encodage d'URL html
Un lien mailto: avec un sujet et un corps est une URL, donc les espaces, les sauts de ligne et & doivent être codés en pourcentage. Cet article montre ce qui se brise quand ce n'est pas le cas et comment créer un lien qui s'ouvre correctement dans les clients de messagerie.
Le lien de contact dont le sujet s'est arrêté au premier espace — un mailto concret cassé : et ce que le client de messagerie a reçu
Les liens de contact tels que <a href="mailto:test@example.com?subject=Support Inquiry">Envoyer</a> sont interrompus, car les espaces dans "Support Inquiry" terminent les liens dans les clients de messagerie. De nombreux clients ne reçoivent que « Support » comme sujet. Cela se produit parce que les liens mailto: suivent la RFC 6068, spécifiant que les espaces et les caractères spéciaux nécessitent un codage en pourcentage dans les paramètres de requête. Les esperluettes nécessitent un codage %26 pour éviter d'être des séparateurs de paramètres.
Mailto brisé : les liens démontrent clairement le problème. Les liens construits comme <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">Contact</a> aboutissent à des messages avec le sujet « Support » uniquement. Les tests effectués sur différents clients de messagerie révèlent des tolérances variables : Apple Mail gère partiellement les liens, Gmail affiche uniquement "Support", Outlook échoue complètement.
mailto : est un schéma d'URL — RFC 6068 en bref, et quelles parties constituent la chaîne de requête
RFC 6068 définit mailto : schémas d'URL avec des règles de codage spécifiques aux composants. Contrairement aux URL classiques, mailto : a des règles spécifiques par composant. Les parties d'adresse (test@example.com) restent non codées ; @ et les domaines sont structurels. Les paramètres de requête (sujet, corps, cc, bcc) doivent être codés. La RFC 6068 fait référence à la RFC 3986 pour les règles, exigeant un codage en pourcentage pour les espaces et les caractères spéciaux. Les esperluettes dans les valeurs deviennent %26 lorsqu'elles apparaissent sous forme de données et non de délimiteurs.
Comprendre mailto : la structure du schéma évite les erreurs d'encodage. Le formulaire est : mailto:address?parameter1=value1¶meter2=value2. Les points d'interrogation introduisent des sections de requête. Les esperluettes séparant les paramètres restent non codées ; seules les esperluettes comprises dans les valeurs sont codées sous la forme %26. Si les sujets contiennent "Tom & Jerry", codez comme Tom%20%26%20Jerry. Les esperluettes entre le sujet et le corps restent non codées. Cet encodage imbriqué est sujet aux erreurs.
Codage du sujet et du corps — espaces sous la forme %20, sauts de ligne sous la forme %0D%0A et & sous la forme %26 à l'intérieur des valeurs
L'encodage des sujets et des corps nécessite une gestion minutieuse des espaces et des caractères spéciaux. Les espaces deviennent %20 dans les liens mailto:, pas de signes plus contrairement aux formulaires HTML. Cette différence critique déconcerte les développeurs familiers avec les formulaires Web. Les sauts de ligne sont codés sous la forme %0D%0A (fins de ligne CRLF dans l'e-mail). Les esperluettes deviennent %26. Les signes de pourcentage deviennent %25. Les sujets contiennent généralement des espaces, des accents et des parenthèses. Les corps contiennent des espaces, des accents, des sauts de ligne.
Les encodages courants dans mailto : les liens incluent : les espaces sous la forme %20, les nouvelles lignes sous la forme %0D%0A, les esperluettes sous la forme %26, le pourcentage sous la forme %25, le hachage sous la forme %23, la question sous la forme %3F. Les accents non-ASCII sont d'abord convertis en UTF-8 octets, puis encodés en pourcentage. "Über rapport" devient %C3%9ber%20report. "Bonjour ! Au revoir" devient Bonjour%21%0D%0AGoodbye. Encoder uniquement les valeurs, pas structurelles ? et & caractères.
Exemple pratique : création d'un lien avec le sujet, le corps sur deux lignes et cc – le résultat codé et comment il apparaît dans un client de messagerie
Exemple concret : création de liens avec le sujet "Ordre du jour de la réunion (septembre)", corps "Discutons : Objectifs trimestriels" et cc "manager@example.com" démontrent l'encodage complet. Les sujets ont besoin : d'espaces comme %20, de parenthèses comme %28 et %29. Les corps ont besoin : « Discutons : » pour la plupart inchangé (l’espace est %20), les sauts de ligne comme %0D%0A, « Objectifs trimestriels » pour la plupart inchangés. Le champ cc ne nécessite aucun encodage.
Le mailto résultant : est : mailto:contact@example.com?subject=Meeting%20agenda%20%28Sept%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com. Les tests dans les navigateurs révèlent différentes interprétations des clients de messagerie. Gmail ouvre les fenêtres de rédaction avec le sujet correct, le corps de deux lignes et cc. Outlook affiche des résultats similaires. Apple Mail nécessite des autorisations. Les clients plus âgés échouent faute de soutien corporel.
Pourquoi + est faux ici — mailto : suit la RFC 3986, pas l'encodage de formulaire, donc + reste un plus
Pourquoi les signes plus sont faux — mailto : suit la RFC 3986, pas l'encodage de formulaire, donc plus reste littéral — clarifie les distinctions critiques. L'encodage des formulaires HTML utilise le signe plus pour les espaces dans les chaînes de requête. RFC 3986 et RFC 6068 spécifient toutes deux %20 pour les espaces. Un mailto : avec subject="Meeting+Agenda" crée des sujets avec des signes plus littéraux, pas des espaces. Cette erreur se produit lors de la copie de la logique d'encodage de formulaire dans mailto: génération. Plus signifie plus, pas espace.
Pourquoi c'est important : les développeurs copient la logique de soumission du formulaire GET vers mailto : génération de liens de rupture. Un sujet « Agenda de réunion » devient « Réunion+Agenda » dans les formulaires. Dans mailto: links, il crée "Réunion+Agenda" avec des avantages littéraux. Les utilisateurs corrigent manuellement les lignes d'objet. Tester les liens mailto : nécessite de cliquer dessus ou d'examiner les liens générés, et non d'analyser les règles du formulaire.
Erreurs courantes : oublier d'échapper au HTML les séparateurs & dans le href et d'encoder en pourcentage le @ dans l'adresse.
Mailto courant : les erreurs de construction incluent l'oubli de l'esperluette HTML qui s'échappe dans les attributs href. En HTML, les esperluettes dans les attributs doivent être & pour un XHTML valide. href="mailto:address?subject=Test&body=Test" n'est pas un code HTML valide ; cela devrait être href="mailto:address?subject=Test&body=Test". Cela représente un codage différent du codage URL. Les analyseurs HTML interprètent & au fur et à mesure que les navigateurs traitent les URL.
Pour tester ces erreurs, vous devez examiner la source HTML et les consoles du navigateur. Cliquez avec le bouton droit et sélectionnez « Inspecter l'élément » pour afficher les valeurs href réelles. Copiez-collez les valeurs href dans les barres d'adresse (avec le préfixe mailto:) et vérifiez les clients de messagerie. Certains liens de messagerie fonctionnent dans certains navigateurs mais pas dans d'autres. Les tests automatisés sont difficiles car mailto : implique des clients externes, ce qui rend la vérification manuelle courante.
Ce que cela ne couvre pas : différences en profondeur dans la prise en charge des clients de messagerie et plusieurs destinataires
Ce qui ne couvre pas inclut les différences de prise en charge des clients de messagerie et les destinataires multiples. Tous les clients ne prennent pas également en charge les paramètres RFC 6068. Le paramètre body bénéficie d'un large support, mais certains clients plus anciens l'ignorent. Les paramètres cc et bcc ont un support variable. Les destinataires multiples nécessitent des adresses e-mail séparées par des virgules, codées par des virgules en %2C pour les adresses complexes. Différents paramètres régionaux nécessitent un encodage UTF-8 approprié pour l'affichage.
L'évolution du client de messagerie affecte le comportement de mailto : sur toutes les plateformes. Les clients de messagerie Web modernes (Gmail, Outlook.com) sont mieux conformes à la RFC 6068 que les anciens clients de bureau. Les clients mobiles ont parfois une analyse plus stricte. Certains prennent en charge le texte enrichi tandis que d'autres ne prennent en charge que le texte brut. Les développeurs devraient tester avec les clients de messagerie que leurs publics utilisent réellement. Les implémentations réelles varient malgré les spécifications RFC 6068.
À retenir : encodez chaque valeur, conservez la structure - comment le mode à valeur unique de l'encodeur et du décodeur d'URL vous donne le sujet et le corps encodés à coller
À retenir : encodez chaque valeur, conservez la structure : le mode à valeur unique de l'encodeur et du décodeur d'URL produit des sujets et des corps encodés prêts à être collés dans des liens. L'outil accepte les valeurs non codées telles que « Agenda de la réunion (septembre) » et produit « Meeting%20agenda%20%28Sept%29 ». Copiez la sortie directement dans les attributs mailto : href. Pour les corps multilignes, collez les versions en texte brut avec des sauts de ligne, pour obtenir les versions codées %0D%0A.
Les meilleures pratiques assemblent mailto : liens à partir de pièces codées plutôt que de construction manuelle. Lors de la création dynamique de HTML dans JavaScript ou dans des modèles, encodez chaque paramètre séparément avant de concaténer avec des séparateurs &. Pour le HTML statique, l'encodeur et le décodeur d'URL testent de manière fiable l'encodage avant l'écriture manuscrite. Documentez les processus d’encodage dans les commentaires de code. Testez les liens mailto : en cliquant dessus avec les clients de messagerie réels avant le déploiement.