Online-URL-Encoder und -Decoder

1. 1

   Kodieren oder Dekodieren wählen

   Kodieren wandelt Zeichen, die eine URL nicht wörtlich tragen kann, in Prozentsequenzen um. Dekodieren macht das rückgängig. Das Ergebnis aktualisiert sich während der Eingabe, für eine einzelne URL ist also nichts zu klicken.

2. 2

   Kodierprofil wählen

   Komponente passt zu einem Query-Wert oder Pfadsegment. Striktes RFC 3986 kodiert zusätzlich ! ' ( ) * und ist das, was OAuth 1.0 und die AWS-Anfragesignatur verlangen. Voll-URL behält : / ? & = bei, damit ein ganzer Link navigierbar bleibt. Formular entspricht dem, was ein Browser beim Absenden eines Formulars sendet.

3. 3

   Zeichensatz einstellen, wenn die Daten nicht UTF-8 sind

   Lassen Sie UTF-8 stehen, sofern Sie nicht mit einem Altsystem arbeiten. Ein von einer älteren Plattform erzeugter Query-String kann Windows-1252- oder Shift_JIS-Bytes enthalten, und der richtige Zeichensatz macht aus %E9 das gemeinte Zeichen statt einen Fehler.

4. 4

   Ergebnis kopieren, herunterladen oder zurückschicken

   Kopieren legt das gesamte Ergebnis in die Zwischenablage, Herunterladen speichert es als Textdatei, und Ausgabe als Eingabe verwenden schiebt das Ergebnis in das Eingabefeld und dreht die Richtung um, damit Sie den Rundlauf prüfen können.

Jede Einstellung unten verändert die erzeugten Bytes, und jede existiert, weil ein echter Arbeitsablauf sie braucht. Nichts davon ist gesperrt: Die Auswahl ist dieselbe, ob mit Konto oder ohne.

Kodieren und Dekodieren

Kodieren wandelt Zeichen, die eine URL nicht wörtlich tragen kann, in Prozentsequenzen um. Dekodieren macht das rückgängig. Die Richtung entscheidet außerdem, welche Zeichensätze angeboten werden, denn beide sind nicht symmetrisch: Ein Browser kann weit mehr historische Kodierungen lesen als schreiben.

Das Kodierprofil

Das Profil ist die Menge der Zeichen, die unangetastet bleiben. Das ist die folgenreichste Wahl auf dieser Seite, und die falsche erzeugt eine Ausgabe, die richtig aussieht und von genau einem Server abgelehnt wird. Der folgende Abschnitt vergleicht alle vier.

Der Zeichensatz

Lassen Sie UTF-8 stehen, sofern Sie es nicht besser wissen. Er entscheidet, wofür die Sequenzen stehen, und macht den Unterschied, ob %E9 ein e mit Akzent ist oder ein Fehler. Das ist unabhängig davon, wie eine abgelegte Datei gelesen wird: Eine Windows-1252-Datei kann berechtigterweise UTF-8-Sequenzen enthalten, dann sind beide Einstellungen gleichzeitig richtig.

Tolerantes Dekodieren

Standardmäßig an. Eine fehlerhafte Sequenz lässt den umgebenden Text unangetastet und wird mit ihrer genauen Position gemeldet, statt die ganze Zeichenkette scheitern zu lassen. Schalten Sie es ab, wenn Sie ein hartes Scheitern wollen, etwa beim Prüfen, ob eine Zeichenkette wohlgeformt ist, statt sie zu lesen.

Wiederholte Dekodierdurchläufe

Dekodiert bis zu fünfmal und hört auf, sobald ein Durchlauf nichts mehr ändert. Die gemeldete Zahl ist die tatsächliche Kodiertiefe, nicht die Einstellung: Eine nur einmal kodierte Zeichenkette meldet weiterhin einen Durchlauf, egal wie hoch Sie den Regler stellen.

Plus als Leerzeichen

Ein Pluszeichen bedeutet in Formulardaten ein Leerzeichen und sonst nirgends. Pro Profil angewendet: Im Voll-URL-Modus geschieht die Ersetzung erst nach dem ersten Fragezeichen, ein wörtliches Plus im Pfad überlebt also. In den Modi Komponente und Formular wird die ganze Zeichenkette als Query behandelt, denn das ist sie.

