Entwicklertools · URL-Encoder und -Decoder
Punycode vs. Prozentkodierung: Wie mit Nicht-ASCII-Domänen und -Pfaden umgegangen wird
· Hintergrund
Internationalisierung Punycode URL-Kodierung
Eine URL mit einem Nicht-ASCII-Hostnamen und einem Nicht-ASCII-Pfad verwendet zwei völlig unterschiedliche Kodierungen. In diesem Beitrag werden IDNA und Punycode für den Host, die Prozentcodierung für alles andere und die Gründe für die Aufteilung erläutert.
Die Adresse, die in einem Browser „münchen.example“ und in einem anderen „xn--mnchen-3ya.example“ anzeigt – ein Host, zwei Schreibweisen
Die Stadt München erscheint in einem deutschen Domainnamen. In der Adressleiste Ihres Browsers wird möglicherweise „munchen.example“ normal angezeigt. Kopieren Sie die Adresse aus einer anderen Anwendung und sie erscheint als xn--mnchen-3ya.example, eine reine ASCII-Zeichenfolge, die nicht wie deutscher Text aussieht. Eine URL, zwei Schreibweisen, beide absolut gültig. Beides ist nicht falsch; Sie repräsentieren dieselbe Domäne mit völlig unterschiedlichen Zeichensätzen. Der Unterschied spiegelt eine grundlegende Einschränkung der Funktionsweise von DNS und der Art und Weise wider, wie die Internetinfrastruktur die Übertragung von Hostnamen erwartet.
Pfadsegmente wie /café/ benötigen eine Codierung, verwenden aber ein anderes System. Nicht-ASCII é wird in Pfaden zu %C3%A9. Why the difference? DNS-Einschränkungen erfordern Punycode für Hostnamen.
Warum Hostnamen keine Prozentkodierung verwenden können – DNS-Bezeichnungen, zulässige Zeichen und Längenbeschränkungen
Für DNS-Labels, die durch Punkte getrennten einzelnen Segmente eines Hostnamens, gelten sehr strenge Regeln. Sie dürfen nur ASCII-Buchstaben, Ziffern, Bindestriche und Unterstriche enthalten. Sie haben Längenbeschränkungen: Jedes Label darf höchstens 63 Oktette umfassen, und der vollständige Hostname darf nicht mehr als 255 Oktette umfassen. Hierbei handelt es sich um strenge Einschränkungen des DNS-Protokolls selbst, die vor Jahrzehnten definiert wurden, bevor internationale Domainnamen überhaupt ein Konzept waren. Die prozentuale Codierung kann für Hostnamen nicht funktionieren, da die resultierende Zeichenfolge wahrscheinlich die Beschriftungsgrenzen für längere Wörter überschreiten würde.
Noch wichtiger ist, dass DNS ein globales System ist, das von Routern und Servern weltweit betrieben wird. Nicht alle verstehen UTF-8 oder Unicode. Ein prozentcodiertes Zeichen wie %C3%A9 besteht immer noch aus drei ASCII-Zeichen und entspricht daher den DNS-Einschränkungen. Dieser Ansatz bedeutet jedoch, dass jede Suche beim Eingang prozentual kodiert und beim Ausgang dekodiert werden muss, was die Komplexität der Protokollschicht selbst erhöht. Insbesondere für Hostnamen war eine bessere Lösung erforderlich.
IDNA und Punycode im Überblick – das xn-- Präfix und der Bootstring-Algorithmus, qualitativ beschrieben
IDNA, die Internationalized Domain Names in Applications-Spezifikation, löst das Hostnamenproblem, indem Nicht-ASCII-Domänennamen in ASCII kodiert werden, das DNS verarbeiten kann. Die verwendete Kodierung heißt Punycode, ein Komprimierungsalgorithmus, der Unicode-Text unter Verwendung des Präfixes xn--, gefolgt von einer Bootsstring-kodierten Darstellung, in ASCII umwandelt. Der Algorithmus ist deterministisch: münchen wird jedes Mal zu xn--mnchen-3ya. Jeder Nicht-ASCII-Hostname muss auf diese Weise konvertiert werden, bevor eine DNS-Auflösung erfolgen kann.
Das xn-- Präfix signalisiert DNS und IDNA-fähiger Software, dass die folgenden Zeichen Punycode und keine wörtlichen ASCII-Buchstaben sind. Eine Domain wie example.xn--mnchen-3ya.com wird von IDNA-fähiger Software als example.münchen.com verstanden. Punycode verwendet nur ASCII-Buchstaben, Ziffern und Bindestriche, sodass es problemlos in DNS-Labels passt. Der Algorithmus komprimiert die Nicht-ASCII-Informationen in diese ASCII-Darstellung.
Pfade, Abfragen und Fragmente bleiben prozentual codiert – UTF-8 Bytes bis %XX, wie anderswo
Alles andere in einer URL – der Pfad, die Abfragezeichenfolge, das Fragment – verwendet stattdessen die Prozentkodierung. Ein Nicht-ASCII-Zeichen wird zunächst in UTF-8 Bytes konvertiert, dann wird jedes Byte als %HH geschrieben, wobei HH hexadezimal ist. Der Pfad /café/ wird zu /caf%C3%A9/.. Die Abfragezeichenfolge ?name=josé wird zu ?name=jos%C3%A9. Prozentkodierung ist überall im Web Standard: in HTTP-Anfrage-URLs, in HTML-Formularen, in APIs. Es ist keine besondere Behandlung durch DNS oder Router erforderlich.
Durch die prozentuale Kodierung können auch andere Sonderzeichen sicher dargestellt werden. Ein Leerzeichen wird zu %20, ein Schrägstrich (sofern er innerhalb eines Werts erscheinen muss) wird zu %2F und so weiter. Das Schema ist konsistent und universell. Es wird nicht für Hostnamen verwendet, da DNS weder URLs noch Prozentkodierung versteht; es versteht nur ASCII-Beschriftungen.
Funktioniertes Beispiel: eine URL mit beiden – der in Punycode konvertierte Host, der prozentual codierte Pfad nebeneinander
Nehmen Sie die URL „https://münchen.example/café?city=münchen".. Der Hostname München muss vor der DNS-Suche in Punycode konvertiert werden: https://xn--mnchen-3ya.example/café?city=münchen. Aber warten Sie – der Pfad und die Abfrage haben auch Nicht-ASCII. Konvertieren Sie diese auch: https://xn--mnchen-3ya.example/caf%C3%A9?city=m%C3%BCnchen. Jetzt ist der Hostname Punycode, der Pfad und die Abfrage sind prozentual codiert. Ein Browser zeigt zur besseren Lesbarkeit die ursprüngliche Unicode-Version an; die HTTP-Anfrage trägt the encoded version.
Fügen Sie im URL-Encoder- und Decoder-Tool einen Pfad ein, der Nicht-ASCII-Text enthält, und vergleichen Sie den Einzelwertmodus (nur den Pfad) mit dem Gesamtadressenmodus (vollständige URL). Das Tool zeigt Ihnen das prozentual kodierte Ergebnis für den Pfad an. Der Hostname erfordert jedoch eine separate Punycode-Konvertierung; Die meisten Codierungstools verarbeiten dies nicht inline. Lesen Sie es daher in der Tooldokumentation nach.
Homograph-Angriffe und warum Browser manchmal Punycode anzeigen – die Sicherheitsgründe hinter den Anzeigeregeln
Ein böswilliger Akteur könnte eine Domain mit kyrillischen Buchstaben registrieren, die optisch mit lateinischen Buchstaben identisch aussehen, wie „https://xn--80akhbyknj4f.example"“ (eine kyrillische Version von „example.example“ in Punycode). Wenn ein Browser ihn dekodiert als kyrillischen Text anzeigt, bemerken Benutzer den Unterschied möglicherweise nicht. Um Homograph-Angriffe zu verhindern, zeigen Browser manchmal die Punycode-Version an, anstatt sie zu dekodieren. Es erscheint eine Warnung: Diese Domäne besteht ganz oder größtenteils aus Nicht-ASCII-Zeichen und Sie erkennen die Zeichen möglicherweise nicht.
Der URL-Encoder und -Decoder ist ein Tool zum Kodieren und Dekodieren, nicht zur Sicherheitsbewertung. Wenn Sie mit internationalen Domainnamen arbeiten, beachten Sie, dass das Netzwerk die Punycode-Darstellung sieht.
Was dies nicht abdeckt – das manuelle Ausführen des Punycode-Algorithmus oder die Unterschiede zwischen IDNA 2003 und 2008
IDNA hat im Laufe der Zeit mehrere Versionen durchlaufen: IDNA 2003 und IDNA 2008 behandeln bestimmte Randfälle unterschiedlich, insbesondere im Hinblick auf die Normalisierung und welche Unicode-Zeichen laut Spezifikation zulässig sind. Einige ältere Systeme verwenden immer noch IDNA 2003, während andere zur besseren Compliance auf IDNA 2008 migriert wurden. Die Unterschiede sind von erheblicher Bedeutung, wenn Sie Systeme erstellen, die über mehrere Versionen hinweg kompatibel sein müssen. Überprüfen Sie Ihre Systemanforderungen stets sorgfältig.
Punycode verwendet Bootstring-Komprimierung. Implementierungen gibt es in gängigen Sprachen, aber überprüfen Sie die IDNA-Richtlinie mit Ihrem Hostnamensystem. Testen Sie Auflösung und Anzeigeverhalten, statt Annahmen zu treffen.
Fazit: Zwei Kodierungen für zwei Aufgaben – wie der URL-Encoder und -Decoder mit den prozentkodierten Teilen umgeht und warum ein Prozentkodierer das falsche Tool für den Hostnamen ist
Hostnamen benötigen Punycode, da DNS ein altes Protokoll ist, das nur ASCII-Labels versteht und strenge Längen- und Zeichenbeschränkungen hat. Pfade, Abfragen und Fragmente verwenden die Prozentkodierung, da sie im Web universell ist und diesen Einschränkungen nicht unterliegt. Es handelt sich um zwei separate Lösungen für zwei völlig unterschiedliche Probleme. Wenn Sie auf eine Nicht-ASCII-URL stoßen, erhält der Hostname zuerst die Punycode-Konvertierung, dann wird für den Rest die Prozentkodierung verwendet.
Bei den meisten Entwicklungsarbeiten übernimmt Ihr Framework oder Ihre Bibliothek diese Konvertierung automatisch im Hintergrund. Wenn Sie jedoch verstehen, warum zwei unterschiedliche Codierungen existieren, vermeiden Sie Verwirrung beim Debuggen internationaler URLs oder beim erfolgreichen Implementieren Ihres eigenen URL-Verarbeitungscodes.