URL-encodering: waarom webadressen soms vol procenttekens en vreemde tekens staan
Typ je weleens een adres in de zoekbalk en zie je ineens iets als %20 of %C3%A9 tussen de letters staan? Dat is geen foutmelding en geen hack, maar URL-encodering: een manier om tekens die een webadres niet mag of kan bevatten, om te zetten in een code die elke computer ter wereld begrijpt. Vergelijk het met het versturen van een pakket naar het buitenland. Sommige spullen mogen niet zomaar de post in — vloeistoffen, batterijen — en moeten eerst apart worden verpakt en van een label voorzien voordat het vervoersysteem ze accepteert. Een webadres werkt net zo: het internet accepteert alleen een beperkte set tekens rechtstreeks, en al het andere moet eerst worden 'verpakt' in een vaste code.
Een concreet voorbeeld: een spatie mag niet zomaar in een URL staan, want in de allereerste internetstandaarden gaf een spatie het einde van een adres aan. Een spatie wordt daarom vaak %20 (of soms een +). Wil je met de letter 'é' zoeken, dan zie je in de adresbalk vaak %C3%A9 verschijnen. Die vreemde reeks tekens is precies wat je nodig hebt om betrouwbaar een webpagina te openen, een zoekopdracht te versturen of een link te delen zonder dat er iets verloren gaat of verkeerd wordt geïnterpreteerd.
Wat is het precies?
Een webadres, technisch een URL (Uniform Resource Locator) of breder URI (Uniform Resource Identifier) genoemd, mag volgens de internetstandaarden alleen uit een beperkte set 'veilige' tekens bestaan: de letters a tot z, cijfers 0 tot 9, en een handvol leestekens zoals een streepje, punt of liggend streepje. Alle andere tekens — spaties, leestekens als vraagtekens binnen een zoekterm, of letters met accenten zoals é, ü of ñ, maar ook emoji of Cyrillische en Chinese tekens — moeten eerst worden omgezet.
Dat omzetten gebeurt in twee stappen. Eerst wordt het teken vertaald naar een reeks bytes volgens een tekenset, tegenwoordig vrijwel altijd UTF-8, de standaard die vrijwel elk teken ter wereld kan weergeven. Daarna wordt elke byte geschreven als een procentteken gevolgd door twee hexadecimale cijfers (0-9 en A-F). Zo wordt de spatie, die in UTF-8 de bytewaarde 32 heeft, geschreven als %20, en wordt 'é' (dat in UTF-8 uit twee bytes bestaat) %C3%A9. Dit proces heet percent-encoding of procent-codering.
Deze stap gebeurt meestal onzichtbaar, in de browser of in de software achter een website. Programmeurs gebruiken hiervoor kant-en-klare functies, zoals encodeURIComponent in JavaScript of vergelijkbare functies in Python en andere talen, zodat ze niet zelf met tabellen van bytewaarden hoeven te werken. Bij het terugvertalen — decoderen — wordt de procentcode weer omgezet naar het oorspronkelijke teken, zodat de gebruiker gewoon 'café' te zien krijgt in plaats van de gecodeerde variant.
Wat wil men ermee bereiken?
Het internet is ontworpen rond een klein en strikt gedefinieerd alfabet van tekens, zodat elk apparaat — van een server in Japan tot een smartphone in Nederland — een adres op precies dezelfde manier kan lezen, ongeacht het besturingssysteem, de taal of de tekenset die lokaal gebruikt wordt. URL-encodering lost het probleem op dat mensen wereldwijd duizenden verschillende tekens en symbolen gebruiken, terwijl de basis-infrastructuur van het web maar een handjevol tekens rechtstreeks aankan.
Daarnaast voorkomt encodering verwarring en fouten. Een teken als een vraagteken of een ampersand (&) heeft in een URL al een speciale betekenis: het scheidt bijvoorbeeld het adres van de zoekparameters. Als zo'n teken toevallig ook in de eigenlijke inhoud van een zoekopdracht voorkomt — bijvoorbeeld iemand zoekt naar 'vraag & antwoord' — dan moet dat teken gecodeerd worden, anders leest de server het adres verkeerd en breekt de link. Het doel is dus tweeledig: universele leesbaarheid over alle systemen heen, en het voorkomen dat data en structuur van een adres door elkaar lopen.
Voorbeelden uit de praktijk
Wikipedia is een van de zichtbaarste dagelijkse voorbeelden: paginatitels met accenten of niet-Latijnse tekens verschijnen in de adresbalk vaak volledig percent-encoded, bijvoorbeeld bij artikelen met een naam als 'Étienne' of bij pagina's in het Japans of Arabisch. Wie zo'n link kopieert en plakt, ziet een lange reeks procenttekens, terwijl de pagina zelf gewoon leesbaar blijft.
In 2005 verscheen RFC 3986, opgesteld door internetpioniers Tim Berners-Lee (de uitvinder van het web), Roy Fielding en Larry Masinter, als de formele opvolger van eerdere standaarden uit 1994 en 1998. Dit document legt tot op de dag van vandaag exact vast welke tekens wel en niet gecodeerd moeten worden.
Een minder onschuldig praktijkvoorbeeld deed zich voor in april 2017, toen onderzoeker Xudong Zheng liet zien dat je met internationale domeinnaam-codering (IDN, een verwante techniek die niet-Latijnse tekens in domeinnamen omzet naar een ASCII-code genaamd Punycode) een domein kon registreren dat er in de adresbalk van Chrome en Firefox identiek uitzag als 'apple.com', terwijl het in werkelijkheid uit Cyrillische letters bestond. Browserbouwers pasten hun software daarna aan om zulke verwarrende domeinnamen expliciet als gecodeerde tekst (bijvoorbeeld beginnend met 'xn--') te tonen, juist om phishing tegen te gaan.
Ook alledaagse zoekmachines leunen op deze techniek: typ je een zoekterm met een spatie of leesteken in Google, dan zie je in de adresbalk vaak parameters als q=zoekterm%20hier. En bij het delen van links op sociale media worden trackingparameters (zoals UTM-codes die bedrijven gebruiken om te meten waar bezoekers vandaan komen) vaak automatisch gecodeerd toegevoegd aan de link.
Hoe ver is de techniek?
URL-encodering is geen opkomende technologie maar een volwassen, decennialang gebruikte en zeer stabiele afspraak — te vergelijken met de afspraak dat we rechts rijden op de weg. Het fundament ligt vast in RFC 3986 uit 2005, en wordt sindsdien nauwelijks fundamenteel gewijzigd. Wel wordt de praktische toepassing continu bijgeschaafd via de WHATWG URL Living Standard, een 'levend document' dat sinds ongeveer 2011 wordt bijgehouden door de gezamenlijke browserbouwers en dat in detail beschrijft hoe browsers URL's exact moeten interpreteren, ook in randgevallen.
De belangrijkste resterende hobbels zijn geen doorbraken die nog moeten komen, maar praktische inconsistenties. Zo gebruikt het formaat voor webformulieren (application/x-www-form-urlencoded, met wortels in de HTML-standaard uit de jaren negentig) van oudsher een +-teken voor een spatie, terwijl de algemene URL-standaard %20 voorschrijft. Die twee systemen door elkaar gebruiken leidt nog regelmatig tot kleine bugs bij ontwikkelaars. Ook is er discussie over hoe streng systemen moeten omgaan met 'dubbele codering' (een teken dat per ongeluk twee keer wordt gecodeerd), een fout die soms door kwaadwillenden wordt misbruikt om beveiligingsfilters te omzeilen — een reden waarom beveiligingsteams decodering en validatie van URL's als aandachtspunt blijven noemen.
Wie werken eraan?
Het onderhoud van de formele standaard ligt bij de IETF (Internet Engineering Task Force), de internationale, vrijwillige organisatie die internetstandaarden via RFC-documenten vastlegt. De dagelijkse, praktische uitwerking voor browsers gebeurt via het WHATWG (Web Hypertext Application Technology Working Group), een samenwerkingsverband van de grote browserbouwers Google (Chrome), Mozilla (Firefox), Apple (Safari) en Microsoft (Edge). Het bredere web-ecosysteem rond gerelateerde standaarden, zoals HTML-formulieren, wordt mede vormgegeven door het W3C (World Wide Web Consortium). Voor internationale domeinnamen en de bijbehorende Punycode-codering speelt daarnaast ICANN, de organisatie die toezicht houdt op het wereldwijde domeinnaamsysteem, een rol bij het beleid rond welke tekens toegestaan zijn.