URL kodieren und dekodieren

URL-Kodierung und -Dekodierung wendet RFC 3986-Prozentkodierung auf Text an und wandelt „%HH“-Sequenzen wieder in Zeichen um. Der Komponentenmodus kodiert reservierte Zeichen wie „/“, „?“ und „&“, sodass sie sicher in einem einzelnen Abfrageparameter Platz finden. Der Full-URI-Modus behält strukturelle Trennzeichen bei, sodass eine vollständige Adresse ein verwendbarer Link bleibt. Die Leerzeichenbehandlung bietet sowohl „%20“ als auch das Formularcodierungs-Pluszeichen.

Die gesamte Kodierung und Dekodierung läuft in Ihrem Browser. Nichts, was Sie einfügen, wird an einen Server gesendet.

Kodieren Sie Text zur sicheren Verwendung in einer URL

Bei der Prozentkodierung werden unsichere oder reservierte Bytes durch ein Prozentzeichen gefolgt von zwei hexadezimalen Ziffern ersetzt. Die Ziffern sind der Bytewert, normalerweise aus UTF-8. Geben Sie eine Zeichenfolge ein, wählen Sie den Komponenten- oder Voll-URI-Modus und kopieren Sie das codierte Ergebnis in eine Abfragezeichenfolge, ein Pfadsegment oder ein Umleitungsziel.

Zeichen, die sich bereits im nicht reservierten Satz befinden, bleiben unverändert bestehen. Alles andere wird im Komponentenmodus zu „%HH“-Sequenzen. Die Kodierung ist umkehrbar, wenn beim Dekodieren dieselben Regeln verwendet werden. Das Mischen von Formularcodierungs-Pluszeichen mit dem Pfadstil „%20“ ist die übliche Ursache für fehlerhafte Rundläufe.

Dekodieren Sie eine prozentcodierte Zeichenfolge

Die Dekodierung findet jedes „%“, gefolgt von zwei Hexadezimalziffern, wandelt dieses Paar in ein Byte um und erstellt den Originaltext mit der ausgewählten Zeichenkodierung neu. Ein einzelnes „%“ oder ein „%“ mit Nicht-Hex-Ziffern ist ein Fehler. Pluszeichen können optional als Leerzeichen behandelt werden, wenn die Eingabe aus „application/x-www-form-urlencoded“-Körpern stammt.

Eine verschachtelte Kodierung erscheint, wenn ein Wert doppelt kodiert wurde. Bei einmaliger Dekodierung bleiben möglicherweise immer noch „%25“-Sequenzen zurück, die einen wörtlichen Prozentsatz darstellen. Nur dann erneut dekodieren, wenn diese zweite Ebene beabsichtigt war; Durch die blinde Doppeldekodierung werden Daten beschädigt, die ein echtes „%“-Zeichen enthielten.

Verstehen Sie reservierte und nicht reservierte Zeichen

RFC 3986 teilt ASCII in nicht reservierte Zeichen, die niemals in einem URI kodiert werden müssen, und reservierte Zeichen mit struktureller Bedeutung wie Trennzeichen auf. Nicht reservierte Buchstaben, Ziffern und „-_.~“ bleiben wörtlich. Reservierte Zeichen wie „/“, „?“ und „&“ müssen prozentual codiert werden, wenn sie als Daten und nicht als Syntax, die die URL umrahmt, erscheinen.

Nicht reserviert: A bis Z, a bis z, 0 bis 9, Bindestrich -, Unterstrich _, Punkt ., Tilde ~

