URI-Komponenten-Encoder

Wenn Sie jemals einen Wert wie name=John & Jane in eine URL eingegeben haben, ohne ihn zu kodieren, wissen Sie, wie schmerzhaft das ist: das & wird als neuer Parameter gelesen und der Server sieht Müll. Dieses Tool kodiert jede Zeichenkette prozentual für die sichere Verwendung als URI-Komponente nach RFC 3986 und wandelt jedes reservierte Zeichen in ein %HH-Paar um (Leerzeichen inbegriffen). Fügen Sie ein Fragment, einen Abfragewert oder ein Weiterleitungsziel ein und erhalten Sie etwas, das sicher in jede URL eingefügt werden kann.

So kodieren Sie eine URI-Komponente

  1. 1

    Fügen Sie Ihren Wert ein

    Geben Sie einen einzelnen Abfrageparameterwert, einen Pfadabschnitt oder einen Fragmentstring ein.

  2. 2

    Wählen Sie kodieren oder dekodieren

    Ändern Sie die Richtung, um Prozent-Escapes wieder in die ursprünglichen Zeichen umzuwandeln.

  3. 3

    Führen Sie es aus

    Das Tool kodiert jedes Zeichen in UTF-8 und ersetzt dann jedes reservierte Byte durch %HH.

  4. 4

    Kopieren Sie das Ergebnis

    Fügen Sie die Ausgabe direkt in Ihre URL-Vorlage oder Ihren API-Client ein.

Was wird maskiert

Dieser Encoder folgt RFC 3986: Nur die unreservierte Menge bleibt unberührt, A-Z a-z 0-9 - _ . ~. Alles andere wird als Prozent-kodiertes UTF-8 ausgegeben, auch das Leerzeichen und die Sub-Delimiter ! * ' ( ), die JavaScripts encodeURIComponent unberührt ließe.

Zeichen Kodiert als
Leerzeichen %20
! %21
# %23
& %26
' %27
( %28
) %29
* %2A
+ %2B
/ %2F
= %3D
? %3F
é %C3%A9

Komponente vs vollständige URI

Dieser Encoder ist strenger als encodeURI, das : / ? # [ ] @ ! $ & ' ( ) * + , ; = unberührt lässt, weil diese Zeichen strukturell in einer URL sind. Für einen Wert, den Sie in eine Abfragezeichenfolge einfügen, wollen Sie die strenge Form, und genau die erzeugt dieses Tool: Es maskiert sogar ! ' ( ) * und geht damit einen Schritt weiter als JavaScripts encodeURIComponent.

const url = `/search?q=${encodeURIComponent(userInput)}`;

Häufige Fallstricke

  • Doppelte Kodierung: Etwas zu kodieren, das bereits kodiert ist, ergibt %2520 statt %20. Dekodieren Sie immer zuerst, wenn Sie sich über die Quelle unsicher sind.
  • Pluszeichen in Formularen: HTML-Formularübermittlungen kodieren Leerzeichen als +, nicht als %20. Dekodierer, die RFC 3986 strikt folgen (dieser eingeschlossen), wandeln + nicht zurück in ein Leerzeichen. Verwenden Sie in diesen Fällen einen formularbewussten Dekodierer.
  • Pfadtrennzeichen: Das Kodieren von / verwandelt es hier in %2F. Wenn Sie eine echte Pfadstruktur behalten wollen, setzen Sie die Segmente zuerst zusammen und kodieren Sie jedes einzeln.

Häufig gestellte Fragen

Es ist Prozent-Kodierung nach RFC 3986, die strenge Form. Es maskiert :, /, ?, # und die übrigen reservierten Zeichen (dazu !, ', (, ) und *), weil eine Komponente keine URL-Struktur in sich tragen sollte. Damit ist es strenger als JavaScripts encodeURIComponent und deutlich strenger als encodeURI.

%20 ist der Weg gemäß RFC 3986. + für Leerzeichen ist ein Erbe aus der Kodierung des application/x-www-form-urlencoded-Körpers. Für Abfragezeichenfolgen in URLs ist %20 immer sicher; + wird nur auf dem Server erwartet, wenn es durch ein Formular-POST erzeugt wurde.

Jedes Zeichen wird zuerst in UTF-8 kodiert, dann wird jedes Byte maskiert. Ein Zeichen wie 日 wird zu %E6%97%A5 (drei Bytes).

Nein. Der Wert wird auf dem Server prozentual kodiert, um Ihr Ergebnis zu erzeugen, und wird nicht gespeichert oder protokolliert; nichts, was Sie einfügen, bleibt nach dem Senden der Antwort erhalten.

Verwandte Tools

Tool in anderen Sprachen verfügbar