De bug die me leerde om procent-encoding te respecteren was een OAuth-omleiding die voor precies één klant mislukte WP Adminify had een Google Fonts-integratie die werd geverifieerd via OAuth, en één gebruiker - een hostingreseller die een omgekeerde proxy-opstelling uitvoerde die ik nog steeds niet begrijp 't volledig begreep - bleef maar krijgen redirect_uri_mismatch Fouten. Iedereen was in orde. Ik bracht het grootste deel van twee dagen door met het beschuldigen van zijn serverconfiguratie. Toen keek ik eindelijk naar de eigenlijke URL die zijn browser stuurde, karakter voor karakter, en daar was het: %2520 waar een ruimte had moeten zijn. Zijn proxy codeerde de redirect_uri. Mijn plug-in was evenzo coderen Het Google kreeg een URL waar de spatie twee keer gecodeerd was - %20 verslappen %2520- en wees de hele handdruk af Twee regels code hebben het opgelost Twee dagen om het te vinden.
Dat was' zelfs mijn eerste coderingsramp. jaren eerder bouwde I'd een campagnelink voor een plugin-lancering met een UTM-parameter die een onbewerkt ampersand bevatte - zoiets als utm_campaign=black&friday. Het Analytics-dashboard toonde een mysterieuze campagne genaamd black en een fantoomparameter genaamd friday Dat kwam niets overeen. De ampersand had mijn parameter stil in tweeën gesplitst. Geen fout. Geen waarschuwing. Gewoon stille verkeerde gegevens gedurende elf dagen voordat ik merkte dat de cijfers niet klopten.
Hier' is het ding over URL-codering: it' is een van die problemen die er triviaal uitziet totdat het is't. De regels leven in een specificatie uit 2005 (RFC 3986), leeft de browserrealiteit in een andere specificatie (de WHATWG URL Standard), JavaScript geeft je drie verschillende functies die allemaal iets andere dingen doen, en PHP geeft je er nog twee. Begrijp het verkeerd en je krijgt 't een crash - je krijgt ingekorte parameters, gebroken OAuth-stromen en links die in Chrome werken maar sterven in een e-mailclient.
Dus ik bouwde de encoder/decoder waar ik altijd al in wilde Toolz.dev. Deze handleiding behandelt hoe u deze kunt gebruiken en - nog belangrijker - hoe procentcodering daadwerkelijk werkt, dus de volgende %2520 In je logs duurt het twee minuten in plaats van twee dagen.
tl;dr: Om online te coderen of te decoderen, plakt u uw string in de Toolz.dev URL encoder/decoder, kies een modus en druk op coderen of decoderen. Het verwerkt UTF-8 en emoji correct, en de swap-knop voert de output terug naar de ingang, zodat u dubbelgecodeerde waarden kunt schillen (
%2520) uit elkaar één laag tegelijk. Alles draait aan de clientzijde, dus tokens en sessie-ID's in uw URL's raken nooit een server. Codeer parameter waarden Met de componentmodus; codeer alleen volledige URL's als u weet waarom.
Belangrijkste kenmerken
Codeer en decodeer in één tool
De helft van de tijd moet ik een waarde coderen De andere helft I' Ik staar naar een knoestige URL uit een logbestand en moet deze decoderen tot iets leesbaars De tool doet beide vanuit één invoervak - Encoderen en Decoderen zitten naast elkaar als twee knoppen, dus there' is geen jacht op een aparte pagina Plak een gecodeerde tekenreeks en druk op Decode; typ een ruwe querywaarde en druk op Encode. Het maakt ook retourvluchten netjes: codeer, decodeer en je krijgt je originele tekenreeks terug, byte voor byte. Dat klinkt voor de hand liggend, maar I' heb online tools gebruikt die precies hetzelfde hebben aangegeven als ze willen # 3 en waarop ze willen debuggen.
Component versus volledige URL-coderingsmodi
Dit onderscheid is waar de meeste coderingsbugs worden geboren Componentmodus codeert alles wat is't niet-gereserveerd - inclusief /, ?, &, en =- dat is wat u wilt voor een enkele parameterwaarde Full-URL-modus laat de structurele tekens met rust, zodat de URL nog steeds werkt als een URL, wat u wilt wanneer u ' een compleet adres opruimt Als u het verkeerde gebruikt, wordt uw URL-structuur verbroken of blijven gevaarlijke tekens ongecodeerd. De tool plaatst beide modi één klik uit elkaar in één enkele vervolgkeuzelijst, gelabeld met de JavaScript-functie waarmee elk correspondeert - encodeURIComponent, encodeURI, application/x-www-form-urlencoded. Ik ging heen en weer over die naamgeving. Intentlabels ("codeer een waarde", "codeer een hele URL') zouden beter koud lezen, maar functienamen betekenen het referentiepaneel onder een-op-een op de code die je op het punt staat te schrijven, en dat is het moment waarop de meeste mensen zich daadwerkelijk bevinden. Als je ooit hebt getypt encodeURI Toen je bedoelde encodeURIComponent- Ik heb, meer dan eens - het paneel is er om het te vangen voordat je het verzendt.
Behandelt UTF-8, emoji en internationale karakters
symboliseren café En je krijgt caf%C3%A9- de é correct uitgebreid tot zijn twee UTF-8 bytes. Typ een emoji en je krijgt vier procent gecodeerde bytes. Dit is waar oudere tools en het verouderde JavaScript escape() Functie vallen uit elkaar: ze gaan uit van Latijn-1 of produceren niet-standaard %uXXXX reeksen die geen server kan parseren Als u & #39; bezig bent met het bouwen van URL's met door gebruikers gegenereerde inhoud - namen, zoekopdrachten, stadsnamen in elke taal die is & #39; t Engels - correcte UTF-8-verwerking is & #39; t een leuke Bengaalse tekst, Arabische naaktslakken, Chinese zoektermen: ze coderen allemaal voor geldige RFC 3986-procentreeksen die aan de andere kant identiek decoderen.
Een swap-knop voor dubbel gecodeerde waarden
de %2520 trap - een reeds gecodeerde %20 opnieuw gecodeerd worden - kostte me één keer twee dagen, dus deze is persoonlijk Decoderen is een enkellaagse bewerking: %2520 decodeert naar %20, niet naar een ruimte, omdat %25 is het coderen van %. Met één passage krijg je één laag. de wisselknop (⇄) verplaatst de uitvoer terug naar het invoervak, zodat de volgende doorgang één klik verwijderd is I & # 39; hebben URL's drie lagen diep uitgepakt nadat ze door een proxy, een omleidingsdienst en een e-maillink-wrapper zijn gegaan - swap, decodeer, swap, decodeer, totdat de tekenreeks stopt met veranderen Dat & quot; stopt met wijzigen" moment is het daadwerkelijke signaal waarnaar u & # 39; op zoek bent Wees eerlijk over wat dit is: it& # 39; is een handmatige lus, geen detector Het gereedschap doet & # 39;t vlag %25XX voor jou, en ik ga heen en weer over de vraag of dit zou moeten gebeuren: automatisch decoderen tot stabiel zou handig zijn totdat het stilletjes een waarde vernietigt die legitiem een procentteken bevatte.
Drie modi, één expliciet referentiepaneel
De moduskiezer heeft drie opties - component, volledige URL en formulier-urlencoded - en het paneel eronder spelt precies uit welke tekens die modus ontsnapt, wat het behoudt, en toont een uitgewerkt voorbeeld Ik heb het toegevoegd omdat ik me nooit kon herinneren of encodeURIComponent bladeren ~ alleen (het doet) of dat ! en * Overleven (dat doen ze, wat mensen verrast, aangezien RFC 3986 hen classificeert als sub-delims in plaats van ongereserveerd). In plaats van drie JavaScript-functies te onthouden, kies je de modus op intentie en lees je terug wat het gaat doen. Die referentietekst is het deel dat ik het meest gebruik, en het is het ding dat ik zou willen als ik om 1 uur 's nachts op de pagina zou landen.
100% clientzijde - Niets verlaat uw browser
Denk na over wat' s eigenlijk binnen de URL's die u decodeert: OAuth-autorisatiecodes, tokens voor het opnieuw instellen van wachtwoorden, sessie-ID's, e-mailadressen in afmeldlinks, API-sleutels een raamwerk dat handig in een queryreeks is gestopt Plak deze in een tool aan de serverzijde en ze landen in iemand's toegangslogboeken, gekoppeld aan uw IP, bewaard voor wie weet hoe lang. De Toolz.dev-encoder draait volledig in uw browser - de conversie bestaat uit een paar regels JavaScript die lokaal worden uitgevoerd, en er wordt geen verzoek gedaan met uw gegevens Open DevTools en bekijk het netwerktabblad #39; Geloof me niet. Voor alles wat beveiliging is #3-adjacent, client.
Gratis, geen aanmelding, geen limieten
Geen accountmuur, geen dagelijkse quota-zeur voor een tool die snaartransformatie doet, geen "upgrade naar pro om meer dan 1.000 tekens te decoderen." Ik heb Toolz.dev gebouwd omdat ik het zat was met ad-geslikte hulpprogramma's die een tien seconden durende taak onderbreken met een nieuwsbrief pop-up. Maak er een bladwijzer van, gebruik het vijftig keer per dag, klaar.
Hoe de URL-encoder en decoder te gebruiken
Stap 1: Open de tool en kies je richting
gaan tot Toolz.dev/tools/url-encoder en laat je touwtje in het linkervak vallen. Er zijn twee actieknoppen, Encode en Decodeer, en je kiest er een na het plakken in plaats van eerst een richting in te stellen. Als u begint met iets leesbaars (een zoekopdracht, een omleidings-URL die u op het punt staat in te sluiten), drukt u op coderen. Als je begint met iets vol procenttekens (een logboekinvoer, een referrer-header), druk je op decode. Uitvoer komt in het rechterdeelvenster met een kopieerknop in de koptekst en verwissel en clear zit naast de twee actieknoppen.
Stap 2: Kies component, volledige URL of formuliermodus
coderen van een waarde dat zal in een parameter zitten: een redirect_uri, een zoekterm, alles na een = teken? Gebruik de componentmodus. het codeert /, ?, &, en = Dus uw waarde kan de omringende URL niet doorbreken. coderen van een Volledige url Dat heeft alleen spaties en niet-ASCII-personages nodig? Gebruik de volledige URL-modus, die de structurele karakters behoudt. De derde modus, form-urlencoded, is componentcodering met spaties die zijn geschreven als + in plaats van %20- kies het als u ' zijn hand-building een application/x-www-form-urlencoded Lichaam. Merk op dat de modus ook van invloed is op decodering: in de formuliermodus, + wordt teruggeconverteerd naar een ruimte voor het decoderen; in de andere twee blijft het een letterlijke plus. Bij twijfel: Componentmodus voor stukken, volledige URL-modus voor gehelen.
Stap 3: Lees de output en kijk naar restanten van het percentage
Uitvoer verschijnt in het rechterdeelvenster. Kijk voor decodering of het resultaat nog steeds %XX reeksen - als dit het geval is, is de waarde meer dan eens gecodeerd Druk op Swap om die uitvoer terug naar de invoer te verplaatsen, opnieuw te decoderen en te herhalen totdat de tekenreeks niet meer verandert Als de invoer verkeerd is ingedeeld (een verdwaalde % niet gevolgd door twee hexadecimale cijfers, zoals een letterlijke 100%), krijg je een expliciete fout in plaats van een stille halfdecodeer, wat het gedrag is dat je wilt als je debugging.
Stap 4: Kopieer en verifieer
Druk op de kopieerknop en plak het resultaat waar het thuishoort Voor alles wat belangrijk is - vooral OAuth omleidingen - voer nog een laatste controle van de geestelijke gezondheid uit: plak de gecodeerde waarde terug in de decodeermodus en bevestig deze retourvluchten tot precies waar u mee bent begonnen Dertig seconden verificatie verslaat twee dagen redirect_uri_mismatch.
Percentagecodering, RFC 3986, en waarom spaties %20 of + worden
URL's kunnen maar een beperkte set tekens bevatten. Al het andere moet worden gesmokkeld als bytes met procentuele gecodeerde bytes. Het regelboek is RFC 3986 (2005), en het splitst personages in twee kampen.
Ongereserveerde karakters Nooit codering nodig: de letters A–Z en a–z, cijfers 0–9, en vier symbolen - koppelteken -, periode ., onderstrepen _, en tilde ~. Deze coderen is legaal, maar zinloos.
Gereserveerde tekens hebben structurele taken binnen een URL: : / ? # [ ] @ (de algemene scheidingstekens) en ! $ & ' ( ) * + , ; = (de sub-delimitanten). De dubbele punt scheidt schema van gastheer. Het vraagteken start de queryreeks. De ampersand scheidt parameters. Of een gereserveerd karakter codering nodig heeft, hangt volledig af van waar het verschijnt. a / in het pad is structuur; a / Binnen een redirect_uri-parameterwaarde bevindt zich gegevens, en deze moet worden %2F of de server zal uw URL verkeerd ontleden.
De mechanica: neem het personage, pak zijn UTF-8 byte(s) en schrijf elke byte als % gevolgd door twee hex cijfers ASCII tekens zijn één byte - spatie is %20, ampersand is %26. Maar UTF-8 is een codering met meerdere bytes, dus é is twee bytes: %C3%A9. Een typische emoji is vier bytes - 🚀 codeert als %F0%9F%9A%80. Dit is de reden waarom tools die één personage aannemen, gelijk is aan één byte corrupt iets buiten gewoon Engels.
Nu, het ruimteprobleem - het meest verwarrende ding in URL-codering Per RFC 3986, wordt een spatie %20. Maar HTML-formulierinzendingen gebruiken een andere serialisatie, application/x-www-form-urlencoded, vandaag gedefinieerd in de WhatWg URL-standaard, en dat Formaat codeert spaties als +. Beide zijn correct - in hun eigen context. Wat betekent + In een queryreeks is dubbelzinnig: het kan een letterlijk plusteken zijn (RFC 3986-lezing) of een gecodeerde ruimte (formulier-coderingslezing). Als je ooit een telefoonnummer hebt zien aankomen als 1234 5678 Wanneer iemand stuurde +1234..., je hebt deze bug ontmoet. Mijn advies: altijd uitstoten %20 voor ruimtes en %2B Voor letterlijke plustekens. Niemand die dat misdoet.
JavaScript geeft u drie functies en ze zijn niet uitwisselbaar. Gezien de snaar a=b&c dpiepsel
const s = "a=b&c d";
encodeURIComponent(s); // "a%3Db%26c%20d" — encodes =, &, and space
encodeURI(s); // "a=b&c%20d" — leaves = and & alone
escape(s); // "a%3Db%26c%20d" — deprecated; breaks on Unicode
encodeURIComponent codeert alles behalve niet-gereserveerde tekens (plus !'()*- een oude eigenaardigheid), waardoor het veilig is voor parameterwaarden. encodeURI behoudt gereserveerde tekens zodat een volledige URL functioneel blijft - maar dat betekent ook dat het niet bescherm een & binnen uw gegevens. en escape() is om een goede reden afgestoten: het produceert niet-standaard %uXXXX Sequentie voor niet-Latijn-1 karakters. Gebruik het nooit in nieuwe code.
PHP spiegelt dezelfde splitsing met een twist: urlencode() Produceert vorm-stijl codering (ruimten worden +), terwijl rawurlencode() volgt RFC 3986 (spaties worden %20). Als u URL's bouwt voor iets anders dan een formulierposttekst, rawurlencode() is degene die je wilt. Ik heb WP Administreer code al vroeg met de verkeerde verzonden; eigen WordPress add_query_arg() heeft me vaker gered dan ik zou willen toegeven.
Ten slotte de dubbelcoderingsval. %20 is een ruimte, gecodeerd. coderen dat touwtje Opnieuw en de % zelf wordt %25, je geven %2520. decodeer het een keer en je krijgt %20 terug - nog steeds gecodeerd Dit gebeurt telkens wanneer twee lagen van een systeem elk "helpfully" coderen: uw code plus een proxy, een omleidingsdienst plus een e-maillink-wrapper De regel die dit voorkomt: codeer precies één keer, op het laatst mogelijke moment voordat de waarde in de URL gaat, en codeer nooit iets dat u hebt gedaan ' t decodeer of genereer gewoon raw.
Veelvoorkomende gebruiksgevallen
Queryreeksen bouwen met gebruikersinvoer
Elke keer dat door de gebruiker getypte tekst in een URL terechtkomt - zoekvakken, filters, formulierwaarden doorgegeven via GET - moet deze componentgecodeerd zijn. Een gebruiker die zoekt naar Q&A tips HALD ?q=Q%26A%20tips; niet-gecodeerd, de server ziet een zoekopdracht naar Q en een mysterieparameter A tips. Tijdens de ontwikkeling gebruik ik de URL-encoder Om verwachte waarden te genereren voordat u de code schrijft, heb ik een bekende correcte referentie om mee te testen. Het is ook de snelste manier om te settelen "moet dit karakter worden gecodeerd?" Argumenten in Code Review: Plak het in de componentmodus en kijk. Moderne API's zoals JavaScript's URLSearchParams behandel dit automatisch en u moet ze gebruiken, maar dat moet nog steeds aflezen hun output wanneer iets kapot gaat, en dat is een decodeerbaan.
Debugging UTM en campagnelinks
Marketinglinks coderen mijnenvelden UTM-waarden met spaties, pijpen of ampersands; links die via een URL-verkorter gaan, vervolgens een e-mailservice' s clicktracker, dan een redirect - elke laag een kans voor codering om toegevoegd of verminkt te worden Wanneer een campagne verkeerd blijkt in analyses, is mijn eerste zet altijd hetzelfde: plak de volledige link in de decodeermodus en lees wat de analyseserver daadwerkelijk heeft ontvangen Negen van de tien keer is de dader in seconden zichtbaar - een raw & het splitsen van een parameter, a + dat moest een letterlijk pluspunt zijn, of een %2520 dubbele codering verraden. m'n black&friday Incident zou een oplossing van elf seconden zijn geweest in plaats van een datagat van elf dagen als ik dit op de eerste dag had gedaan.
OAuth redirect_uri en callback-URL's
OAuth is waar coderingsfouten duur worden, omdat providers dat wel doen Exacte stringovereenkomst op omleidings-URI's De omleiding_uri is een volledige URL die is ingebed als parameterwaarde in een andere URL - dus deze moet precies één keer componentgecodeerd zijn. Ondercodeer het en de ? of & Binnenin breekt de URL van de buitenautorisatie. Dubbelcodeer het en de provider vergelijkt https%3A%2F%2F... tegen uw geregistreerde https://... en keert terug redirect_uri_mismatch Met nul verder detail. Wanneer die fout verschijnt, decodeert u de daadwerkelijke autorisatie-URL van de adresbalk van uw browser en vergelijkt u de redirect_uri-personage per teken met de geregistreerde waarde van uw app. Combineer het met de JWT-decoder Voor het inspecteren van de tokens die terugkomen, en je kunt een hele OAuth-stroom debuggen zonder de browser te verlaten.
Gnarly URL's decoderen uit logboeken en verwijzingsheaders
Serverlogboeken en verwijzer-headers zitten vol met soep met procent-gecodeerde soep: %D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82 in een zoekverwijzer, drievoudig gecodeerde paden uit botverkeer, gecodeerde payloads in verdachte verzoeken Decoderen van dit is hoe je erachter komt wat er werkelijk is gebeurd - of die rare 404 een gebruiker was met een Cyrillische zoekopdracht of een script dat ernaar zocht ../../etc/passwd achter drie lagen codering. Dit is ook precies de situatie waarin de privacyhoek het belangrijkst is: log-URL's bevatten routinematig sessietokens en e-mailadressen. Decodeer ze in een client-side tool, niet op een willekeurige server die zijn eigen logboeken bijhoudt. Ik schreef meer over deze workflow in de API-debugger-tools voor debuggen.
API-testen met curl
Je shell en curl vormen een tweede mijnenveld bovenop de URL-codering. & achtergronden een proces in bash, ? triggers glob uitbreiding in zsh - dus een niet geciteerde, niet-gecodeerde URL faalt op verwarrende manieren voordat het zelfs maar het netwerk bereikt Mijn workflow: codeer elke parameterwaarde in de tool, assembleer de URL, wikkel deze in enkele aanhalingstekens, en voer vervolgens curl uit Wanneer een API een 400 retourneert voor een verzoek dat " goed lijkt, & quot; Ik decodeer de exacte URL uit de uitgebreide uitvoer (curl -v) om te zien wat er werkelijk is verzonden - meer dan eens was de bug mijn terminal, niet mijn API. curl's --data-urlencode Vlag-handlingen coderen voor postbody's, maar voor het ophalen van queryreeksen, ben je meestal alleen, en een betrouwbare encoder beats raden.
Links delen met niet-ASCII-tekst
Wikipedia-artikelen in andere talen, Google Maps-links met lokale plaatsnamen, docs-URL's met Bengaalse of Arabische naaktslakken - kopieer er een van uw adresbalk en u kunt beide mooi krijgen Unicode vorm of een muur van %E0%A6%AC-style bytes, afhankelijk van de browser' s stemming Sommige chat-apps en e-mailclients knotten of verminken het ruwe Unicode-formulier Het coderen van de URL voordat u deelt, levert een pure-ASCII-tekenreeks op die elke messenger, mailinglijst en Markdown-renderer I' overleeft; hebben geprobeerd De andere kant op gaan, decodering verandert een onleesbare gedeelde link terug in iets dat een mens kan verifiëren voordat hij klikt - de moeite waard om te doen voordat u iets doorstuurt dat op regelruis lijkt.
Encodeuricomponent vs Encodeur vs Escape(): Welke moet u gebruiken?
Drie functies, één correcte standaard. Hier is de eerlijke vergelijking:
encodeURIComponent() |
encodeURI() |
escape() |
|
|---|---|---|---|
| codeert | Alles behalve A-Z a-z 0-9 - . _ ~ ! ' ( ) * |
alles behalve onvoorwaardelijk + alle gereserveerde tekens (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) |
Alles behalve A-Z a-z 0-9 @ * _ + - . / |
| ruimte wordt | %20 |
%20 |
%20 |
& en = |
gecodeerd (%26, %3D) |
niet gecodeerd | gecodeerd |
| Unicode-afhandeling | Correcte UTF-8 bytes | Correcte UTF-8 bytes | Gebroken - niet-standaard %uXXXX |
| gebruiken voor | Parameterwaarden, padsegmenten, alles binnen een URL | Een volledige URL die u niet wilt herstructureren | helemaal niet |
| positie | Standaard, aanbevolen | standaard, niche | afbraak |
Mijn standpunt, en ik zal sterven op deze heuvel: goed doen encodeURIComponent Voor waarden, bijna altijd. Het mentale model is eenvoudig - als de string gaat binnenzijde een URL (een querywaarde, een padsegment, een redirect_uri), het is een component en het wordt encodeURIComponent. De gevallen waarin encodeURI is echt goed zijn zeldzaam: je hebt een complete, al gestructureerde URL met spaties of niet-ASCII-tekens, en je wilt deze ontsmetten zonder de structuur aan te raken. Dat is misschien 5% van de real-world coderingsoproepen. en escape() zou eenvoudigweg nooit meer mogen verschijnen in code die na ongeveer 2010 is geschreven - de Unicode-uitvoer is & # 39;t geldige procentcodering, en elke moderne linter zal deze toch markeren.
Nog een nuance: encodeURIComponent bladeren ! ' ( ) * niet gecodeerd om historische redenen, ook al vermeldt RFC 3986 ze als gereserveerde subdelimiters Voor OAuth en strikt parserende API's voegen sommige bibliotheken een tweede pass toe om die vijf ook te coderen Als een kieskeurige API uw waarden afwijst, is dat ' een plek om te kijken - en de URL-encoder's Componentmodus laat u precies zien welke tekens zijn geconverteerd, zodat u kunt vergelijken.
Veelgestelde vragen
Wat is URL-codering?
URL-codering (percent-encoding) is het mechanisme voor het weergeven van tekens in een URL die anders onveilig of structureel betekenisvol zouden zijn Elk problematisch teken wordt geconverteerd naar zijn UTF-8-bytes, en elke byte wordt geschreven als een procentteken gevolgd door twee hexadecimale cijfers - een spatie wordt % 20, een ampersand wordt % 26. De regels zijn gedefinieerd in RFC 3986. Het bestaat omdat URL's slechts een beperkte tekenset toestaan, en tekens als ? en & amp; hebben taken te doen binnen de URL-structuur.
Waarom veranderen spaties soms in %20 en + andere keren?
Twee verschillende specs RFC 3986, die URL's zelf regelt, codeert een spatie als % 20 De applicatie/x-www-form-urlencoded formaat dat wordt gebruikt door HTML-formulierinzendingen, gedefinieerd in de WHATWG URL Standard, codeert een spatie als +. Beide zijn geldig in hun eigen context, daarom is + in een queryreeks dubbelzinnig. De veilige praktijk: produceer altijd % 20 voor spaties en % 2B voor letterlijke plus-tekens - elke parser verwerkt deze correct.
Wat is het verschil tussen EncodeURI en EncodeuriComponent?
encodeURIComponent codeert bijna alles, inclusief /, ?, & amp;, en =, waardoor het veilig is voor individuele waarden die in een URL zijn geplaatst. encodeURI bewaart die gereserveerde tekens zodat een volledige URL zijn structuur behoudt Gebruik encodeURIComponent voor parameterwaarden en padsegmenten - wat bijna elk geval in de echte wereld is - en codeerURI alleen bij het opschonen van een volledige URL zonder deze te herstructureren. EncodeURI gebruiken op een waarde die & amp; zal in stilte uw queryreeks verbreken.
Hoe repareer ik een dubbel gecodeerde URL?
Dubbele codering vindt plaats wanneer een reeds gecodeerde tekenreeks opnieuw wordt gecodeerd - % 20 wordt % 2520 omdat het % zelf verandert in % 25 Om het te repareren, decodeert u de tekenreeks herhaaldelijk totdat er geen % XX-reeksen meer over zijn en de uitvoer stopt met veranderen. Zoek vervolgens welke laag van uw systeem twee keer is gecodeerd - meestal uw code plus een proxy, omleidingsservice of e-maillink-wrapper - en verwijder een van de coderingsstappen. De regel: codeer precies één keer, op het laatste moment voordat de waarde de URL binnenkomt.
Is het veilig om URL's te decoderen in een online tool?
Alleen als de tool client-side draait URL's bevatten vaak OAuth-codes, tokens voor wachtwoordreset, sessie-ID's en e-mailadressen Een tool aan de serverzijde ontvangt dat allemaal en mag het voor onbepaalde tijd in toegangslogboeken bewaren De Toolz.dev URL Encoder/Decoder voert alle conversie in uw browser uit met JavaScript - er worden nergens gegevens verzonden, die u kunt verifiëren in uw browser's netwerktabblad Voor alles wat inloggegevens of tokens bevat, moet verwerking aan de clientzijde niet onderhandelbaar zijn.
Moet ik de hele URL coderen of alleen de parameters?
Alleen de data-onderdelen - individuele parameterwaarden en, af en toe, padsegmenten De structurele tekens van de URL zelf (de://na het schema, de ? het starten van de query, de & amp; tussen parameters) moeten ongecodeerd blijven of de URL werkt niet meer Elke waarde afzonderlijk coderen met component-stijl codering, en vervolgens de URL eromheen samenstellen Het coderen van een volledige URL end-to-end is alleen correct wanneer die URL zelf een waarde binnen een andere URL wordt, zoals een OAuth redirect_uri.
Kan URL-codering emoji en niet-Engelse tekens aan?
Ja - moderne procent-encoding werkt op UTF-8 bytes, dus elk Unicode-teken werkt Een teken van twee bytes zoals é wordt % C3% A9, en een emoji van vier bytes wordt vier procent-reeksen, zoals % F0% 9F% 9A% 80. Problemen doen zich alleen voor met oudere tools of JavaScript' s verouderde escape () functie, die coderingen van één byte aannemen en ongeldige uitvoer produceren De Toolz.dev encoder verwerkt volledige UTF-8 correct in beide richtingen.
Waarom breekt mijn URL als een parameter een ampersand bevat?
Omdat & amp; de scheidingsteken tussen parameters is Als een waarde een onbewerkt ampersand bevat - zeg utm_campaign=black& vrijdag - parseert de server het als een parameter met de naam utm_campaign met waarde zwart, plus een tweede parameter met de naam vrijdag Er wordt geen fout gemaakt; uw gegevens zijn gewoon stilzwijgend verkeerd Coderen van de ampersand als % 26 binnen de waarde en de parameter komt intact Dit is een van de meest voorkomende en minst zichtbare URL-bugs.
Wat betekent %2f in een URL?
% 2F is de procentgecodeerde voorwaartse schuine streep U ' zal het zien wanneer een waarde die toevallig een schuine streep bevat - een bestandspad, een datum als 07/07, of een geneste URL - correct gecodeerd is voordat deze in een queryparameter of padsegment wordt geplaatst Wees je ervan bewust dat sommige servers en proxy's (Apache, oudere Tomcat-versies, verschillende API-gateways) % 2F in het pad om veiligheidsredenen weigeren of in stilte decoderen, dus als een verzoek met een gecodeerde schuine streep een 404 retourneert, is de configuratie aan de serverzijde meestal de boosdoener, niet jouw codering.
Hoe kan ik url coderen in Python, PHP of op de opdrachtregel?
python: urlib.parse.quote() voor padsegmenten en quote_plus() voor querywaarden in formulierstijl. PHP: RawurlenCode() produceert RFC 3986-uitvoer met %20 voor spaties, terwijl UrlenCode() vorm-achtige output produceert met +. Opdrachtregel: JQ -RR @URI of CURL's --data-urlencode vlag. Elk van deze komt overeen met het gedrag van deze componentstijl van deze tool, zodat u de codering hier kunt prototyperen en verifiëren dat uw code byte-identieke uitvoer produceert.
inpakken
URL-codering is een kleine vaardigheid met een buitensporige uitbetaling. Zodra je kunt lezen %C3%A9 Als é en plek %2520 als een dubbel-coderende geur, een hele categorie van & quot; het werkt op mijn machine" bugs - gebroken OAuth stromen, fantoom UTM campagnes, API's die perfect redelijk uitziende verzoeken afwijzen - verandert van mysterieus naar mechanisch De regels passen op een indexkaart: niet-gereserveerde tekens passeren, al het andere wordt UTF-8 bytes als % HH, coderen waarden niet structureren, en precies één keer coderen.
houden URL-encoder/decoder een bladwijzer naast zijn broers en zussen - de Base64-converter Voor het andere coderingsschema dat je zult ontmoeten in elke auth-header (ik heb een volledige Base64-coderingsgids wanneer u welke moet gebruiken), de HTML-entiteiten encoder/decoder voor de derde coderingslaag die webinhoud graag bovenop stapelt (de HTML-entiteitsgids Dekt de dubbelontsnappende versie van dezelfde val waarmee ik sloeg %2520), en de JSON-formatter Voor wat de gedecodeerde URL-punten ook zijn.
En als u een bredere browsergebaseerde debugging-kit aan het assembleren bent, Handleiding voor coderingshulpmiddelen loopt door hoe deze tools in een echte workflow in elkaar passen Alles op Toolz.dev draait client-side, kost niets, en doet één klus goed Dat' is de hele pitch - dezelfde die ik wou dat iemand mij had gemaakt voordat ik twee dagen op een enkele misplaatste % 25.