Historische %uXXXX-Sequenzen

Zeichenketten aus der alten JavaScript-Funktion escape() und aus mehreren älteren Microsoft-Plattformen verwenden %u gefolgt von vier Hexadezimalziffern für ein Nicht-ASCII-Zeichen. Der Standarddekodierer lehnt sie schlicht ab. Schalten Sie dies ein, um sie zu lesen.

Zeilenweise

Wandelt jede Zeile einzeln um und gibt ihr ihr eigenes Zeilenende zurück. Das ist die Einstellung für eine Linkliste: Die ganze Datei als eine Zeichenkette zu kodieren würde die Zeilenumbrüche selbst kodieren und eine einzige unbrauchbare Zeile ergeben.

Umgebende Leerzeichen entfernen

Standardmäßig aus, und das mit Absicht. Leerzeichen sind genau die Art Zeichen, für deren Erhalt die Prozentkodierung existiert; sie stillschweigend zu entfernen würde das Werkzeug untergraben. Schalten Sie es ein, wenn Sie eine URL aus einer E-Mail kopiert und dabei einen Zeilenumbruch mitgenommen haben.

Browser, Server und Caches behandeln bestimmte Zeichen als Struktur: Leerzeichen, Kaufmannsund, Rauten und Nicht-ASCII-Text müssen kodiert werden, wenn sie Daten und nicht Syntax sind. Ein eigenes Werkzeug zeigt Ihnen die exakte Zeichenkette, die ein HTTP-Client senden wird — bevor Sie den Code ausliefern, der sie baut.

Vorteile korrekter URL-Kodierung

• Sichere Übertragung — reservierte Zeichen in Nutzerinhalten zerbrechen die Parser nicht mehr, die Pfade, Querys und Fragmente trennen.
• Unicode-Unterstützung — UTF-8-Bytes werden als %-Sequenzen dargestellt, damit internationaler Text reine ASCII-Übertragungen übersteht.
• Berechenbare APIs — die Ausrichtung an RFC 3986 verringert Abweichungen zwischen Frontend, Mobil-Apps und Backend-Frameworks.
• Weniger 400er-Fehler — korrekt kodierte Parameter werden seltener von strengen Gateways oder Reverse Proxies abgelehnt.
• Einfachere Fehlersuche — vergleichen Sie eine von Hand gebaute Zeichenkette mit dem, was die Standardfunktionen erzeugen, bevor Sie einen Hotfix ausliefern.

Die Prozentkodierung schreibt jedes Byte, das in einer URL nicht wörtlich stehen darf, als %HH, wobei HH hexadezimal ist. Welche Zeichen wörtlich bleiben, hängt davon ab, ob Sie eine ganze URL oder eine einzelne Komponente schützen — und das ist das Einzige, was die vier folgenden Profile trennt.

Von Zeichen zu Bytes zu Sequenzen

• Zuerst werden Zeichen zu Bytes — der Text wird im gewählten Zeichensatz in Bytes umgewandelt. In UTF-8 sind ein e mit Akzent zwei Bytes und ein japanisches Zeichen drei.
• Jedes Byte wird geprüft — ein Byte aus der sicheren Menge des Profils wird wörtlich geschrieben; alles andere wird zu % gefolgt von zwei Hexadezimalziffern.
• Das Leerzeichen ist der Sonderfall — in der Formularkodierung wird ein Leerzeichen zum Pluszeichen statt zu %20 — die einzige Stelle, an der diese Ersetzung richtig ist.
• Das Dekodieren geht rückwärts — Sequenzen werden zu Byte-Läufen zusammengefasst und gemeinsam dekodiert, denn ein Zeichen besteht oft aus mehreren Sequenzen hintereinander.

Die vier Profile unterscheiden sich nur darin, welche Zeichen sie unangetastet lassen — doch dieser Unterschied entscheidet, ob eine Signatur gültig ist und ob ein Link noch funktioniert. Das hier behält jedes wörtlich bei, und dafür greifen Sie dazu.

Komponente

Lässt Buchstaben, Ziffern und - _ . ! ~ * ' ( ) unangetastet. Entspricht der Standardfunktion encodeURIComponent und ist die richtige Voreinstellung für einen einzelnen Query-Wert, ein Formularfeld oder ein Pfadsegment. Nehmen Sie es, sofern keiner der drei folgenden Fälle zutrifft.

