link URL Encoderen / Decoderen star

Hoe het werkt

Een URL kan veilig maar een klein alfabet bevatten: letters, cijfers en de vier niet-gereserveerde symbolen - _ . ~. Alles daarbuiten wordt herschreven als een %XX-drietal, waarbij XX de hexadecimale waarde van de byte van het teken is — dit is RFC 3986-percentcodering. Tekens die de structuur van een URL bepalen (? # / : @ & =, de "gereserveerde" set) worden ook gecodeerd wanneer ze binnen een waarde voorkomen in plaats van als scheidingsteken, aangezien een letterlijke & binnen een querywaarde anders gelezen zou worden als het begin van de volgende parameter.

Niet-ASCII-tekst wordt byte voor byte gecodeerd, niet teken voor teken: de tool zet uw tekenreeks eerst om naar UTF-8 en codeert vervolgens elke resulterende byte in hex. De Turkse letter "ç" bestaat uit twee UTF-8-bytes (0xC3 0xA7), dus wordt het twee percentblokken, %C3%A7 — niet één code. Een concreet voorbeeld: het coderen van İstanbul çayı & simit levert %C4%B0stanbul%20%C3%A7ay%C4%B1%20%26%20simit op. Merk op dat de spatie %20 wordt, de gereserveerde & verandert in %26, en elke letter met een accent wordt uitgebreid naar zijn eigen meerdere-bytes-reeks.

In de praktijk telt dit onderscheid het meest wanneer u verzoeken met de hand opbouwt: het plakken van een webhook-URL met een queryparameter die iemand u stuurde, het decoderen van een trackingparameter uit een marketing-e-mail, of uitzoeken waarom een API-aanroep mislukt omdat een ongecodeerde & of # in een waarde is geslopen en als scheidingsteken werd gelezen in plaats van als data. Door de waarde eerst te coderen en het resultaat vervolgens in de URL-sjabloon te plaatsen, voorkomt u precies dit soort fouten.

Wat u moet weten

• %20 versus +: RFC 3986-percentcodering gebruikt altijd %20 voor een spatie. De +-conventie hoort bij een andere, oudere standaard — application/x-www-form-urlencoded, gebruikt wanneer een HTML-formulier gegevens verzendt — en geldt alleen binnen dat specifieke bodyformaat, nooit binnen een pad of een correct percentgecodeerde querywaarde. De twee door elkaar halen is een klassieke bron van fouten: een server die formuliercodering verwacht, leest een verdwaalde + in een percentgecodeerde tekenreeks als een letterlijk plusteken, niet als een spatie.
• Codeer één component, niet de hele URL: deze tool is gebouwd voor één enkele querywaarde of padsegment. Het hele adres (inclusief https://) door de encoder halen zou ook de schuine strepen en dubbele punten escapen die het een geldige URL maken, waardoor deze volledig kapot gaat.
• Dezelfde engine als uw browser: de tool roept de native encodeURIComponent/decodeURIComponent van de browser aan, zodat de resultaten precies overeenkomen met wat een echte browser of JavaScript fetch-aanroep zou produceren — geen benadering.
• Heen en terug coderen is verliesvrij: het coderen van een tekenreeks en vervolgens het decoderen van het resultaat levert altijd exact de oorspronkelijke bytes op, waardoor u een handmatige coderingsklus eenvoudig kunt controleren door deze terug te decoderen en te vergelijken met de brontekst.
• Er verlaat niets uw browser: coderen en decoderen gebeuren volledig aan de clientzijde, direct, zonder upload.