Entwicklertools · URL-Encoder und -Decoder
Vom RFC 1738 zum URL-Standard: Wie sich Prozentkodierungsregeln entwickelt haben
· Hintergrund
URL-Kodierung RFC-Verlauf Webstandards
Die Regeln für Escape-Zeichen in URLs wurden seit 1994 mehrmals umgeschrieben. Dieser Beitrag folgt RFC 1738, RFC 2396, RFC 3986 und dem WHATWG-URL-Standard und erklärt, was sich jedes Mal geändert hat.
Vom RFC 1738 zum URL-Standard – wie sich Prozentkodierungsregeln entwickelt haben
Tilde (~) veranschaulicht, wie sich Codierungsregeln über Standardgenerationen und Bereitstellungen hinweg ändern. RFC 1738 (1994) überall %7E erforderlich; RFC 2396 (1998) hat die Tilde auf „unreserviert“ verschoben, was die Uncodierung zulässt. RFC 3986 (2005) bestätigte den uneingeschränkten Status. Alte URLs mit %7E bleiben gültig; neue Bauherren Ausgabe ~. Die Evolution spiegelt die Erkenntnisse aus der Bereitstellung wider, da das Web ausgereift und die Infrastruktur standardisiert ist. RFC 1738 war konservativ, da die frühe Infrastruktur heterogen und vielfältig war.
RFC 1738 kodifiziertes 1994 Browserverhalten. Bereitstellungen standardisiert auf UTF-8; Einschränkungen erwiesen sich als unnötig. Spätere Standards lockerten die Zeichenbeschränkungen. RFC 3986 ermöglicht die sichere Dekodierung nicht reservierter Zeichen.
RFC 1738 (1994): „unsichere“ Zeichen und die ersten Escape-Regeln – was als gefährlich galt und warum
RFC 1738 definierte „unsichere“ Zeichen als solche, die mit der URI-Syntax (Leerzeichen, Schrägstrich) in Konflikt stehen, historisch in Protokollen verwendet wurden (Steuerzeichen) oder die Systeme nicht sicher übertragen konnten. Die konservative Liste ist weitaus mehr prozentcodiert, als für das moderne Internet erforderlich ist. Viele frühe Systeme existierten vor RFC; es kodifizierte ihr Verhalten. Kontrollzeichen waren in Protokollen wirklich gefährlich; Leerzeichen waren Übertragungsprobleme für HTTP-Clients, die aus Befehlszeilen lesen. Moderne Systeme handhaben diese Fälle durch explizite Codierung eleganter.
Tests gegen RFC 1738 zeigen, was alte Systeme erwartet haben. Codieren Sie ein Zeichen aus der URL-Spezifikation der 1990er Jahre und vergleichen Sie es mit dem modernen RFC 3986. Unterschiede zeigen, was entspannt wurde. Das uneingeschränkte Set wurde im Laufe der Zeit erweitert. Bindestrich, Punkt und Unterstrich waren immer sicher. Tilde brauchte RFC 2396, um sicher zu sein. Konservativer Ansatz bedeutete Abwärtskompatibilität. Alte URLs, die nach den RFC-Regeln 1738 erstellt wurden, bleiben auch heute noch gültig. Die Normalisierung im RFC-3986-Abschnitt 6 ermöglicht die sichere Dekodierung unnötigerweise prozentcodierter, nicht reservierter Zeichen.
RFC 2396 (1998) – reserviert versus nicht reserviert, die generische Syntax und die Tilde rehabilitiert
RFC 2396 (1998) hat die Zeichensätze strenger geklärt als RFC 1738. Es formalisierte reservierte Zeichen, die der URI-Struktur dienen, im Vergleich zu nicht reservierten Zeichen als Literaldaten. Uneingeschränkt erweitert, einschließlich Bindestrich, Punkt, Unterstrich und Tilde. Es erkannte die generische URI-Syntax getrennt von schemaspezifischen Regeln an. RFC 2396 führte die Unterscheidung zwischen Gen-Delims (:, /, ?, #, [, ], @) und Sub-Delims (!, $, &, ', (, ), *, +, ,, ;, =) ein. Durch die Benennung wird klargestellt, dass reservierte Zeichen in zwei Gruppen mit unterschiedlichen strukturellen Rollen unterteilt werden.
RFC 2396 führte eine Normalisierungsrichtlinie ein, die angibt, welche prozentcodierten Zeichen ohne Bedeutungsänderung dekodiert werden können. Die uneingeschränkte Zeichendekodierung wird normalisiert. Reservierte Zeichenkodierungssticks. RFC 3986 vereinfachte die Notation weiter. Standards achten streng auf die Abwärtskompatibilität.
RFC 3986 (2005) — ! * ' ( ) zu Sub-Delims wechseln, Gen-Delims werden benannt und die Normalisierungsanleitung wird angezeigt
RFC 3986 (2005) ist ein moderner Referenzstandard für die Prozentkodierung. Es behielt die reservierte /unreserved-Unterscheidung bei, vereinfachte jedoch die Notation und fügte Normalisierungsanleitungen hinzu. Tilde bewegte sich eindeutig vorbehaltlos. Standardmäßig geklärte, prozentkodierte, nicht reservierte Zeichen können ohne Bedeutungsänderung dekodiert werden. Der RFC-Abschnitt 3986 3 beschreibt die URI-Syntax präzise. Abschnitt 2 definiert Zeichenkategorien. Abschnitt 6 widmet formale Regeln der syntaktischen Normalisierung. Bei der vergleichsbasierten Normalisierung werden URIs als identisch betrachtet, wenn normalisierte Formen übereinstimmen. Das Entfernen von Punktsegmenten aus Pfaden normalisiert sich, ohne dass sich die Bedeutung ändert.
Normalisierung ist wichtig für Analyse, Caching und Linkverfolgung. URLs, die sich nur in der Groß-/Kleinschreibung unterscheiden (RFC 3986 bevorzugt Großbuchstaben), sollten in der Praxis identisch sein. Durch die Normalisierung werden doppelte Protokolleinträge und Cache-Fehler verhindert. Auf normalisierten URLs verschlüsselte Caches stellen Inhalte unabhängig von der Kodierungspräferenz des Anforderers bereit. Mithilfe der RFC 3986-Normalisierungsanleitung können Systeme konsistente Entscheidungen treffen. Eine strikte Durchsetzung führt jedoch dazu, dass URLs im aktuellen Internet einwandfrei funktionieren.
Der WHATWG-URL-Standard: Analysieren, was Browser tatsächlich empfangen – Codierungssätze, spezielle Schemata und Fehlertoleranz
WHATWG-URL-Standard (2016–vorhanden) entstand aus der Browsererfahrung mit URLs, die RFC 3986 nicht perfekt entsprechen. Browser waren mit unverschlüsselten Leerzeichen, gemischten Kodierungen und Macken konfrontiert. WHATWG beschreibt echtes Browser-Parsing, keine theoretische Grammatik. Reale Browser hatten praktische Regeln für die Toleranz von Leerzeichen, den Umgang mit maskierten Zeichen und die Wiederherstellung nach fehlerhaften Eingaben entwickelt. RFC 3986 kam in 2005 an und definierte die formale Grammatik, aber in der Praxis waren die Browser bereits leicht unterschiedlich.
WHATWG definiert neun Codierungssätze mit kontextspezifischen Regeln. Leerzeichen im Pfad wird zu %20; Schrägstrich in Benutzerinfo wird zu %2F. Der Browser wendet einen engeren Standard für das Web an. RFC 3986 stellt eine Basislinie bereit; WHATWG baut darauf auf.
Arbeitsbeispiel: eine URL mit einer Tilde, einem Leerzeichen und einem Nicht-ASCII-Zeichen – wie jede Regelgeneration sie kodiert
Internationalisierte Domains verwenden Punycode-Kodierung (München wird zu xn--mnchen-3ya). Pfade und Abfragen verwenden weiterhin die Prozentkodierung. Der Domain-Teil verwendet Punycode; Pfad- und Abfrageteile verwenden Prozentkodierung. Schichten vermischen oder stören sich nicht.
IDNA (Internationalized Domain Names in Applications) löst das Hostnamen-Problem. Punycode kodiert Nicht-ASCII aus Gründen der DNS-Kompatibilität in ASCII. Das Präfix xn-- signalisiert die Punycode-Kodierung. Der Algorithmus ist deterministisch: münchen wird immer zu xn--mnchen-3ya. Nicht-ASCII-Zeichen müssen vor der DNS-Auflösung konvertiert werden. Die prozentuale Kodierung funktioniert aufgrund von DNS-Einschränkungen und Bezeichnungsbeschränkungen nicht für Hostnamen. Jeder Ansatz löst ein anderes Problem richtig. Standards wurden aus guten Gründen separat entwickelt.
Was dies nicht abdeckt – IRIs und internationalisierte Domainnamen, die ihre eigene Geschichte haben
Die Auswahl von Standards hängt vom Kontext ab. URLs für Browser erstellen? Folgen Sie RFC 3986; Browser wenden WHATWG an. Ältere Systeme? Testimplementierungen. Das Verständnis der Evolution verhindert Verwirrung.
Moderne Builder sollten RFC 3986 oder WHATWG kontextbezogen befolgen. Alte und neue URLs existieren nebeneinander und erfordern sorgfältige Überlegungen zur Kompatibilität. Der URL-Encoder und -Decoder folgt durchgehend RFC 3986 und bietet eine feste Referenz unabhängig vom Browserverhalten. WHATWG fügt komponentenspezifische Codierungssätze hinzu, die über die RFC-Grundlagen hinausgehen. Zu wissen, was sich wann geändert hat, hilft zu verstehen, warum Systeme unterschiedlicher Meinung sind. Das Testen Ihrer URL mit beiden Standards zeigt, welche Standardkontrollen in Ihrer Umgebung erfolgen. Beide Standards sind korrekt.
Takeaway: Wissen Sie, welchem Regelwerk Ihr Code folgt – wie der URL-Encoder und -Decoder Ihnen das RFC-3986-Verhalten als festen Referenzpunkt liefert Die
RFC 3986-Normalisierung ermöglicht die sichere Dekodierung unnötigerweise prozentcodierter, nicht reservierter Zeichen. %41 normalisiert sich auf A. Kodierte reservierte Zeichen wie %2F werden nie dekodiert; Eine sich ändernde Bedeutung zerstört die Struktur. Normungsgremien legen großen Wert auf Abwärtskompatibilität. Eine Lösung würde eine weltweite Koordination erfordern, die nach Jahrzehnten unmöglich ist. Standardbücher zerstören nicht rückwirkend das Internet. Durch die Änderung von Kodierungsentscheidungen werden Milliarden bestehender Systeme gleichzeitig beschädigt.
Prozentkodierung umfasst drei Jahrzehnte sorgfältiger Entwicklung: von RFC 1738 über RFC 2396 und RFC 3986 bis zum modernen WHATWG-URL-Standard. Moderner Code sollte der RFC-Grundlinie 3986 folgen. Alte URLs mit früherer Kodierung behalten ihre Gültigkeit. Das Testen von Roundtrips stellt Korrektheit und Kompatibilität sicher.