URL Parser / Inspektor
Fügen Sie eine oder mehrere vollständige URLs (eine pro Zeile) ein, um jeden in sein Protokoll, Host, Pfad, Abfragestring und Fragment zu brechen, mit jedem Abfrageparameter decodiert.
Fügen Sie eine oder mehrere vollständige URLs (eine pro Zeile) ein, um jeden in sein Protokoll, Host, Pfad, Abfragestring und Fragment zu brechen, mit jedem Abfrageparameter decodiert.
Eine URL kann nur sicher Buchstaben, Ziffern und einen kleinen Satz von Symbolen enthalten (- _ . ~). Alles andere, einschließlich Leerzeichen, Pünctuation und nicht-englische Zeichen, muss mit einer prozentualen Kodierung dargestellt werden, bevor sie innerhalb einer URL reisen kann.
Die Percent-Kodierung ersetzt ein Zeichen mit einem Prozentzeichen, gefolgt von seinem zweistelligen hexadezimalen Byte-Wert, mit UTF-8 für alles außerhalb des ASCII. Ein Raum wird zu %20, ein Ampersand wird zu %26, und ein akzentuierter oder nicht lateinischer Charakter kann mehrere %XX Sequenzen in Folge werden, da UTF-8 ihn als mehr als ein Byte darstellt.
Charaktere wie ? & = # und / haben eine besondere Bedeutung in einer URL-Struktur: Sie markieren die Abfragekette, separate Parameter oder stellen das Fragment ein. Wenn Ihre Daten eine dieser Zeichen als Wert enthalten müssen, anstatt als Struktur, kodieren Sie sie zuerst, oder der Browser oder Server kann falsch lesen, wo ein Teil der URL endet und der nächste beginnt.
Das Dekodieren rückt den Vorgang um: es liest jede %XX Sequenz zurück in das Zeichen (oder Byte), das es darstellt, was genau das oben stehende Werkzeug tut.
| Charakter | Kodifiziert | Wo es verwendet wird |
|---|---|---|
| Raum | %20 | Worttrenner innerhalb eines Wertes |
| ! | %21 | |
| " | %22 | |
| # | %23 | Startet das Fragment |
| % | %25 | Startet eine prozent-codierte Sequenz |
| & | %26 | Trennt Abfrageparameter |
| ' | %27 | |
| ( | %28 | |
| ) | %29 | |
| + | %2B | Oft als Raum innerhalb einer Abfrage-String lesen |
| , | %2C | |
| / | %2F | Trennt Pfadsegmente |
| : | %3A | Folgen des Programms, z.B. https: |
| ; | %3B | |
| = | %3D | Der Wert eines Abfrageparameters zuweist |
| ? | %3F | Startet die Abfrage-String |
| @ | %40 | |
| [ | %5B | |
| ] | %5D |
Eine Schülerin kopiert eine Webadresse aus einem Onlineformular und sieht dort Text wie science%20project%20notes. Ein Entwickler am Anfang seiner Laufbahn sieht sich eine API-Anfrage an und stellt fest, dass ein Und-Zeichen innerhalb eines Suchwerts als %26 erscheint. Die Adresse funktioniert, aber sie ist schwer zu lesen und schwer zu untersuchen.
Ein Werkzeug zur URL-Decodierung wandelt prozentcodierte Sequenzen zurück in die Zeichen, für die sie stehen. Aus %20 wird üblicherweise ein Leerzeichen, aus %26 ein Und-Zeichen.
Decodieren hilft dabei, Links zu verstehen, Abfrageparameter zu prüfen, Webcodierung zu lernen und fehlerhafte Anfragen einzugrenzen. Dabei ist Sorgfalt nötig, denn reservierte Zeichen können die Struktur einer URL verändern, sobald sie decodiert sind.
Das Werkzeug entscheidet nicht, ob ein Ziel sicher, richtig oder erlaubt ist. Es ändert nur die Darstellung codierter Zeichen. Host, Pfad, Parameter und decodierte Werte müssen Lernende und Entwickler weiterhin selbst prüfen.
URLs nutzen bestimmte Zeichen, um ihre Bestandteile voneinander zu trennen. Ein Fragezeichen kann eine Abfragezeichenfolge einleiten, ein Und-Zeichen kann Parameter trennen, und ein Rautezeichen kann ein Fragment kennzeichnen.
Soll eines dieser Zeichen als Daten und nicht als strukturelles Trennzeichen erscheinen, lässt es sich prozentcodieren. Auf ein Prozentzeichen folgen dann zwei Hexadezimalziffern, die einen Bytewert darstellen.
| Codierter Wert | Decodiertes Zeichen | Übliche Bedeutung |
|---|---|---|
%20 |
Leerzeichen | Trennt Wörter innerhalb eines Werts |
%21 |
! |
Ausrufezeichen |
%23 |
# |
Rautezeichen oder Fragmentmarke |
%26 |
& |
Und-Zeichen oder Parametertrenner |
%2B |
+ |
Pluszeichen |
%2F |
/ |
Schrägstrich oder Pfadtrenner |
%3A |
: |
Doppelpunkt |
%3D |
= |
Gleichheitszeichen oder Parametertrenner |
%3F |
? |
Fragezeichen oder Abfragemarke |
Bei den Hexadezimalbuchstaben in Prozentsequenzen spielt die Groß- und Kleinschreibung keine Rolle: %2F und %2f stehen für dasselbe Byte.
Nehmen wir dieses Beispiel:
https://example.edu/search?q=water%20cycle&level=grade%206#results
Seine wichtigsten Bestandteile sind:
httpsexample.edu/searchq=water%20cycle&level=grade%206resultsDie Abfragewerte werden zu „water cycle“ und „grade 6“ decodiert. Das strukturelle Und-Zeichen zwischen den Parametern darf man nicht mit einem Und-Zeichen verwechseln, das innerhalb eines Werts codiert ist.
Entwickler handeln sich oft Probleme ein, weil sie eine ganze URL decodieren, obwohl nur ein Bestandteil gemeint war. Reservierte Zeichen können je nach Position eine andere Rolle haben.
Angenommen, eine Abfrage enthält Folgendes:
?topic=research%26writing
Der codierte Wert steht für:
research&writing
Das Und-Zeichen gehört hier zum Wert des Themas. Wird die vollständige Abfrage decodiert und anschließend falsch ausgewertet, kann das Und-Zeichen für ein Trennzeichen gehalten werden, das einen weiteren Parameter einleitet.
Eine verlässliche Anwendung zerlegt die URL anhand ihrer Struktur und decodiert jeden Bestandteil mit einer passenden URL-Schnittstelle statt mit willkürlichen Textersetzungen.
Die Klasse sieht sich das an:
https://example.edu/library?topic=space%20science
Sie bestimmt Host, Pfad, Parameternamen und codierten Wert.
Aus dem Wert space%20science wird space science. Die Lernenden erklären, warum man ein Leerzeichen in einer geteilten URL normalerweise nicht einfach so schreibt.
Die Lehrkraft gibt Folgendes vor:
?title=Design%20%26%20Technology
Der decodierte Titel lautet Design & Technology. Die Lernenden erkennen, dass das codierte Und-Zeichen zum Titel gehört und keine Parameter trennt.
Mit dem Werkzeug zur URL-Codierung bereiten die Lernenden einen neuen Wert vor, decodieren ihn anschließend und vergleichen das Ergebnis.
Eine der Sequenzen enthält eine unvollständige Prozentmaskierung wie %2. Die Lernenden begründen, warum nach dem Prozentzeichen zwei Hexadezimalziffern erwartet werden.
Ein Schüler kopiert einen Suchlink aus dem Bibliothekskatalog, in dem mehrere Wörter codiert sind. Die sichtbare URL lässt sich kaum deuten.
Er decodiert die Abfragewerte und sieht, welche Suchbegriffe und Filter enthalten waren. Vor dem Öffnen prüft er den Host.
So versteht er, wie eine Website Suchinformationen von Seite zu Seite weiterreicht.
Ein Entwickler am Anfang seiner Laufbahn sendet eine Anfrage mit einem Kurstitel, der ein Und-Zeichen enthält. Der Server empfängt den Titel als zwei getrennte Parameter.
Beim Blick in die rohe Anfrage zeigt sich, dass das Und-Zeichen nicht als Daten codiert wurde. Der Wert wird mit einer gängigen URL-Schnittstelle aufbereitet und erneut getestet.
Der Decoder hilft, die Anfrage zu verstehen; die dauerhafte Lösung liegt jedoch in strukturierter URL-Verarbeitung statt in manuellem Ersetzen.
Eine Lehrkraft erhält einen Link zu einem Unterrichtsdokument, doch das Ziel meldet, die Datei sei nicht auffindbar.
Die URL wird geprüft und decodiert. Ein Dateiname enthält einen Schrägstrich, der womöglich als Pfadtrenner gewertet wurde, oder ein Leerzeichen wurde falsch übernommen.
Statt blind an einer fremden, privaten Adresse herumzubasteln, lässt sich die Lehrkraft vom Eigentümer des Dokuments einen neuen Freigabelink geben.
Die Klasse baut ein einfaches Suchformular und schaut sich die URL an, nachdem ein Text mit Leerzeichen und Satzzeichen abgeschickt wurde.
Die Lernenden decodieren die Parameterwerte und vergleichen sie mit der ursprünglichen Eingabe. Anschließend wird besprochen, warum Browser Werte codieren, bevor sie in einer URL landen.
Echte Passwörter, Schülerdaten oder private Antworten kommen in der Übung nicht vor.
Der Link in einem Schulnewsletter enthält mehrere Tracking-Parameter. Eine Lehrkraft möchte vor dem Weitergeben wissen, welche Informationen darin stecken.
Die URL wird in Parameter zerlegt und deren Werte werden decodiert. Überflüssige Tracking-Werte lassen sich nur dann entfernen, wenn das Ziel dadurch nicht kaputtgeht.
Der fertige Link wird getestet, statt nach dem Umbauen einfach anzunehmen, dass er funktioniert.
Ein Informatikkurs probiert eine kurze nichtenglische Wendung in einer URL aus. Das codierte Ergebnis enthält mehrere Prozentsequenzen, weil UTF-8-Zeichen mehrere Bytes belegen können.
Die Lernenden decodieren die vollständige Sequenz und vergleichen sie mit der ursprünglichen Wendung. Fehlt ein prozentcodiertes Byte, entsteht womöglich ein Ersatzzeichen oder ungültiger Text.
Die Übung zeigt, dass einem sichtbaren Zeichen nicht immer genau ein codiertes Byte entspricht.
Ein Entwickler erwartet ein Leerzeichen, sieht aber %2520. Die Sequenz %25 steht für ein Prozentzeichen; ein Decodierdurchgang ergibt also %20, ein weiterer möglicherweise ein Leerzeichen.
Er verfolgt zurück, wo der Wert zweimal codiert wurde. Der Datenfluss wird korrigiert, statt jede Eingabe immer wieder zu decodieren.
Ein Link enthält in einem Parameter wie redirect oder next eine weitere codierte URL.
Der Wert wird als reiner Text decodiert, und vor dem Öffnen wird der tatsächliche Zielhost geprüft. Eine codierte Adresse verdient kein Vertrauen, nur weil ihr Endziel schwer zu lesen ist.
| Eingabe | Wahrscheinliche Codierung | Passendes Werkzeug | Decodiertes Beispiel |
|---|---|---|---|
lesson%20notes |
URL-Prozentcodierung | URL-Decodierung | lesson notes |
<p> |
HTML-Entitäten | HTML-Decodierung | <p> |
SGVsbG8= |
Base64 | Base64-Decodierung | Hello |
u003F |
Unicode-Maskierung | JSON- oder sprachspezifischer Parser | ? |
Für Entitätsreferenzen eignet sich das Werkzeug zur HTML-Decodierung, und das Werkzeug zur Base64-Decodierung nur dann, wenn bekannt ist, dass die Daten dieses Format nutzen.
Leerzeichen werden üblicherweise als %20 dargestellt. In der formulartypischen Abfragecodierung kann auch ein Pluszeichen als Leerzeichen gelesen werden.
Daraus ergibt sich ein wichtiger Unterschied:
class%20notes wird üblicherweise zu class notes decodiert.class+notes kann im Kontext einer Formularabfrage zu class notes werden.%2B codiert werden.Nutzen Sie das Decodierverfahren, das für den jeweiligen Bestandteil und das jeweilige Format gedacht ist. Ein Pfaddecoder und ein Decoder für Formularabfragen behandeln Pluszeichen nicht zwingend gleich.
Die Prozentcodierung arbeitet auf Byteebene. Ein Zeichen außerhalb des einfachen ASCII-Bereichs kann durch mehrere codierte Bytes dargestellt werden.
Ein Buchstabe mit Akzent oder ein arabisches Zeichen erscheint zum Beispiel als Folge mehrerer Prozentmaskierungen. Alle nötigen Bytes müssen in der richtigen Reihenfolge erhalten bleiben und mit der passenden Zeichencodierung gelesen werden.
Enthält die Ausgabe Ersatzsymbole, prüfen Sie, ob:
Reservierte Zeichen können die Struktur nach dem Decodieren verändern. Zerlegen Sie die URL in ihre Bestandteile und decodieren Sie nur den gewünschten Wert.
Wiederholtes Decodieren kann zuvor harmlose Daten in wirksame Trennzeichen oder unerwartete Pfade verwandeln. Klären Sie, warum mehrere Codierschichten vorliegen.
%20 durch Leerzeichen zu ersetzen deckt weder alle codierten Zeichen noch UTF-8-Sequenzen, fehlerhafte Eingaben oder die Regeln für Pluszeichen ab. Verwenden Sie im Code einen strukturierten URL-Parser oder eine gängige Schnittstelle.
Decodieren Sie es zuerst als Text. Prüfen Sie Schema, Hostname, Pfad und Parameter, bevor Sie entscheiden, ob Sie die Adresse aufrufen.
%26 und & können in verschiedenen Zusammenhängen beide für ein Und-Zeichen stehen. Wählen Sie den Decoder nach der tatsächlichen Darstellung.
Auf ein Prozentzeichen sollten zwei Hexadezimalziffern folgen. Unvollständige oder ungültige Sequenzen deuten auf beschädigte Eingaben hin.
URLs tauchen im Browserverlauf, in Protokollen, in Analytics-Daten, auf Screenshots und in geteilten Nachrichten auf. Sensible Zugangsdaten gehören nicht in eine Abfragezeichenfolge.
Decodierte Werte können Zeichen mit besonderer Bedeutung enthalten. Ein decodierter Schrägstrich kann einen Pfad beeinflussen, ein Und-Zeichen kann Parameter verändern, und spitze Klammern können zu Markup werden, wenn sie falsch in eine Webseite eingesetzt werden.
Anwendungen sollten:
Decodieren ist keine Bereinigung. Es macht die dargestellten Zeichen sichtbar, entscheidet aber nicht, ob sie für HTML, Dateipfade, Datenbankabfragen oder Weiterleitungen unbedenklich sind.
Eine URL kann Suchbegriffe, Dokumentkennungen, E-Mail-Adressen, Kurscodes, Dateinamen, Tracking-Daten und weitere Informationen enthalten. Decodieren macht all das leichter lesbar, entfernt es aber nicht.
Fügen Sie keine privaten Schullinks, Rücksetz-Token, signierten URLs, Adressen zu Schülerakten oder Anmeldedaten in ein externes Werkzeug ein. Ersetzen Sie sensible Werte im Unterricht und bei Vorführungen durch erfundene Beispiele.
Bevor Sie einen Screenshot einer decodierten URL teilen, entfernen Sie Kontonamen, interne Hosts, Token und Dokumentkennungen.
Wer neu in der Entwicklung ist, sollte strukturierte URL-Schnittstellen bevorzugen. In JavaScript lässt sich ein Abfragewert so auslesen:
const url = new URL(
"https://example.edu/search?q=water%20cycle"
);
const query = url.searchParams.get("q");
console.log(query);
// water cycle
Dieser Weg zerlegt die URL und liefert den decodierten Parameterwert zurück. Er ist in der Regel sicherer und klarer, als die vollständige Zeichenfolge von Hand an jedem Fragezeichen, Und-Zeichen und Gleichheitszeichen aufzutrennen.
Mit dem Werkzeug zur URL-Codierung bereiten Sie Text als URL-Bestandteil auf und decodieren ihn anschließend, um ein Unterrichtsbeispiel zu überprüfen.
Enthält die Eingabe Entitäten wie &lt; oder &quot;, nutzen Sie das Werkzeug zur HTML-Decodierung. Für bekannten Base64-Text greifen Sie zum Werkzeug zur Base64-Decodierung.
Der passende Decoder erspart unnötige Umwandlungen und macht die Fehlersuche verlässlicher.
URL-Decodierung verwandelt prozentcodierte Sequenzen in lesbare Zeichen. Sie hilft Lernenden, Webadressen zu verstehen, und Entwicklern, Abfragewerte, API-Anfragen, mehrsprachigen Text, Weiterleitungen und Probleme mit doppelter Codierung zu untersuchen.
Am sichersten ist es, den URL-Bestandteil zu bestimmen, nur das Nötige zu decodieren und die ursprüngliche Eingabe aufzubewahren. Behandeln Sie das Ergebnis als Daten, die weiterhin geprüft werden müssen.
Ein lesbarer decodierter Link lässt sich leichter untersuchen, ist deshalb aber weder automatisch sicher noch richtig. Prüfen Sie Struktur, Ziel, Parameter, Datenschutz und die vorgesehene Zeichencodierung, bevor Sie ihn verwenden.