Reserviert (gen-delims): `: / ?

Reserviert (Unterstriche): ! $ & ' ( ) * + , ; =

Nicht reservierte Zeichen bleiben wörtlich. Reservierte Zeichen müssen codiert werden, wenn sie als Daten und nicht als Trennzeichen angezeigt werden. Ein Fragezeichen innerhalb eines Parameterwerts sind Daten; Ein Fragezeichen, mit dem die Abfragezeichenfolge beginnt, ist die Struktur. Durch die Modusauswahl weiß der Rechner, welche Rolle jeder Charakter spielt.

Kodieren Sie eine ganze URL statt eines einzelnen Parameters

Die vollständige URI-Kodierung, ähnlich wie JavaScript „encodeURI“, lässt Strukturzeichen in Ruhe, sodass „https://“ und Pfadschrägstriche erhalten bleiben. Die Komponentenkodierung, ähnlich wie „encodeURIComponent“, kodiert diese Zeichen, sodass ein Wert innerhalb eines Parameters stehen kann, ohne die umgebende URL zu zerstören. Wenn Sie den falschen Modus wählen, wird entweder ein Link zerstört oder es bleiben Trennzeichen zurück, die die Abfrage falsch aufteilen.

Input	Full-URI style	Component style
https://example.com/a b	https://example.com/a%20b	https%3A%2F%2Fexample.com%2Fa%20b
red&blue	red&blue	red%26blue
a=b	a=b	a%3Db

Durch die Codierung einer gesamten URL im Komponentenmodus wird diese als Link zerstört: Der Schema-Doppelpunkt und die Schrägstriche werden zu „%3A“ und „%2F“. Beim Codieren eines einzelnen Parameters im Voll-URI-Modus bleiben „&“ und „=“ intakt, wodurch die Abfrage falsch aufgeteilt wird. Wählen Sie den Modus, der dem Steckplatz entspricht, den die Saite belegen soll.

Codieren Sie einen Schrägstrich und ein Fragezeichen

Die Fixture-Zeichenfolge / and ? werden im Komponentenmodus zu %2F%20and%20%3F. Der Schrägstrich und das Fragezeichen sind reservierte Trennzeichen, die hier als Nutztext behandelt werden und daher jeweils maskiert sind. Leerzeichen werden zu „%20“, während die Buchstaben in and nicht reserviert sind und unverändert von links nach rechts durch die Zeichenfolge laufen.

Character	Reason	Encoded
/	reserved path delimiter	%2F
space	not unreserved	%20
a, n, d	unreserved letters	unchanged
?	reserved query delimiter	%3F

Gehen Sie die Zeichenfolge von links nach rechts durch: kodieren Sie „/“, kodieren Sie das Leerzeichen, übergeben Sie and, kodieren Sie das Leerzeichen, kodieren Sie „?“. Das Ergebnis %2F%20and%20%3F kann sicher in einen Abfrageparameter namens „q“ eingefügt werden. Die Verwendung des vollständigen URI-Modus für dieselbe Zeichenfolge würde die Literale / and ? belassen, was nur dann korrekt ist, wenn diese Zeichen als Struktur und nicht als Nutztext gedacht sind.

Verstehen Sie %20 im Vergleich zum Pluszeichen

Ein Leerzeichen wird in URI-Pfaden und in modernen Abfragezeichenfolgen, die RFC 3986 folgen, als „%20“ kodiert. HTML-Formulare, die als „application/x-www-form-urlencoded“ übermittelt werden, kodieren Leerzeichen in der Vergangenheit stattdessen als „+“. Beide Konventionen kommen im Produktionsverkehr vor und ihre identische Behandlung ist der häufigste Fehler bei der Leerzeichenkodierung beim Dekodieren gemischter Eingaben.

Context	Space encoding
Path segment	%20
RFC 3986 query	%20
Form body / legacy query	+

Ein literales Pluszeichen in Daten muss als „%2B“ codiert werden, sonst behandelt ein Formulardecoder es als Leerzeichen. Der Rechner kennzeichnet, welche Leerzeichenkonvention aktiv ist, sodass ein dekodiertes „+“ nicht mit einem Pluszeichen verwechselt wird, wenn der Formularmodus aktiviert ist, und ein „%20“ nicht abgelehnt wird, wenn der Pfadmodus aktiviert ist.

Zerlegen Sie eine URL in ihre Teile

Eine typische URL verfügt über ein Schema, einen Host, einen optionalen Port, einen Pfad, eine Abfragezeichenfolge und ein Fragment, und die Codierungsregeln unterscheiden sich teilweise. Strukturelle Trennzeichen wie „://“, „/“, „?“, „&“, „=“ und „#“ bleiben wörtlich, wenn sie die Adresse einrahmen.

Parameternamen, Parameterwerte und Pfadsegmente, die Daten übertragen, werden im Komponentenmodus einzeln codiert, bevor sie durch diese Trennzeichen verbunden werden.

https://example.com:443/search?q=a%20b&lang=en#top
└─┬─┘   └─────┬─────┘ └─┬──┘ └───────┬───────┘ └┬┘
scheme       host     path        query      fragment

Part	Role
Scheme	Protocol, such as https
Host	Domain or IP, with optional port
Path	Resource location, slash-separated
Query	Parameter list after ?, joined by &
Fragment	Client-side location after #, not sent to the server in the request URI the same way

Parameternamen und -werte einzeln im Komponentenmodus kodieren und dann mit den Literalen „&“ und „=“ verknüpfen. Pfadsegmente einzeln kodieren, wenn sie Leerzeichen oder reservierte Zeichen enthalten, wobei die Schrägstriche, die die Segmente trennen, literal bleiben.

Lesen Sie die Zeichenkodierungstabelle

In der folgenden Tabelle sind häufig verwendete reservierte und unsichere Zeichen mit ihren Prozentformen unter UTF-8-Byte-Kodierung aufgeführt. Ein Leerzeichen wird zu „%20“, ein kaufmännisches Und zu „%26“ und ein Hash zu „%23“. Nicht-ASCII-Zeichen werden auf mehrere „%HH“-Einheiten erweitert, da jedes UTF-8-Byte separat und nicht als einzelnes abstraktes Glyph codiert wird.

Char	Percent	Notes
space	%20	Or + in form encoding
!	%21
#	%23	Fragment delimiter
$	%24
&	%26	Query pair delimiter
'	%27
(	%28
)	%29
+	%2B	Literal plus
,	%2C
/	%2F	Path delimiter
:	%3A	Scheme / host separator
;	%3B
=	%3D	Parameter assignment
?	%3F	Query start
@	%40	Userinfo separator
[	%5B
]	%5D

Nicht-ASCII-Text wird zunächst als UTF-8-Byte ausgedrückt, dann wird jedes Byte prozentual codiert. Ein einzelnes Zeichen kann daher auf zwei oder drei „%HH“-Einheiten erweitert werden. Tiefgehende Einblicke in die Zeichenkodierung für Shift JIS und ähnliche Legacy-Sets live mit dem Base64-Tool; Diese Seite verlinkt diesen Katalog, anstatt ihn zu wiederholen.

Häufig gestellte Fragen

Zusammenfassung

URL-Kodierung und -Dekodierung kodiert und dekodiert Text gemäß den RFC 3986-Regeln prozentual, mit separaten Modi für vollständige URIs und einzelne Komponenten. Das Fixture / and ? wird im Komponentenmodus zu %2F%20and%20%3F. Leerzeichen verwenden „%20“ in URI-Kontexten und können „+“ in der Formularkodierung verwenden, was einer anderen Konvention entspricht.

Reservierte Zeichen behalten ihre Bedeutung nur dann, wenn sie als Struktur wörtlich belassen werden; kodieren Sie sie, wenn sie Nutzlast sind. Alle Arbeiten bleiben auf dem Gerät.