Entwicklertools · URL-Encoder und -Decoder
RFC 3986 reservierte und nicht reservierte Zeichen: Was der URI-Standard sagt
· Hintergrund
URL-Kodierung rfc3986 Prozent-Kodierung
RFC 3986 unterteilt Zeichen in reservierte, nicht reservierte und alles andere, und diese Aufteilung erklärt jede prozentuale Codierungsregel, die Sie erfüllt haben. In diesem Beitrag werden die relevanten Abschnitte klar vorgelesen.
RFC 3986 reservierte und nicht reservierte Zeichen – worauf es beim Erstellen von URLs ankommt
RFC 3986 unterteilt Zeichen in drei Kategorien: nicht reserviert, reserviert und alles andere, was codiert werden muss. Nicht reservierte Zeichen müssen nie kodiert werden – dies sind Buchstaben, Ziffern, Bindestrich, Punkt, Unterstrich und Tilde. Der RFC listet diese explizit im Abschnitt 2.3 auf und gibt an, dass sie in jedem URI-Kontext sicher uncodiert bleiben dürfen. Tests im URL-Encoder und -Decoder mit diesen Zeichen zeigen, dass sie unverändert weitergeleitet werden. Reservierte Zeichen werden in Gen-Delims (: / ? # [ ] @) und Sub-Delims (! $ & ' ( ) * + , ; =) unterteilt, die jeweils eine strukturelle Bedeutung in verschiedenen URL-Komponenten haben.
Wann muss ein Zeichen kodiert werden? Reservierte Zeichen dürfen nur dann prozentual codiert werden, wenn sie Mehrdeutigkeiten hervorrufen. Ein Schrägstrich markiert Pfadsegmente; in einem Abfragewert muss es %2F sein. Ein kaufmännisches Und trennt Parameter; & in einem Wert erfordert %26. Nicht reservierte Zeichen müssen nie kodiert werden – ein Bindestrich bleibt Bindestrich. Der URL-Standard gewährleistet eine korrekte Analyse. Testen mit URL-Encoder und -Decoder: Die Eingabe von „hello/world"“ mit encodeURIComponent erzeugt „hello%2Fworld“; mit encodeURI bleibt der Schrägstrich erhalten.
Nicht reserviert: Buchstaben, Ziffern, Bindestrich, Punkt, Unterstrich und Tilde – die Zeichen, die nie kodiert werden müssen und auch nie kodiert werden sollten
Prozentkodierung verwendet %HH, wobei HH die hexadezimale Schreibweise ist. Der ASCII-Buchstabe A (Code 65) wird zu %41. Nicht-ASCII-é erfordert die Kodierung UTF-8: é (U+00E9) wird zu %C3%A9. Moderne Standards spezifizieren UTF-8 einheitlich für alle Browser.
Vollständige URLs erfordern eine intakte strukturelle Syntax; Abfragewerte benötigen harmlose interne reservierte Zeichen. Der Abfrageparameter ?q=R&D sollte das & als %26 kodieren, wenn es manuell ist, andernfalls wird das kaufmännische Und zum Trennzeichen. Werte mit Schrägstrichen werden im Komponentenmodus zu %2F. Die Komponentenkodierung (encodeURIComponent) bewältigt dies, indem sie alles außer nicht reservierten Buchstaben, Ziffern und - _ kodiert. ! ~ * ' ( ). Tests zeigen den Unterschied zwischen den Methoden deutlich.
Reserviert: Gen-Delims und Sub-Delims – die beiden Gruppen, ihre Mitglieder und ihre strukturellen Rollen
Abfragezeichenfolgen zeigen, warum reservierte Zeichen wichtig sind. Das kaufmännische Und trennt Schlüssel=Wert-Paare: ?utm_source=email&utm_campaign=sale bedeutet zwei Parameter. Innerhalb eines Werts beendet ein kaufmännisches Und ohne Escapezeichen das Paar. „Equals“ trennt Schlüssel von Werten. Das Parsen erfolgt auf mehreren Ebenen. Jeder wendet die gleichen Regeln an.
Zu den Zeichen, die in Abfragewerten kodiert werden müssen, gehören kaufmännisches Und, Gleichheitszeichen, Hash, Fragezeichen, Leerzeichen und Nicht-ASCII-Buchstaben. Hash ist am hinterhältigsten: #anything wird zur Fragment-ID und wird nie an den Server gesendet. Kampagnennamen, die mit einem Hash enden, verlieren danach alles, bevor die Anfrage den Browser verlässt. Leerzeichen müssen zu %20 werden. Beim Testen mit URL-Encoder und -Decoder werden Komponenten- und Formularmodi angezeigt. Das Verständnis der Position bestimmt den Codierungsbedarf.
Wenn reservierte Zeichen codiert werden müssen – nur dort, wo sie mit einem Trennzeichen verwechselt werden würden, Komponente für Komponente
Prozentkodierung bleibt in RFC 3986 bestehen. Das uneingeschränkte Set bleibt klein und gewährleistet die Tragbarkeit. Prozentkodierte, nicht reservierte Zeichen können ohne Bedeutungsänderung dekodiert werden. Die Dekodierung von %41 in A ist korrekt, da A nicht reserviert ist. Durch die Dekodierung von %2F in / ändert sich die Bedeutung, wenn der Schrägstrich ein Datenwert und kein Trennzeichen ist. Der RFC-Normalisierungsabschnitt 3986 6 behandelt syntaktische Ansätze.
Reservierte Charaktere an unterschiedlichen Positionen haben unterschiedliche Rollen. Doppelpunkt im Schema markiert scheme:authority border; Doppelpunkt in Benutzerinfo sind Daten. Fragezeichen öffnet den Abfrageabschnitt; Der Schrägstrich im Abfragewert ist ein Literal. Hash markiert den Fragmentanfang. Die Position bestimmt den Kodierungsbedarf. Abfragezeichenfolgen enthalten Werte, die selbst URIs sind. Die Kodierung einer Weiterleitungs-URL wie https://example.com/page?param=value als Parameter erfordert die Kodierung von Schrägstrichen und Doppelpunkten in %2F und %3A. Der Kontext definiert immer sichere Zeichen.
Arbeitsbeispiel: Klassifizierung jedes Zeichens einer echten URL – nicht reserviert, als Trennzeichen reserviert, als Daten reserviert
RFC 1738 (1994) betrachtete viele Zeichen als unsicher. Als die Bereitstellungen auf UTF-8 standardisiert wurden, lockerten spätere Standards die Einschränkungen. Tilde (~) veranschaulicht die Entwicklung: RFC 1738 erforderte %7E, RFC 2396 (1998) verschob die Tilde in den nicht reservierten Zustand, RFC 3986 bestätigte den nicht reservierten Status. Die Evolution spiegelt die Erkenntnisse aus der Bereitstellung wider. Standards wahren die Abwärtskompatibilität.
Die RFC-Normalisierung ermöglicht die Dekodierung unnötigerweise prozentcodierter, nicht reservierter Zeichen. %41 normalisiert sich sicher auf A. Kodierte reservierte Zeichen wie %2F werden nie dekodiert; Eine sich ändernde Bedeutung zerstört die Struktur. Der moderne Konsens verwendet RFC 3986 als Referenzbasis. Der URL-Encoder und -Decoder folgt durchgehend RFC 3986 und bietet eine feste Referenz unabhängig vom Browserverhalten. WHATWG URL Standard fügt über RFC hinaus komponentenspezifische Codierungssätze hinzu. Standards existieren nebeneinander: RFC 3986 für allgemeines URL-Parsing, WHATWG für Webbrowser. Bibliotheken sind unterschiedlich; Überprüfen Sie die Dokumentation.
Normalisierungsanleitung im Abschnitt 6 – Hex-Schreibweise, uneingeschränkte Dekodierung und Pfadsegmentregeln
Tests gegen RFC 3986 stellen sicher, dass URLs über Jahrzehnte hinweg softwareübergreifend funktionieren. Der URL-Encoder und -Decoder gibt RFC 3986 eine Codierungsbasislinie zur Anwendung auf erstellte Komponenten vor. Lesen Sie die Standarddokumentation, in der jede Kodierungsentscheidung in URL-Bibliotheken erläutert wird. WHATWG URL baut auf RFC 3986 auf, anstatt es vollständig zu ersetzen. URLs für allgemeine Browser erstellen? Folgen Sie RFC 3986; Browser wenden zusätzlich die WHATWG-Regeln an. Ältere Systeme? Testen Sie tatsächliche Implementierungen. Für die Speicherung normalisieren? Wenden Sie RFC 3986 konsequent an. Wenn Sie die Unterscheidung „reserved/unreserved“ verstehen, erfahren Sie sichere Zeichen.
Die URL-Codierung ist keine Sicherheitsbereinigung. Jeder Kontext – SQL, HTML, JavaScript, URI – benötigt seine eigene Ausgabekodierung. Die prozentuale Kodierung schützt nur die URL-Struktur. Tragen Sie die richtige Verteidigung auf der richtigen Ebene auf.
Was dies nicht abdeckt – die verschiedenen Codierungssätze und die IRI-Behandlung des WHATWG-URL-Standards
RFC 2396 (1998) hat die Zeichensätze strenger geklärt als RFC 1738. Es formalisierte reservierte Zeichen, die der URI-Struktur dienen und nicht als Literaldaten reserviert sind. Vorbehaltlos erweitert, einschließlich Bindestrich, Punkt, Unterstrich und Tilde über Originaldefinitionen. RFC 2396 führte die Unterscheidung zwischen Gen-Delims (:, /, ?, #, [, ], @) und Sub-Delims (!, $, &, ', (, ), *, +, ,, ;, =) ein. Jede Gruppe hat unterschiedliche strukturelle Rollen in URLs. Durch die Benennung wird klargestellt, dass reservierte Zeichen in zwei Gruppen unterteilt werden. Die Kenntnis von Namen hilft bei technischen Diskussionen.
RFC 3986 (2005) ist eine moderne Referenz. Die Unterscheidung blieb vorbehalten/unreserved, die Notation wurde jedoch vereinfacht. Normungsgremien unterbrechen das Netz nicht rückwirkend. Codieren Sie bewusst, indem Sie Ihren Standard kennen. Der URL-Encoder und -Decoder stellt eine RFC-Referenz 3986 bereit.
Takeaway: Der Standard ist kurz und präzise – wie die beiden Modi des URL-Encoders und -Decoders der Codierung von Daten im Vergleich zur Beibehaltung von Trennzeichen entsprechen
Die Auswahl von Standards hängt vom Kontext ab. URLs für allgemeine Browser erstellen? Folgen Sie RFC 3986; Browser wenden WHATWG-Regeln an. Ältere Systeme? Testen Sie tatsächliche Implementierungen. Für die Speicherung normalisieren? Wenden Sie RFC 3986 konsequent an. Prozentcodierungsregeln haben sich vom konservativen RFC 1738 über den klareren RFC 2396 und RFC 3986 zum mehrschichtigen WHATWG-URL-Standard entwickelt. Jede Generation spiegelte die Erfahrung wider. Moderne Builder folgen kontextbezogen RFC 3986 oder WHATWG. Alte und neue URLs koexistieren und erfordern Kompatibilitätsdenken. Das Verständnis von Kategorien verhindert Codierungsfehler.
Überprüfen Sie vor der Bereitstellung, ob die URLs korrekt codiert sind. Der URL-Encoder und -Decoder demonstriert die RFC-Regeln 3986 durchgängig. Sehen Sie sich die genauen Hexadezimalwerte an und verstehen Sie, welche Zeichen kodiert werden. Verwenden Sie dieses Tool, wenn Sie URLs durch Verketten von Teilen erstellen. RFC 3986 reservierte und nicht reservierte Kategorien partitionieren Zeichensätze für eine konsistente URI-Analyse.