URLs können nur einen begrenzten Satz von ASCII-Zeichen enthalten, daher muss alles andere – Leerzeichen, Akzente, Emojis oder die reservierten Trennzeichen, die eine URL strukturieren – prozentual codiert werden. Dieses Tool kodiert und dekodiert diese Darstellung vollständig in Ihrem Browser. In diesem Leitfaden wird erklärt, wann man zur Komponenten- oder Voll-URL-Kodierung greifen sollte, warum ein Leerzeichen manchmal ein + und manchmal %20 ist und wie man einen Dekodierungsfehler liest.
Wann sollte encodeURIComponent im Vergleich zu encodeURI verwendet werden?
Die beiden Funktionen unterscheiden sich nur darin, welche Zeichen sie schützen. encodeURIComponent maskiert alles außer dem nicht reservierten Satz (Buchstaben, Ziffern und - _ . ! ~ * ' ( )), also reservierte Trennzeichen wie / ? & = # werden in %2F %3F %26 %3D %23 umgewandelt. Das ist genau das, was Sie für ein einzelnes Datenelement wünschen – einen Abfragewert, ein Pfadsegment –, weil es garantiert, dass der Wert nicht als Struktur missverstanden werden kann.
encodeURI ist für eine ganze URL gedacht. Die reservierten Zeichen, die eine URL begrenzen, bleiben unberührt, sodass https://x.com/a?b=c verwendbar bleibt. Der Nachteil: Es wird nicht einen Wert schützen, der selbst einen / oder & enthält. Faustregel: Codieren Sie jeden Wert zuerst im Komponentenmodus und stellen Sie dann die URL zusammen. Verwenden Sie den Voll-URL-Modus nur, wenn Sie eine fertige URL haben, die lediglich ein Leerzeichen oder einen Akzent enthält.
Reservierte Zeichen und die Verwirrung zwischen + und %20
RFC 3986 nennt dies die reservierten Zeichen: : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Innerhalb von Daten müssen sie maskiert werden; als Trennzeichen dürfen sie nicht sein. Die häufigste Fehlerquelle ist der Speicherplatz. Moderne Prozentkodierung schreibt ein Leerzeichen immer als %20. Aber das ältere application/x-www-form-urlencoded-Format – das, was ein Browser erzeugt, wenn er ein HTML-Formular sendet – kodiert ein Leerzeichen in der Abfragezeichenfolge als +. Also können ?q=a+b und ?q=a%20b beide „a b“ bedeuten. Wenn Sie eine Zeichenfolge im Formularstil dekodieren, aktivieren Sie Behandeln Sie + als Leerzeichen; Wenn Sie einen Pfad oder eine moderne API-URL dekodieren, lassen Sie es weg, damit ein wörtliches + ein + bleibt.
Warum die Dekodierung fehlschlägt und warum die Doppelkodierung fehlschlägt
Die Dekodierung löst einen Fehler „URI malformed“ aus, wenn auf einen % nicht genau zwei hexadezimale Ziffern folgen (0–9 A–F). Ein wörtliches Prozentzeichen im Quelltext, wie 50 % Rabatt, ist der übliche Übeltäter – es hätte als %2520 codiert werden sollen … nein, als 50 %25 Rabatt, wobei %25 der maskierte Prozentsatz ist. Das Werkzeug zeigt auf die Position der ersten fehlerhaften Sequenz, damit Sie sie lokalisieren können. Die gegenteilige Gefahr besteht in der doppelten Codierung: Wenn Sie eine Zeichenfolge codieren, die bereits %XX enthält, werden die Prozentzeichen selbst maskiert und %20 wird zu %2520. Das Tool erkennt bereits codierte Eingaben und warnt Sie, stattdessen zu decodieren.
Datenschutz: Jeder Vorgang hier wird lokal mit der nativen encodeURIComponent, encodeURI, decodeURIComponent und decodeURI des Browsers ausgeführt. Nichts, was Sie einfügen – Token, Abfragezeichenfolgen, persönliche Daten – wird jemals an einen Server gesendet.