URL-encoder

De URL-encoder is een gratis tool die een tekenreeks omzet naar de formuliercodering die wordt gebruikt voor URL-queryparameters en andere tekstgegevens op het web.

Wat is URL-codering en waarom wordt die gebruikt?

Bij URL-codering worden tekens met een speciale betekenis in een URL vervangen door een procentteken met daarop hexadecimale cijfers. Zo kan tekst worden verwerkt door systemen die slechts een beperkte tekenset accepteren.

Een ampersand scheidt bijvoorbeeld queryparameters. Staat een ampersand in de waarde zelf, dan moet deze worden gecodeerd als %26. Ook spaties vereisen een speciale behandeling. Deze tool gebruikt de PHP-functie urlencode, die een spatie omzet in een plusteken.

Voor: tea and cake

Na: tea+and+cake

Je kunt URL-gecodeerde tekst onder meer tegenkomen in:

• querystrings die via webformulieren worden verzonden;
• data-URI's met tekst die niet letterlijk kan worden opgenomen;
• links in e-mailberichten;
• URL-waarden die in JSON-payloads zijn opgeslagen;
• redirect- en callbackparameters van webapplicaties;
• URL's die bij geïnternationaliseerde domeinen horen, al kan voor de domeinnaam zelf Punycode nodig zijn in plaats van procentcodering.

URL-codering is geen versleuteling en houdt gegevens niet geheim. Iedereen die een procentgecodeerde URL-waarde kan zien, kan deze ook decoderen.

Hoe gebruik ik de URL-encoder?

Voer de tekenreeks in die je wilt coderen, start de tool en bekijk de omgezette waarde in het resultaatveld URL-gecodeerd. Codeer alleen de waarde zelf, dus niet de aanhalingstekens eromheen of eventuele toelichtende tekst.

De verwerking vindt plaats op de server. Je invoer wordt via HTTPS naar de server verzonden en niet opgeslagen. Voer desondanks geen wachtwoorden, sessietokens of persoonlijke privégegevens in URL's in. Webadressen kunnen namelijk terechtkomen in de browsergeschiedenis, analysesystemen en serverlogboeken.

Gebruik de URL-decoder om de bewerking ongedaan te maken. Bij correcte decodering moet de uitkomst overeenkomen met de oorspronkelijke tekst, mits in beide richtingen dezelfde tekencodering en regels voor formuliercodering worden gebruikt.

Moet ik de hele URL coderen of alleen de parameterwaarde?

Codeer normaal gesproken elke parameterwaarde afzonderlijk, niet de volledige URL. Als je een heel adres codeert, worden ook structurele tekens vervangen, zoals de dubbele punt, schuine strepen, het vraagteken en het isgelijkteken.

Stel dat de zoekwaarde green tea & coffee is. De gecodeerde vorm daarvan is green+tea+%26+coffee. Deze kun je achter een parameternaam plaatsen. Als je het volledige adres codeert, worden de scheidingstekens onherkenbaar die een browser nodig heeft om het schema, de host, het pad en de querystring te onderscheiden.

Omdat deze tool urlencode gebruikt, is hij goed geschikt voor queryparameters volgens de formuliercodering van HTML. Sommige API's en padsegmenten volgen in plaats daarvan de conventies van RFC 3986. Daarbij wordt een spatie geschreven als %20 en niet als +. Controleer of het ontvangende systeem formuliercodering met + verwacht, of %20 volgens RFC 3986.

Voorbeelden van URL-codering

ASCII-letters en cijfers blijven leesbaar. Spaties worden plustekens, terwijl gereserveerde leestekens en niet-ASCII-tekst als gecodeerde bytes worden weergegeven.

• hello world wordt hello+world.
• tea & cake wordt tea+%26+cake.
• email=test@example.com wordt email%3Dtest%40example.com.
• 100% ready wordt 100%25+ready.
• café wordt caf%C3%A9 wanneer de brontekst UTF-8 gebruikt.

