Entwicklertools · URL-Encoder und -Decoder
So kodieren Sie ein Mailto: Link mit Betreff, Zeilenumbrüchen im Text und kaufmännischen Und-Zeichen
· Warum es wichtig ist
mailto URL-Kodierung html
Ein mailto:-Link mit Betreff und Text ist eine URL, daher müssen Leerzeichen, Zeilenumbrüche und & prozentual codiert sein. Dieser Beitrag zeigt, was kaputt geht, wenn nicht, und wie man einen Link erstellt, der in E-Mail-Clients korrekt geöffnet wird.
Der Kontaktlink, dessen Betreff beim ersten Leerzeichen stehen blieb – ein konkreter defekter Mailto: und was der Mail-Client erhalten hat
Kontaktlinks wie <a href="mailto:test@example.com?subject=Support Inquiry">Send</a> unterbrechen, da Leerzeichen in „Support Inquiry“ Links in E-Mail-Clients beenden. Viele Kunden erhalten als Betreff nur „Support“. Dies liegt daran, dass „mailto: links“ RFC 6068 folgt und angibt, dass Leerzeichen und Sonderzeichen in Abfrageparametern eine prozentuale Kodierung erfordern. Kaufmännische Und-Zeichen benötigen die Codierung %26, um keine Parametertrennzeichen zu sein.
Defekte Mailto-Links zeigen das Problem deutlich. Konstruierte Links wie <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">Kontakt</a> führen nur zu Nachrichten mit dem Betreff „Support“. Tests in verschiedenen Mail-Clients zeigen unterschiedliche Toleranzen: Apple Mail verarbeitet Links teilweise, Gmail zeigt nur „Support“ an, Outlook scheitert komplett.
mailto: ist ein URL-Schema – kurz RFC 6068, und welche Teile sind die Abfragezeichenfolge
RFC 6068 definiert mailto: URL-Schemata mit komponentenspezifischen Kodierungsregeln. Im Gegensatz zu regulären URLs gelten für mailto: spezifische Regeln pro Komponente. Adressteile (test@example.com) bleiben unverschlüsselt; @ und Domänen sind strukturell. Abfrageparameter (Betreff, Text, CC, BCC) müssen kodiert werden. RFC 6068 verweist auf RFC 3986 für Regeln und schreibt eine prozentuale Codierung für Leerzeichen und Sonderzeichen vor. Kaufmännische Und-Zeichen innerhalb von Werten werden zu %26, wenn sie als Daten und nicht als Trennzeichen angezeigt werden.
Das Verständnis der Struktur des mailto:-Schemas verhindert Codierungsfehler. Die Form ist: mailto:address?parameter1=value1¶meter2=value2. Fragezeichen leiten Abfrageabschnitte ein. Kaufmännische Und-Zeichen, die Parameter trennen, bleiben unverschlüsselt; Nur kaufmännische Und-Zeichen innerhalb von Werten werden als %26 kodiert. Wenn Betreffzeilen „Tom & Jerry“ enthalten, kodieren Sie als Tom%20%26%20Jerry. Kaufmännische Und-Zeichen zwischen Betreff und Text bleiben unverschlüsselt. Diese verschachtelte Kodierung ist fehleranfällig.
Codierung des Betreffs und des Textkörpers – Leerzeichen als %20, Zeilenumbrüche als %0D%0A und & als %26 innerhalb von Werten
Das Kodieren von Subjekten und Körpern erfordert einen sorgfältigen Umgang mit Leerzeichen und Sonderzeichen. Leerzeichen werden in mailto:-Links zu %20, im Gegensatz zu HTML-Formularen nicht zu Pluszeichen. Dieser entscheidende Unterschied bringt Entwickler, die mit Webformularen vertraut sind, aus der Fassung. Zeilenumbrüche werden als %0D%0A (CRLF-Zeilenenden in E-Mails) kodiert. Et-Zeichen werden zu %26. Prozentzeichen werden zu %25. Betreffzeilen enthalten normalerweise Leerzeichen, Akzente und Klammern. Körper enthalten Leerzeichen, Akzente und Zeilenumbrüche.
Zu den gängigen Codierungen in mailto:-Links gehören: Leerzeichen als %20, Zeilenumbrüche als %0D%0A, kaufmännische Und-Zeichen als %26, Prozent als %25, Hash als %23, Frage als %3F. Nicht-ASCII-ähnliche Akzente werden zuerst in UTF-8 Bytes konvertiert und dann in Prozent kodiert. „Überbericht“ wird zu %C3%9ber%20report. „Hallo! „Auf Wiedersehen“ wird zu „Hallo%21%0D%0AAuf Wiedersehen“. Nur Werte kodieren, nicht strukturell? und & Zeichen.
Arbeitsbeispiel: Erstellen eines Links mit Betreff, zweizeiligem Text und CC – das codierte Ergebnis und wie es in einem E-Mail-Client angezeigt wird
Arbeitsbeispiel: Erstellen von Links mit Betreff „Tagesordnung der Besprechung (September)“, Text „Lassen Sie uns besprechen: Vierteljährliche Ziele“ und CC „manager@example.com“ demonstrieren die vollständige Codierung. Betreffs benötigen: Leerzeichen als %20, Klammern als %28 und %29. Körper benötigen: „Lasst uns diskutieren:“ größtenteils unverändert (Leerzeichen ist %20), Zeilenumbrüche als %0D%0A, „Vierteljährliche Ziele“ größtenteils unverändert. Das CC-Feld erfordert keine Codierung.
Das resultierende Mailto lautet: mailto:contact@example.com?subject=Meeting%20agenda%20%28Sept%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com. Tests in Browsern zeigen unterschiedliche Interpretationen von E-Mail-Clients. Gmail öffnet Fenster zum Verfassen mit korrektem Betreff, zweizeiligem Text und CC. Outlook zeigt ähnliche Ergebnisse. Für Apple Mail sind Berechtigungen erforderlich. Ältere Klienten scheitern an fehlender Körperunterstützung.
Warum + hier falsch ist – mailto: folgt RFC 3986, nicht der Formkodierung, also bleibt + ein Plus
Warum Pluszeichen falsch sind – mailto: folgt RFC 3986, nicht der Formkodierung, also bleibt Plus wörtlich – verdeutlicht wichtige Unterscheidungen. Bei der HTML-Formularcodierung wird das Pluszeichen für Leerzeichen in Abfragezeichenfolgen verwendet. RFC 3986 und RFC 6068 geben beide %20 für Leerzeichen an. Ein Mailto: mit subject="Meeting+Agenda" erstellt Betreffzeilen mit wörtlichen Pluszeichen, nicht mit Leerzeichen. Dieser Fehler tritt auf, wenn die Formularcodierungslogik in mailto: generation kopiert wird. Plus bedeutet Plus, nicht Leerzeichen.
Warum das wichtig ist: Entwickler kopieren die GET-Übermittlungslogik des Formulars nach mailto: Unterbrechungslinks generieren. Ein Betreff „Meeting Agenda“ wird in Formularen zu „Meeting+Agenda“. In mailto:links wird „Meeting+Agenda“ mit wörtlichen Pluspunkten erstellt. Benutzer korrigieren Betreffzeilen manuell. Zum Testen von mailto:-Links müssen Sie darauf klicken oder die generierten Links untersuchen, nicht die Formularregeln analysieren.
Häufige Fehler – vergessen, die &-Trennzeichen im href mit einem HTML-Escape zu versehen und das @ in der Adresse in Prozent zu kodieren
Zu den häufigsten Fehlern beim Erstellen von mailto: gehört das Vergessen des HTML-kaufmännischen Und-Escapezeichens in href-Attributen. In HTML sollten kaufmännische Und-Zeichen in Attributen für gültiges XHTML & lauten. href="mailto:address?subject=Test&body=Test" ist ungültiges HTML; es sollte href="mailto:address?subject=Test&body=Test" lauten. Dies stellt eine andere Kodierung als die URL-Kodierung dar. HTML-Parser interpretieren & als & bevor Browser URLs verarbeiten.
Um diese Fehler zu testen, müssen die HTML-Quelle und die Browserkonsolen untersucht werden. Klicken Sie mit der rechten Maustaste und wählen Sie „Element prüfen“, um die tatsächlichen href-Werte anzuzeigen. Kopieren Sie href-Werte, fügen Sie sie in die Adressleisten ein (mit dem Präfix „mailto:“) und überprüfen Sie E-Mail-Clients. Einige E-Mail-Links funktionieren in bestimmten Browsern, in anderen jedoch nicht. Automatisierte Tests sind schwierig, da mailto: externe Clients einbezieht und eine manuelle Überprüfung üblich ist.
Was dies nicht abdeckt – Unterschiede bei der Unterstützung von E-Mail-Clients und mehrere Empfänger im Detail
Was hiervon nicht abgedeckt ist, umfasst Unterschiede bei der E-Mail-Client-Unterstützung und mehrere Empfänger. Nicht alle Clients unterstützen gleichermaßen die RFC-Parameter 6068. Der Body-Parameter wird weitgehend unterstützt, aber einige ältere Clients ignorieren ihn. Die Parameter cc und bcc unterstützen Variablen. Für mehrere Empfänger sind durch Kommas getrennte E-Mail-Adressen erforderlich, wobei bei komplexen Adressen Kommas als %2C kodiert werden. Verschiedene Gebietsschemas erfordern für die Anzeige die richtige UTF-8-Codierung.
Die Entwicklung des E-Mail-Clients wirkt sich auf das Verhalten von mailto: auf allen Plattformen aus. Moderne Webmail-Clients (Gmail, Outlook.com) verfügen über eine bessere RFC 6068-Konformität als ältere Desktop-Clients. Mobile Clients verfügen manchmal über eine strengere Analyse. Einige unterstützen Rich Text, während andere nur einfachen Text unterstützen. Entwickler sollten mit E-Mail-Clients testen, die ihre Zielgruppen tatsächlich verwenden. Die tatsächlichen Implementierungen variieren trotz der RFC-Spezifikationen 6068.
Takeaway: Codieren Sie jeden Wert, behalten Sie die Struktur bei – wie der Einzelwertmodus des URL-Encoders und -Decoders Ihnen den codierten Betreff und den Text zum Einfügen liefert
Takeaway: Codieren Sie jeden Wert, behalten Sie die Struktur bei – der URL-Encoder- und Decoder-Einzelwertmodus erzeugt codierte Betreffzeilen und Körper, die zum Einfügen in Links bereit sind. Das Tool akzeptiert nicht codierte Werte wie „Meeting Agenda (Sept)“ und erzeugt „Meeting%20agenda%20%28Sept%29“. Kopieren Sie die Ausgabe direkt in mailto: href-Attribute. Fügen Sie bei mehrzeiligen Texten Klartextversionen mit Zeilenumbrüchen ein und erhalten Sie %0D%0A-codierte Versionen.
Best Practice stellt Mailto:-Links aus codierten Teilen zusammen, statt sie manuell zu erstellen. Wenn Sie HTML dynamisch in JavaScript oder Vorlagen erstellen, kodieren Sie jeden Parameter separat, bevor Sie ihn mit &-Trennzeichen verketten. Für statisches HTML testet der URL-Encoder und -Decoder zuverlässig die Kodierung vor der Handschrift. Kodierungsprozesse in Codekommentaren dokumentieren. Testen Sie die resultierenden mailto:-Links, indem Sie vor der Bereitstellung mit tatsächlichen E-Mail-Clients darauf klicken.