URL Encoder/Decoder

De Wetenschap en Geschiedenis van Procentcodering

Procentcodering ontstond uit een fundamentele beperking van het vroege internet: de ASCII-restrictie. Toen Tim Berners-Lee in 1994 de URL-syntaxis ontwierp, beperkte de Uniform Resource Locator-specificatie (RFC 1738) webadressen tot een kleine subset van ASCII-tekens. Dit was logisch voor het overwegend Engelstalige internet van de vroege jaren '90, maar het betekende dat elk teken buiten deze veilige set een representatiemechanisme nodig had. De oplossing was elegant eenvoudig: vertegenwoordig elke onveilige byte als een procentteken gevolgd door zijn tweecijferige hexadecimale waarde. Een spatie (bytewaarde 32, hex 20) wordt %20, een vraagteken (bytewaarde 63, hex 3F) wordt %3F. Dit schema kon elke bytewaarde van 00 tot FF vertegenwoordigen, waardoor het elk teken in elke tekenset kon coderen. De introductie van UTF-8 als de standaard tekencodering van het web transformeerde procentcodering van een eenvoudig byte-toewijzingsschema naar een multi-byte coderingssysteem. Een enkel Chinees teken kan drie bytes in UTF-8 vereisen, wat drie opeenvolgende procentgecodeerde drielingen oplevert. Het euroteken bijvoorbeeld bezet drie bytes (E2, 82, AC) en wordt de zespositiereeks %E2%82%AC. Daarom kunnen gecodeerde URL's met niet-Latijnse tekst er aanzienlijk langer uitzien. RFC 3986, gepubliceerd in 2005, verfijnde de oorspronkelijke URL-specificatie en formaliseerde de moderne regels voor procentcodering. Het vestigde het concept van gereserveerde en niet-gereserveerde tekensets, waarbij werd verduidelijkt welke tekens als structurele scheidingstekens in URL's dienen. Dit onderscheid verklaart waarom er twee coderingsfuncties in JavaScript bestaan: encodeURI behoudt structuurtekens voor volledige URL's, terwijl encodeURIComponent alles codeert voor veilige inbedding. De specificatie introduceerde ook het principe van normalisatie, dat definieert wanneer twee verschillend gecodeerde URL's als equivalent moeten worden beschouwd.

Methodologie

URL-codering vervangt onveilige ASCII-tekens door een procentteken (%) gevolgd door twee hexadecimale cijfers die de bytewaarde van het teken vertegenwoordigen. Een spatie wordt bijvoorbeeld %20 (hex 20 = decimaal 32), een ampersand wordt %26 en een plusteken wordt %2B. De codering volgt RFC 3986, die de set van niet-gereserveerde tekens definieert die nooit codering nodig hebben: hoofd- en kleine letters (A-Z, a-z), cijfers (0-9) en vier speciale tekens (koppelteken, punt, underscore, tilde). Deze tool biedt twee coderingsmodi die rechtstreeks overeenkomen met JavaScript's native functies. De Componentmodus gebruikt encodeURIComponent(), die elk teken behalve de niet-gereserveerde set codeert, ideaal voor queryparameterwaarden waar tekens als & en = moeten worden ge-escaped. De Volledige URL-modus gebruikt encodeURI(), die aanvullend URL-structuurtekens bewaart zoals : / ? # [ ] @ ! $ & ' ( ) * + , ; = zodat een volledige URL functioneel blijft na codering. Voor internationale tekens en emoji's converteert de tool eerst de tekst naar zijn UTF-8 byterepresentatie en codeert vervolgens elke byte afzonderlijk. Een enkel Unicode-teken zoals het euroteken kan meerdere procentgecodeerde drielingen produceren (%E2%82%AC) omdat UTF-8 variabele-lengte codering van een tot vier bytes per teken gebruikt.

Je resultaten begrijpen

Gebruik de Componentmodus (encodeURIComponent) wanneer u een waarde codeert die na een gelijkteken in een querystring wordt geplaatst. Dit zorgt ervoor dat tekens zoals &, = en # in uw waarde de URL-structuur niet per ongeluk beschadigen. Gebruik de Volledige URL-modus (encodeURI) wanneer u een volledige URL hebt en alleen spaties en niet-ASCII-tekens wilt coderen terwijl de structurele scheidingstekens intact blijven. Als u %25 in uw uitvoer ziet, betekent dit dat het procentteken zelf is gecodeerd, wat doorgaans dubbele codering aangeeft—de invoer was al procentgecodeerd voordat u deze verwerkte. Zulke strings twee keer decoderen herstelt de oorspronkelijke tekst. Dit is een van de meest voorkomende URL-coderingsfouten in webapplicaties en API's. Decodering is nuttig om URL's leesbaar te maken tijdens debugging, serverlogboeken te analyseren of queryparameters met gecodeerde waarden te inspecteren. Internationale domeinnamen (IDN) gebruiken een andere codering genaamd Punycode in plaats van procentcodering, dus domeinnamen met niet-Latijnse tekens vereisen aparte afhandeling. Codeer gebruikersinvoer altijd voordat u deze in URL's invoegt om injectieaanvallen te voorkomen.

Praktische voorbeelden

Zoekqueryparameter: het coderen van 'coffee & tea' in Componentmodus produceert 'coffee%20%26%20tea', waarbij zowel spaties als de ampersand veilig worden ge-escaped zodat de server de letterlijke tekst ontvangt. Formulierinzending: een gebruiker voert 'price=50$' in, dat moet worden gecodeerd als 'price%3D50%24' om te voorkomen dat het gelijkteken als sleutel-waardescheider wordt geinterpreteerd. API-redirect-URL's: bij het doorgeven van een callback-URL als parameter aan een andere URL codeert de Componentmodus de volledige callback inclusief zijn eigen querystring. Meertalige inhoud: het coderen van Japanse tekst produceert UTF-8 bytereeksen als procentdrielingen. Debug-decodering: plak een volledige URL uit serverlogboeken en decodeer deze om de oorspronkelijke query direct te zien voor snelle probleemoplossing.

Tips en Best Practices

Gebruik altijd de Componentmodus bij het coderen van individuele queryparameterwaarden. De Volledige URL-modus laat structuurtekens zoals & en = ongecodeerd, wat uw URL zal beschadigen als die tekens in de data zelf voorkomen in plaats van als scheidingstekens. Vermijd dubbele codering door te controleren of uw invoer al procentgecodeerd is. Als u reeksen zoals %20 of %26 in de invoer ziet, decodeer dan eerst voordat u opnieuw codeert om stapeling te voorkomen (waarbij %20 wordt tot %2520). Bij het programmatisch opbouwen van URL's codeert u elke parameterwaarde apart en stelt u vervolgens de volledige URL samen. Codeer nooit de gehele URL-string in een keer, want dit beschadigt de structuurtekens die schema, host, pad en querycomponenten scheiden. Voor het debuggen van API-aanroepen plakt u de volledige gecodeerde URL in de decoderingsmodus om alle parameterwaarden snel in leesbare vorm te bekijken. Dit is vooral handig bij het oplossen van problemen met webhook-URL's of OAuth-callback-redirects met geneste gecodeerde waarden.

Veelgebruikte URL-coderingen

Bronnen

• RFC 3986 – URI Generieke Syntaxis
• MDN – encodeURIComponent