Entwicklertools · URL-Encoder und -Decoder
So funktioniert die Prozentkodierung: von Zeichen über UTF-8 Bytes bis hin zu %XX-Sequenzen
· Wie es funktioniert
URL-Kodierung utf-8 Prozent-Kodierung Entwickler
Prozentkodierung kodiert keine Zeichen; es kodiert Bytes. Dieser Beitrag zeigt, wie ein Zeichen zu UTF-8 Bytes und dann zu Hex-Paaren wird und warum ein Buchstabe mit Akzent zwei %XX-Gruppen benötigt, während ein Emoji vier benötigt.
Warum aus „é“ %C3%A9 und nicht %E9 wird – die Beobachtung, die die darunter liegende Byteschicht enthüllt
Wenn ein Junior-Entwickler %C3%A9 in einer URL sieht, erfolgt die Prozentkodierung auf Bytes und nicht auf Zeichen. Das Zeichen é besteht nicht aus einem Byte; UTF-8 kodiert es als zwei: C3 A9. Die Prozentkodierungsregel von RFC 3986 ist einfach: Kodieren Sie jedes Byte als Prozentzeichen, gefolgt von zwei Hexadezimalziffern. Diese Unterscheidung verwandelt die Erklärung von mysteriös in logisch.
Um die Prozentkodierung zu verstehen, muss man UTF-8 verstehen. Text muss mithilfe der Zeichenkodierung in Bytes umgewandelt werden. UTF-8 ist der Standard für URLs und Web. Es drückt Zeichen als Bytesequenzen variabler Länge aus: ASCII verwendet ein Byte, Buchstaben mit Akzent verwenden zwei, Emoji verwenden vier. Jede Stufe ist unterschiedlich: Zeichen, Unicode-Codepunkt, UTF-8 Bytes, dann %XX Paare. Das Springen zu Hex, ohne die Bytes zu verstehen, verfehlt den Sinn.
Die Prozentkodierungsregel von RFC 3986 – ein % gefolgt von zwei Hexadezimalziffern pro Byte, bevorzugt Großbuchstaben
RFC 3986 definiert eine Regel: Codieren Sie jedes Byte als Prozent, gefolgt von zwei hexadezimalen Großbuchstaben. Nicht reservierte Zeichen, die keiner Kodierung bedürfen, sind Buchstaben, Ziffern, Bindestrich, Unterstrich, Punkt und Tilde. Alles andere muss kodiert werden. Leerzeichen werden zu %20, Schrägstriche werden zu %2F und das Prozentzeichen wird zu %25. Dadurch wird verhindert, dass Sonderzeichen in Abfragewerten die URL-Struktur zerstören.
Ein Leerzeichen wird als Byte 0x20 kodiert und wird zu %20. Ein Schrägstrich ist 0x2F und wird zu %2F. Dies sind ASCII-Zeichen, die ein Byte benötigen. Akzentuierte Buchstaben und Emojis unterscheiden sich. Das Prozentzeichen wird zu %25. Reservierte Trennzeichen wie Doppelpunkte werden codiert, um die Struktur beizubehalten. Dadurch wird verhindert, dass ein eingebettetes kaufmännisches Und oder Gleichheit in einem Abfrageparameter die Analyse unterbricht. Jedes Byte wird zu %HH.
UTF-8 als angenommener Zeichensatz – warum moderne URLs UTF-8 sind und wo die alten Ausnahmen sind
UTF-8 verwendet Codierung mit variabler Länge. ASCII von den Codepunkten 0 bis 127 ist ein Byte. Die Zeichen von 128 bis 2047, einschließlich lateinischer Buchstaben mit Akzent, bestehen aus zwei Bytes. Die in ostasiatischen Schriften üblichen Zeichen von 2048 bis 65535 bestehen aus drei Bytes. Zeichen über 65535, einschließlich der meisten Emojis, umfassen vier Bytes. Jedem Byte sind Bits vorangestellt, die signalisieren, wie viele Bytes folgen.
Der akzentuierte Buchstabe é ist der Unicode-Codepunkt U+00E9. UTF-8 kodiert es als zwei Bytes: 0xC3 und 0xA9. Prozentcodierung erzeugt %C3%A9. Deutsch ü (U+00FC) wird als 0xC3 0xBC kodiert und wird zu %C3%BC. Spanisch ñ (U+00F1) wird als 0xC3 0xB1 kodiert und wird zu %C3%B1. Das Muster ist konsistent: Das erste Byte signalisiert eine Zwei-Byte-Sequenz. Ein Buchstabe mit Akzent wird in der Kodierung um sechs Zeichen erweitert.
Arbeitsbeispiel: Codierung von „café 😀“ Byte für Byte – die Codepunkte, die UTF-8 Bytes und die resultierende Zeichenfolge
Emoji macht die Byte-Ebene deutlich. Das Daumen-hoch-Emoji 👍 hat den Codepunkt U+1F44D. UTF-8 kodiert es als vier Bytes: F0 9F 91 8D. Prozentkodierung erzeugt %F0%9F%918D: zwölf Zeichen für ein Symbol. Der Smiley 😀 (U+1F600) wird als F0 9F 98 80 kodiert und wird zu %F0%9F%9880. Vier-Byte-Sequenzen werden zu zwölf Prozent kodierten Zeichen.
Gemischter Text zeigt, warum es wichtig ist, Bytes zu verstehen. Der Ausdruck „Café 😀“ enthält einfaches ASCII, einen Akzent und ein Emoji. Die Buchstaben c, a, f werden als 63, 61, 66 kodiert. Das é kodiert als C3 A9. Leerzeichen wird als 20 kodiert. Das Emoji wird als F0 9F 98 80 kodiert. Das Ergebnis ist „caf%C3%A9%20%F0%9F%9880“. Wenn Sie wissen, welche Bytes kodiert werden müssen, ist die Ausgabe vorhersehbar.
Dekodierung in umgekehrter Reihenfolge – Sammeln von %XX Gruppen in Bytes und erst dann deren Interpretation als UTF-8
Durch die Dekodierung wird der Vorgang umgekehrt. Ein Decoder sucht nach %XX-Paaren und sammelt sie in Bytewerten. Wenn %C3%A9 angezeigt wird, werden die Bytes C3 und A9 extrahiert. Die UTF-8-Dekodierung interpretiert diese als das Zeichen é. Wenn eine Sequenz unvollständig ist, wie z. B. %C3 allein, ist das Ergebnis ein Fehler. Der Decoder weiß aus den Präfixbits UTF-8, dass C3 ein zweites Byte benötigt.
Bei Hexadezimalzahlen spielt die Groß-/Kleinschreibung keine Rolle; %C3%A9 und %c3%a9 dekodieren identisch. RFC erlaubt Groß- und Kleinschreibung, Großschreibung wird jedoch bevorzugt. Für Zeichen ist jedoch die Groß- und Kleinschreibung wichtig: é (als %C3%A9) ist nicht dasselbe wie É (als %C3%89). Der URL-Vergleich muss die prozentuale Kodierung normalisieren, sonst besteht die Gefahr, dass identische Ressourcen als unterschiedlich behandelt werden. Frameworks normalisieren sich vor dem Caching.
Warum die Groß- und Kleinschreibung bei Hexadezimalziffern keine Rolle spielt, anderswo jedoch schon – Normalisierungsregeln und URL-Vergleich
RFC 3986 erwähnt Punycode für Domainnamen und Formularkodierung für Übermittlungen als separate Regeln. Punycode kodiert Nicht-ASCII-Domänennamen ohne Prozentzeichen aus Gründen der DNS-Kompatibilität. Die Domain 😀.example wird zu „xn--js8h.example“. Die Formularkodierung ändert die Prozentkodierung mit einer Ausnahme: Leerzeichen werden zu Pluszeichen anstelle von %20. Als application/x-www-form-urlencoded eingereichte Formulare verwenden Pluszeichen für Leerzeichen.
Das URL-Encoder-Tool zeigt alle drei Modi: Komponentenkodierung, Gesamt-URL-Kodierung und Formularkodierung. Komponentenkodierung mit encodeURIComponent kodiert alle Sonderzeichen, einschließlich Trennzeichen, die für Abfragewerte geeignet sind. Bei der Kodierung ganzer URLs mit encodeURI bleiben Strukturzeichen für vollständige URLs erhalten. Die Formularkodierung gilt für POST-Körper. Jeder verwendet UTF-8; Sie unterscheiden sich nur darin, welche Bytes uncodiert bleiben.
Punycode und Formularkodierung: Geschwisterstandards, keine Prozentkodierungserweiterungen
Die Byte-Perspektive löst URL-Rätsel. Warum braucht ein Emoji zwölf Zeichen? Weil UTF-8 vier Bytes verwendet, die jeweils zu %HH werden. Warum haben einige URLs %2F für Schrägstriche, während andere einfache Schrägstriche haben? Denn der Kodierungsmodus entscheidet: Ein Schrägstrich in einem Pfadsegment bleibt unkodiert, aber innerhalb eines Abfragewerts muss er %2F sein, um Fehlinterpretationen zu vermeiden.
Denken Sie in Bytes für eine vorhersehbare Prozentkodierung. Ein Zeichen ist ein Unicode-Codepunkt. UTF-8 ist seine Byte-Darstellung. Prozentkodierung ist das Übertragungsformat. Die Zeichenerweiterung erfolgt auf der Ebene UTF-8. Die Hex-Groß-/Kleinschreibung hat keinen Einfluss auf die Dekodierung, die Zeichen-Groß-/Kleinschreibung hingegen schon. Ungültige Bytesequenzen schlagen bei UTF-8 aufgrund strenger Präfixregeln fehl. Das URL-Encoder-Tool zeigt diesen Fortschritt an.
Takeaway: Denken Sie in Bytes – wie der URL-Encoder und -Decoder die genaue %XX-Ausgabe für jeden von Ihnen eingefügten Text im Browser anzeigt
Arbeitsbeispiel: Kodierung von „café 😀“. Das Wort Café hat die Buchstaben c, a, f als ASCII-Einzelbytes: 63, 61, 66. Das é ist UTF-8 zwei Bytes: C3 A9. Der Speicherplatz beträgt 20. Emoji 😀 besteht aus vier Bytes: F0 9F 98 80. Nicht reservierte ASCII-Buchstaben bleiben sichtbar. Ergebnis: „caf%C3%A9%20%F0%9F%9880“. Dies zeigt, warum ein Emoji auf zwölf Zeichen erweitert wird.
Fazit: Denken Sie in Bytes, nicht in Zeichen. Die prozentuale Kodierung wird nach der Kodierung UTF-8 angewendet. Jedes Byte wird zu %HH. Variable Länge UTF-8 bedeutet, dass Zeichen unterschiedlich erweitert werden: ASCII wird zu %XX (zwei Zeichen), Zwei-Byte-Akzente werden zu %XX%XX (sechs Zeichen), Vier-Byte-Emojis werden zu %XX%XX%XX%XX (zwölf Zeichen). Fügen Sie Text in das URL-Encoder-Tool ein und beobachten Sie den Fortschritt.