Striktes RFC 3986

Lässt nur Buchstaben, Ziffern und - . _ ~ unangetastet — die unreservierte Menge der Spezifikation, mehr nicht. Die fünf zusätzlichen Zeichen, die der Komponentenmodus behält (! ' ( ) *), werden hier kodiert. Greifen Sie dazu, wenn Sie einen OAuth-1.0-Signaturbasisstring oder eine kanonische Anfrage für AWS Signature Version 4 bauen; beide verlangen die strikte Menge. Eine Abweichung scheitert nur dann, wenn eines dieser fünf Zeichen in den Daten vorkommt — das macht sie zu einem der schwerer reproduzierbaren Fehler.

Voll-URL

Behält die Trennzeichen, die einer URL ihre Form geben — : / ? # & = + $ , ; @ — damit ein vollständiger Link nach der Kodierung navigierbar bleibt. Nehmen Sie es, wenn Sie eine ganze URL bereinigen statt eine zusammenzusetzen. Das Dekodieren ist in diesem Modus bewusst unsymmetrisch: %2F bleibt %2F, denn es in einen Schrägstrich zu verwandeln würde ein Pfadsegment hinzufügen, das nicht da war. Das Kästchen Auch Trennzeichen dekodieren hebt das auf, wenn Sie Klartext wollen.

Formular

Behält nur Buchstaben, Ziffern und * - . _ und schreibt ein Leerzeichen als Pluszeichen. Das ist es, was ein Browser beim Absenden eines Formulars tatsächlich auf die Leitung legt, und was URLSearchParams erzeugt. Es ist wissenswert, dass dies nicht die einzige umlaufende Definition ist: Pythons quote_plus kodiert das Sternchen und behält die Tilde — bei beidem das Gegenteil. Dieses Werkzeug folgt dem heutigen Webstandard, denn dagegen wurde der empfangende Server gebaut.

Eine prozentkodierte Zeichenkette ist eine Folge von Bytes, und welche Zeichen diese Bytes bedeuten, hängt vollständig von der Kodierung des Systems ab. Hier geben Werkzeuge auf, die nur UTF-8 sprechen — und hier steckt ein großer Teil der echten Arbeit.

Alte Daten lesen

Zum Dekodieren stehen siebenunddreißig Zeichensätze bereit: die Einzelbyte-Familien — Windows-1250 bis 1258, die ISO-8859-Reihe, KOI8-R und KOI8-U, die Mac-Sätze und IBM866 — sowie die ostasiatischen Mehrbyte-Sätze Shift_JIS, EUC-JP, ISO-2022-JP, EUC-KR, GBK, GB18030 und Big5. Fast alles, was eine PHP-, ASP- oder Java-Plattform vor etwa 2010 erzeugt hat, braucht einen davon.

Alte Daten schreiben — und was nicht geht

Zum Kodieren stehen achtundzwanzig Sätze bereit: UTF-8 und jeder Einzelbyte-Satz von oben. Die ostasiatischen Mehrbyte-Sätze sind reine Dekodiersätze, und diese Grenze wird hier benannt statt stillschweigend übergangen. Ein Zeichen, das der Zielsatz nicht darstellen kann, wird als numerische Referenz wie € geschrieben, statt verworfen oder durch ein Fragezeichen ersetzt zu werden — genau das tut ein Browser, der ein Formular auf einer Seite mit historischer Kodierung absendet, der empfangende Server kann es also bereits lesen.

Die meisten Werkzeuge dieser Kategorie, und die Standardfunktion decodeURIComponent, auf der sie aufbauen, behandeln das Dekodieren als Alles-oder-nichts. Ein einziges falsches Zeichen, und Sie bekommen eine Fehlermeldung statt Ihrer Daten. Das sind die vier Dinge, die tatsächlich schiefgehen, und wie dieses Werkzeug jedes davon behandelt.

• Eine abgeschnittene Sequenz — ein % mit weniger als zwei Hexadezimalziffern dahinter, meist weil die URL von einer Logzeile oder einem Textfeld abgeschnitten wurde. Tolerantes Dekodieren lässt sie stehen und meldet ihre Position.
• Bytes, die im Zeichensatz ungültig sind — %E9 allein ist kein gültiges UTF-8. Entweder liegen die Daten in einer historischen Kodierung vor — dann wählen Sie sie aus der Liste — oder die Zeichenkette ist wirklich beschädigt, und der tolerante Modus markiert die Stelle.
• Doppelte Kodierung — %2520, wo %20 gemeint war. Erhöhen Sie die wiederholten Dekodierdurchläufe; die Parameteraufschlüsselung zeigt, welche betroffen sind.
• Historisches %uXXXX — gar keine Prozentkodierung, sondern die Ausgabe der alten Funktion escape(). Schalten Sie historische Sequenzen ein, um es zu lesen.

Fügen Sie etwas ein, das wie eine URL aussieht, und unter dem Ergebnis erscheint eine Aufschlüsselung: Schema, Host, Port, Pfad und Fragment, danach eine Tabelle jedes Query-Parameters mit einzeln dekodiertem Schlüssel und Wert.

Das gibt es, weil das Dekodieren einer ganzen Tracking-URL am Stück eine unlesbare Zeile ergibt, während die eigentliche Frage war, was in einem bestimmten Parameter stand. Die Tabelle dekodiert jeden Schlüssel und Wert für sich und markiert diejenigen, die doppelt kodiert aussehen oder eine fehlerhafte Sequenz enthalten — in der Praxis ist das meist ein einziger Parameter, häufig ein Weiterleitungsziel, und ihn in einem Link mit vierzehn Parametern mit bloßem Auge zu finden ist der Teil, der Zeit kostet. Die Aufschlüsselung meldet genau die Zeichen, die Sie eingefügt haben: Sie schreibt den Host nicht klein, entfernt keinen Standardport und löst keine ..-Segmente auf — denn eine Diagnose, die ihre Eingabe repariert, hat die Beweise vernichtet.

Kleine Details — etwa Pluszeichen in Formularübermittlungen gegenüber echter Prozentkodierung — bringen Teams zu Fall, wenn Frameworks sich uneinig sind.

Kurzreferenz

• Das Leerzeichen ist %20 in einem Query-String, aber ein Pluszeichen in einem application/x-www-form-urlencoded-Rumpf.
• Nur unreservierte Zeichen (Buchstaben, Ziffern, - . _ ~) dürfen in der strikten Kodierung unkodiert erscheinen.
• Doppelte Kodierung erzeugt längere URLs und kann Server verwirren; %2520 ist die Signatur, nach der Sie suchen.
• Der Standarddekodierer scheitert an einem % mit unvollständigem Hexadezimalwert und liefert dann überhaupt nichts.
• Ein japanisches Zeichen wird zu neun Ausgabezeichen; eine kodierte Zeichenkette kann also um ein Vielfaches länger sein als der Text.
• Internationalisierte Domainnamen nutzen im DNS Punycode; die URL-Kodierung betrifft Pfad und Query, nicht die Umwandlung des Hostnamens.

Bewährte Vorgehensweisen

Kodieren Sie an der Grenze, an der nicht vertrauenswürdiger Text Teil einer URL wird, und dekodieren Sie einmal, wenn Sie ihn wieder als Daten behandeln.

• Kodieren Sie jeden Query-Wert einzeln, statt die ganze URL zweimal zu kodieren.
• Protokollieren Sie rohe Nutzereingaben getrennt von der kodierten Zeichenkette, wenn Sie Analytics oder Weiterleitungen debuggen.
• Bevorzugen Sie HTTPS-Links, wenn Sie kodierte URLs mit sensiblen Tokens teilen.
• Prüfen Sie dekodierte Ausgaben, bevor Sie sie in HTML einsetzen, um Probleme durch bösartige Links zu vermeiden.
• Testen Sie beide Richtungen, wenn Ihr Produkt Deep Links aus E-Mail oder SMS unterstützt.

Ideale Anwendungsfälle

• Webentwicklung — bauen Sie Suchfilter, UTM-Parameter und OAuth-Weiterleitungs-URIs mit Sicherheit.
• API-Integration — treffen Sie das SDK-Verhalten, wenn die Dokumentation die Prozentkodierung nach RFC 3986 nennt.
• QA und Support — reproduzieren Sie Kunden-URLs, ohne zu raten, welche Zeichen kodiert wurden.
• Dokumentation — zeigen Sie exakte Vorher-Nachher-Beispiele für Partnerintegrationen.
• Migrationsskripte — vergleichen Sie historische Kodierregeln mit dem, was moderne Clients erzeugen.

Eine einzelne URL wird getippt oder eingefügt; eine Liste davon kommt als Datei. Beide Wege laufen durch denselben Motor und unterliegen denselben Grenzen.

Welche Dateien geöffnet werden

Reiner Text und textförmige Formate: .txt, .log, .csv, .tsv, .md, .json, .xml, .html, .yaml, .ini, .env, .sql, .har, die üblichen Quellcode-Endungen und .url-Internetverknüpfungen. Alles andere wird namentlich abgelehnt, mit einem Link zum passenden Werkzeug: Ein PDF wird an den Textextraktor verwiesen statt stillschweigend ignoriert. Die Dateiauswahl bietet nur Formate an, die funktionieren, Sie können also keine Datei wählen und dann zusehen, wie nichts geschieht.

Welche Textkodierungen gelesen werden

UTF-8, UTF-8 mit Bytereihenfolge-Markierung und UTF-16 in beiden Reihenfolgen, wenn die Datei eine identifizierende Markierung trägt. Eine UTF-16-Datei ohne Markierung wird abgelehnt statt geraten, denn die Bytereihenfolge ist Münzwurf und ein Fehlgriff erzeugt überzeugenden Unsinn statt eines Fehlers. Womit die Datei ankam, damit geht sie auch wieder: Eine Windows-CSV kommt nicht als etwas zurück, das Excel falsch öffnet.

Was die kostenlose Version enthält

Jedes Kodierprofil, jeden vom Gerät unterstützten Zeichensatz, tolerantes Dekodieren, wiederholtes Dekodieren, historische Sequenzen, zeilenweise Umwandlung und die Parameteraufschlüsselung — dazu eine Datei auf einmal bis 10 MB und unbegrenztes Einfügen innerhalb derselben Größe. Keine Umwandlungsfunktion wird zurückgehalten.

Was Pro hinzufügt

Eine Warteschlange von bis zu zwanzig Dateien, einen einzigen ZIP-Download für den gesamten Stapel und den Wegfall der 10-MB-Obergrenze — Pro wird von dem begrenzt, was Ihr Gerät fassen kann, nicht von einer größeren festen Zahl. Die kostenlose 10-MB-Grenze liegt dort, wo sie liegt, weil die Prozentkodierung die seltene Textoperation ist, deren Ausgabe größer ist als ihre Eingabe: Jedes Byte kann zu drei Zeichen werden, aus 10 MB Eingabe können also 31 Millionen Zeichen Ausgabe werden.

Drei Dinge, die dieses Werkzeug bewusst nicht tut. Ostasiatische Mehrbyte-Zeichensätze stehen zum Dekodieren bereit, nicht zum Kodieren, denn ihre Tabellen lassen sich aus dem, was ein Browser bietet, nicht rückwärts ableiten. Das wiederholte Dekodieren hört nach fünf Durchläufen auf, weit jenseits jeder in der Praxis beobachteten Tiefe. Und die Parameteraufschlüsselung meldet die URL genau so, wie sie eingegeben wurde, statt sie zu normalisieren — sie zeigt Ihnen also bereitwillig eine fehlerhafte URL, was genau der Sinn der Sache ist.

Auf dem Referenzgerät gemessen: Eine URL mit 100.000 Zeichen wird in unter einer Millisekunde umgewandelt, ein Dokument an der kostenlosen 10-MB-Grenze in deutlich unter einer Sekunde. Bis etwa einer Viertelmillion Zeichen geschieht die Umwandlung während der Eingabe; darüber wandert sie vom Oberflächen-Thread weg, damit die Seite nie stockt.

• Base64-Encoder/Decoder
• Base64-Encoder
• Base64-Decoder
• Alle Konverter
• Hash-Generator
• UUID-Generator
• QR-Code-Generator
• JSON-Formatierer
• JSON-Escape
• Text-Splitter
• Text-Trimmer
• CSV-Escape-Korrektur
• Alle Textwerkzeuge
• Alle JSON-Werkzeuge