Letters met accenten en niet-Latijnse schriften worden eerst met een tekencodering omgezet in bytes. Op het web is dat meestal UTF-8. Elke byte buiten de toegestane set krijgt vervolgens een eigen procentcode. Eén zichtbaar teken kan daardoor meerdere groepen opleveren die met % beginnen.

Cijfers vereisen geen speciale behandeling. Lege invoer levert geen gecodeerde inhoud op. Zeer lange invoer kan aanzienlijk langer worden, omdat elke gecodeerde byte drie tekens inneemt.

Waarom mislukt URL-decodering of krijg ik onleesbare tekst?

Decodering mislukt meestal doordat de invoer met andere regels is gecodeerd, meer dan één keer is gecodeerd of geen tekst in de verwachte tekenset bevat.

• Andere verwerking van spaties. Een formulierdecoder behandelt + als een spatie, terwijl een strikte procentdecoder het teken als plusteken kan laten staan.
• Dubbele codering. Het procentteken in %26 kan zelf worden omgezet in %25, waardoor %2526 ontstaat. Na één decoderingsstap krijg je dan %26 terug in plaats van de oorspronkelijke ampersand.
• Verkeerde tekencodering. Als UTF-8-bytes als een andere tekenset worden gedecodeerd, kunnen vervangende symbolen of verminkte letters verschijnen.
• Binaire gegevens in plaats van tekst. De gedecodeerde bytes kunnen een afbeelding, archief of ander bestand vormen. Als je deze als tekst weergeeft, ontstaat onleesbare inhoud.
• Verkeerde indeling of verkeerd alfabet. URL-veilige Base64, standaard-Base64 en procentcodering zijn verschillende indelingen. Als je een URL-decoder op Base64-tekst toepast, krijg je niet de bedoelde waarde terug.

URL-codering gebruikt geen opvullingstekens. Meldt een decoder dat opvulling ontbreekt, dan is de invoer waarschijnlijk Base64 of een andere indeling met opvulling, en geen procentgecodeerde tekst.

Veelgestelde vragen

Zijn procentcodes met hoofdletters en kleine letters hetzelfde?

Ja. Hexadecimale letters in procentcodes zijn niet hoofdlettergevoelig. %2F en %2f staan dus allebei voor een schuine streep. Voor een consistente notatie worden hexadecimale cijfers in hoofdletters aanbevolen.

Kan ik een internationale domeinnaam omzetten met URL-codering?

Nee. Voor domeinlabels, zoals een naam met é, is normaal gesproken verwerking als Internationalised Domain Name nodig, met een ASCII-vorm in Punycode die begint met xn--. Procentcodering is bedoeld voor andere onderdelen van een URL en is geen vervanging voor die omzetting.

Wat gebeurt er met regeleinden en tabs?

Tabs en bytes voor regeleinden worden procentgecodeerd, omdat ze niet letterlijk in een gangbare URL-waarde kunnen staan. Een tab wordt meestal weergegeven als %09. De codering van regeleinden hangt ervan af of de bron LF- of CRLF-tekens gebruikt.

Waarom werkt een gecodeerde URL niet als ik die in een applicatie plak?

De applicatie verwacht mogelijk een ongecodeerde waarde en codeert deze zelf, waardoor dubbele codering ontstaat. Ook kan de URL worden geweigerd vanwege een limiet voor de totale lengte, of omdat een gereserveerd teken in een structureel deel van het adres is gecodeerd. Controleer vóór het coderen om welk afzonderlijk onderdeel de applicatie vraagt.

Kan ik gecodeerde querystringgegevens veilig delen?

Nee. Procentcodering van URL's verandert alleen de weergave. Browsers en ontwikkelaarstools kunnen de oorspronkelijke waarde zichtbaar maken. Controleer voordat je een link deelt de queryparameters op e-mailadressen, accountreferenties, toegangstokens en andere gegevens die niet openbaar mogen worden.