RFC-3986-Prozent-Kodierer
Nach der strengen RFC-3986-Regel wird aus hello world!'()* die Zeichenfolge hello%20world%21%27%28%29%2A: Nur Buchstaben, Ziffern, Bindestrich, Punkt, Unterstrich und Tilde bleiben unverändert. Beim Dekodieren stoppt eine unvollständige Prozentsequenz den Vorgang, statt Zeichen zu erfinden. Gratis in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Text
- hello world!'()*
- Berechnungsmodus
- Encode
- Ergebnis
- hello%20world%21%27%28%29%2A
- Länge
- 28
- Normalform
- RFC 3986
- Nicht reserviert
- A-Z a-z 0-9 - . _ ~
RFC 3986 definiert die moderne URI-Grammatik und die exakte unreservierte Zeichenmenge, die ohne Prozentkodierung erscheinen darf: Buchstaben, Ziffern, Bindestrich, Punkt, Unterstrich und Tilde.
Worin die RFC-3986-Prozentkodierung von encodeURIComponent abweicht
Prozentkodierung ersetzt unzulässige Oktette durch ein Prozentzeichen und zwei Hexadezimalziffern, damit eine Zeichenkette sicher in einer URI-Komponente reisen kann. Abschnitt 2.3 von RFC 3986 benennt die unreservierte Menge—ALPHA, DIGIT, Bindestrich, Punkt, Unterstrich und Tilde—und stellt fest, dass diese Zeichen bei der Datenproduktion nicht prozentkodiert werden sollten. Jedes andere Oktett, einschließlich reservierter gen-delims und sub-delims sowie aller nicht-ASCII-UTF-8-Bytes, sollte kodiert werden, wenn der Wert als opake Daten behandelt wird.
JavaScripts encodeURIComponent nutzt eine lockerere unmaskierte Menge, die auch Ausrufezeichen, Apostroph, öffnende und schließende Klammer sowie Sternchen als Literale behält. Das passt zum historischen Browser-Formularverhalten, weicht aber von der strengen RFC-3986-Komponentenkodierung und von vielen Serverbibliotheken in Python, Go, Java oder Rust ab, die nur die sechs unreservierten Zeichen freilassen. Der praktische Fehlerfall ist subtil: Eine Signatur oder ein Cache-Schlüssel aus «hello!
world» kann unterschiedlich hashen, wenn eine Seite hello! world und die andere hello%21world ausgibt. Dieses Werkzeug wendet bei encode stets die RFC-Abbildung mit Großbuchstaben-Hex an, sodass Mehrbyte-Zeichen wie café zu caf%C3%A9 und ein Leerzeichen zu %20 werden, während !
' ( ) * zu %21 %27 %28 %29 %2A werden. Decode akzeptiert Groß- oder Kleinbuchstaben-Hex, prüft, dass jedem Prozentzeichen genau zwei Hex-Ziffern folgen, und rekonstruiert UTF-8-Text.
Was Sie senden und was Sie zurückerhalten
Senden Sie ein Pflicht-String-Feld namens text und ein optionales Feld mode. Wenn mode weggelassen wird, ist encode der Standard, sodass eine einzelne Nutzlast weiter nützlich bleibt. Mode encode prozentmaskiert Text nach der unreservierten RFC-3986-Regel und liefert die umgewandelte Zeichenkette in result.
Mode decode validiert jede Prozentsequenz, kehrt die Kodierung um und liefert einfachen UTF-8-Text in result. Klassische Prüfungen: eine Phrase mit Leerzeichen und Ausrufezeichen kodieren, um %20 und %21 nebeneinander zu sehen, caf%C3%A9%21 zurück zu café! dekodieren und eine Zeichenkette ablehnen, die mit nacktem Prozent endet oder %ZZ enthält.
Wo strenge RFC-3986-Kodierung in der Praxis vorkommt
Backend-Dienste, die signierte Redirect-URLs, OAuth-1.0-Parameterzeichenketten oder HMAC-kanonische Anfragen bauen, verlangen oft Prozentkodierung nach RFC 3986 statt Browser-encodeURIComponent, weil Signatur-Basiszeichenketten ! ' ( ) * als zu maskierende Zeichen behandeln. Mobile und Desktop-Clients außerhalb des JavaScript-Ökosystems liefern typischerweise Bibliotheken, die bereits die Nur-unreserviert-Regel befolgen; eine Node-Middleware, die encodeURIComponent für dieselben Werte nutzte, würde intermittierende Signaturfehler erzeugen, die nur auftreten, wenn ein Produkttitel oder Anzeigename Apostroph oder Klammer enthält.
Support-Ingenieure fügen halb kodierte Zeichenketten aus Tickets und Protokollen ein und brauchen einen Decode-Pfad, der bei abgeschnittenen Escapes laut scheitert statt Zeichen zu erfinden. Curriculum-Autoren für Web-Grundlagen wollen eine eigene Seite zur RFC-3986-Prozentkodierung mit expliziter unreservierter Menge statt das Thema unter einem generischen URL-Kodierer oder Base64-Werkzeug zu vergraben, weil Suchintention und der !'() *-Unterschied das sind, wonach Studierende und Integratoren suchen.
Lokalisierungsingenieure prüfen, dass Mehrbyte-Sprachen ohne Mojibake rundlaufen. Wenn Sie encodeURIComponent-Semantik, leichte Voll-URI-Kodierung mit strukturellen Trennzeichen, Base64 oder Slug-Erzeugung brauchen, behandeln Sie das als getrennte Suchintentionen und Landings statt diese RFC-3986-Kodiererseite zu überladen.
Anwendungsfälle
OAuth und signierte Abfragezeichenketten
Prozentkodieren Sie Parameterwerte mit der strengen unreservierten RFC-3986-Menge, damit HMAC- und OAuth-Basiszeichenketten mit Nicht-JavaScript-Partnern übereinstimmen, die ! ' ( ) * maskieren.
URI-Fragmente aus Protokollen oder Einfügen dekodieren
Dekodieren Sie prozentkodierte Fragmente aus Protokollen und Tickets zu lesbarem UTF-8, mit harten Fehlern bei unvollständigen oder nicht hexadezimalen Prozentsequenzen.
Häufige Fragen
Worin unterscheidet sich das von encodeURIComponent?
encodeURIComponent lässt ! ' ( ) * unmaskiert. Dieses Werkzeug folgt nur den unreservierten RFC-3986-Zeichen (A–Z a–z 0–9 - . _ ~) und prozentkodiert diese vier sub-delims als %21 %27 %28 %29 %2A.
Kann ich sowohl kodieren als auch dekodieren?
Ja. Setzen Sie mode auf encode (Standard), um Klartext nach RFC 3986 zu prozentmaskieren, oder mode auf decode, um UTF-8-Text aus einer prozentkodierten Zeichenkette wiederherzustellen.
Sind Hex-Ziffern beim Encode groß- oder kleingeschrieben?
Encode gibt großgeschriebene Hexadezimalziffern aus (%2A nicht %2a), die bevorzugte Form in RFC 3986. Decode akzeptiert Groß- und Kleinbuchstaben-Hex.
Warum schlägt meine OAuth-Signatur bei Namen mit Klammern fehl?
Meist, weil eine Seite die Klammern unverändert lässt und die andere %28 und %29 schreibt. Dadurch unterscheiden sich die signierten Zeichenfolgen. Kodieren Sie beide Werte nach RFC 3986, dann werden ! ' ( ) * immer maskiert und beide Seiten erzeugen denselben Text.
Was passiert bei einer fehlerhaften Prozentsequenz?
Die Dekodierung bricht ab und nennt die Stelle des Problems, etwa ein einzelnes Prozentzeichen am Ende oder eine Folge wie %G1. Sie erhalten nie einen halb dekodierten Text mit erfundenen Zeichen.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/enc/url-rfc3986 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"hello world!'\''()"}'const res = await fetch("https://api.kit.forhosting.com/enc/url-rfc3986", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "hello world!'()"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/url-rfc3986",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "hello world!'()"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/url-rfc3986", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"hello world!\'()"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"hello world!'()"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/url-rfc3986", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"text": "hello world!'()"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.url_rfc3986",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Viele Alltagswerkzeuge folgen JavaScript-encodeURIComponent und lassen Ausrufezeichen, Apostrophe, Klammern und Sternchen absichtlich unmaskiert—Zeichen, die RFC 3986 als sub-delims einstuft und die strenge Gateways, OAuth-Signierer und sprachübergreifende HTTP-Clients oft als %21 %27 %28 %29 %2A erwarten. Diese Fähigkeit wendet die strenge RFC-3986-Abbildung in beide Richtungen an: encode wandelt jedes nicht unreservierte UTF-8-Byte in großgeschriebenes %HH um, und decode stellt Klartext wieder her und scheitert sofort an unvollständigen oder nicht hexadezimalen Prozentsequenzen. Nutzen Sie sie, wenn Ihr Vertrag «Prozentkodierung gemäß RFC 3986» verlangt, wenn Sie mit einem Nicht-JavaScript-Gegenstück übereinstimmen müssen, das nur die sechs unreservierten Satzzeichen belässt, oder wenn Sie ein einziges kostenloses Browser-Werkzeug und eine bezahlte API brauchen, die byteweise auf derselben reinen Funktion übereinstimmen. Der Preis erfolgreicher API-Aufrufe ist die veröffentlichte Basis von $0.002 pro Element; Validierungsfehler werden nicht berechnet.
Worin die RFC-3986-Prozentkodierung von encodeURIComponent abweicht
Ein abschließendes nacktes Prozent, eine Sequenz wie %G1 oder ungültiges UTF-8 nach der Expansion löst invalid_input mit positionsbezogener Meldung aus statt halb dekodiertem Müll. Der Pfad ist reine String-Arbeit ohne Netz, ohne Zufalls-Seeds und ohne Wanduhr, sodass identische Eingaben stets identisches JSON erzeugen. Erfolgreiche API-Preise sind die veröffentlichte Basis von $0.002 pro Element.
Was Sie senden und was Sie zurückerhalten
Die Antwort spiegelt mode und den originalen text wider, enthält result und die length von result und kennzeichnet den Vertrag mit standard auf RFC 3986, einer kurzen unreserved-Zusammenfassung und also_escaped mit den vier sub-delim-Zeichen, die diese Abbildung von encodeURIComponent unterscheiden. Fehlendes text, Nicht-String-Objekte, nicht unterstützte mode-Werte, Zeichenketten über dem dokumentierten Maximum, unvollständige Prozent-Escapes, Nicht-Hex-Ziffern nach einem Prozent und Host-Fehler bei ungültigem dekodiertem UTF-8 scheitern mit invalid_input und einer klaren englischen Meldung. Validierungsfehler verbrauchen kein Prepaid-Guthaben. Erfolgreiche API-Preise sind die veröffentlichte Basis von $0.002 pro Element und entsprechen anderen Parse-Kodierern im Katalog.
Wo strenge RFC-3986-Kodierung in der Praxis vorkommt
Weil diese Fähigkeit eine reine Parse-Engine ist, beträgt der API-Preis die veröffentlichte Basis von $0.002 pro erfolgreichem Element und fehlgeschlagene Validierung wird nicht berechnet.
Integrationsbeispiele
Sprachübergreifende Golden-Fixtures
Erzeugen Sie Encode- und Decode-Vektoren, auf die sich Python-, Go-, Java- und Rust-URL-Bibliotheken einigen, einschließlich der sub-delim-Zeichen, die Browser oft literal lassen.
Technische Fragen
Was passiert bei einer fehlerhaften Prozentsequenz?
Decode scheitert mit invalid_input und nennt Position und schlechtes Escape (zum Beispiel unvollständiges % oder Nicht-Hex-Ziffern). Validierungsfehler werden nicht berechnet.
Was kostet der RFC-3986-Prozent-Kodierer?
Das Browser-Werkzeug ist kostenlos und läuft lokal. API-Anfragen nutzen Prepaid-KIT-Guthaben zu $0.002 pro erfolgreichem Element; ungültige Eingabe wird nicht berechnet.