Ik verloor een keer een uur aan een query string Een webhook van derden was aan het versturen filter[status]=open&filter[assignee]=me, mijn begeleider was aan het lezen filter als een platte string, en ik kon niet achterhalen waarom elk verzoek ongefilterd doorkwam Op het moment dat ik de onbewerkte URL in een query string parser plakte en zag dat het oploste naar een genest object, lag de bug voor de hand: de afzender gebruikte haakjesnotatie en mijn parser niet Deze gids behandelt hoe ik de Query String Parser op Toolz.dev, wat de lastige delen van query strings eigenlijk zijn, en waarom dezelfde sleutel gecodeerd twee verschillende manieren kan stilletjes een integratie te breken.
tl;dr: Een query string is het deel van een URL na het vraagteken dat parameters als sleutel-waarde paren draagt Een query string parser zet dat om in gestructureerde JSON, het decoderen van procent-codering en het verwerken van herhaalde sleutels en beugel arrays, en kan een correct gecodeerde query string terug bouwen van JSON De Query String Parser doet beide richtingen in uw browser, zodat u een rommelige URL kunt inspecteren of een schone kunt samenstellen zonder de pagina te verlaten.
Wat is een query string?
Een query string is het gedeelte van een URL dat begint na het eerste vraagteken en eindigt bij het fragment, het gedeelte na een hash Het draagt parameters als key=value paren verbonden door ampersands, dus ?q=json&page=2 geeft twee parameters door Servers en clientcode lezen die om een zoekopdracht te filteren, een campagne te volgen, een lijst te pagineren of status tussen pagina's te dragen De generieke regels voor wat wel en niet legaal is in dat onderdeel komen van RFC 3986, de URI-standaard en de specifieke regels die browsers volgen voor parameters in formulierstijl zijn afkomstig van de WhatWg URL-standaard.
Het addertje onder het gras is dat RFC 3986 de syntaxis van de querycomponent definieert, maar niet de betekenis ervan. Er staat welke tekens zijn toegestaan en hoe ze procentgecodeerd moeten zijn, maar het zegt niets over hoe key=value paren wijzen naar een datastructuur Die interpretatie is overgenomen van het indienen van HTML-formulieren, en verschillende platforms hebben deze op incompatibele manieren uitgebreid. Dit is de reden waarom dezelfde queryreeks iets andere dingen kan betekenen voor een PHP-back-end, een Rails-controller en een JavaScript-front-end, en waarom een parser zijn conventies expliciet moet maken.
Elke toets en waarde in een query string is URL-gecodeerd zodat gereserveerde tekens overleven Een spatie wordt %20 of een plusteken, een ampersand binnen een waarde wordt %26 het wordt dus niet aangezien voor een scheidingsteken, en een schuine streep wordt %2F. Parseren betekent het splitsen van de paren en vervolgens het decoderen van elke zijde, en bouwmiddelen die elke zijde coderen en de paren verbinden Verkeerd coderen in beide richtingen en waarden stilletjes corrumperen.
Wat doet een query string parser eigenlijk?
Een parser neemt een URL of een kale query string en maakt er gestructureerde, leesbare data van, Onderweg ontdoet het alles tot en met het vraagteken, negeert het fragment na de hash, splitst de paren, decodeert elke sleutel en waarde, en beslist hoe herhaalde sleutels en toetsen tussen haakjes worden weergegeven De uitvoer is een JSON object dat je kunt lezen en kopiëren, plus een platte tabel van elk gedecodeerd paar zodat duplicaten en lege waarden voor de hand liggen.
Op Toolz.dev draait de tool in twee richtingen In de parse-modus plak je een volledige URL of alleen de query string en krijg je de JSON en de parametertabel In de build-modus plak je een JSON object en krijg je een correct gecodeerde query string, met een keuze hoe arrays worden weergegeven Laad het sample en je kunt een echte URL bekijken met een fragment, een herhaalde-stijl array, en een gecodeerde space resolve in clean JSON, en dan opnieuw opbouwen.
De reden om een dedicated parser te gebruiken in plaats van naar de URL te kijken, is dat queryreeksen hun structuur verbergen Een lange URL met gecodeerde tekens, herhaalde sleutels en haakjesnotatie is bijna onmogelijk om correct te lezen door deze te scannen, en de onderdelen die het moeilijkst te lezen zijn, de codering en de duplicaten, zijn precies de onderdelen die bugs veroorzaken. Als je de gedecodeerde tabel naast de JSON ziet, wordt het giswerk verwijderd.
Hoe worden herhaalde sleutels afgehandeld?
Dezelfde sleutel kan legaal meer dan één keer in een queryreeks verschijnen, zoals in tags=react&tags=laravel, en er is niet één correcte manier om dat te interpreteren, wat de wortel is van veel verwarring Verschillende systemen lossen duplicaten anders op, dus een parser moet je laten kiezen.
De meest gebruikelijke conventie, en de standaard in de Toolz.dev tool, is het verzamelen van herhaalde sleutels in een array, dus tags=react&tags=laravel HALD {"tags":["react","laravel"]}. Dit komt overeen met hoe de browser' is eigen URLSearchParams.getAll legt de waarden bloot en hoe de meeste moderne back-ends zich gedragen Maar sommige frameworks houden alleen de eerste gebeurtenis en sommige houden alleen de laatste, dus de tool biedt ook keep-first en keep-last opties Wanneer u een integratie foutopsporing doet, komt u overeen met de parser' s gedrag met het systeem dat de URL produceerde of verbruikt, is wat de JSON betekenisvol maakt.
Deze dubbelzinnigheid is niet academisch Een klassiek beveiligings - en correctheidsprobleem genaamd HTTP parameter vervuiling bestaat juist omdat twee systemen in een verzoekpad kunnen oplossen id=1&id=2 anders, één zien 1 en de andere ziende 2. Het expliciet kunnen zien hoe een bepaalde parser duplicaten oplost, is de snelste manier om over die klasse bugs te redeneren.
Wat betekenen haakjes als tags [] of filter [kleur]?
Beugelnotatie is een conventie voor het coderen van arrays en geneste objecten binnen een platte queryreeks, en het is waar parsers het het meest oneens zijn. Een achterste lege haak markeert een array, dus tags[]=react&tags[]=laravel bouwt {"tags":["react","laravel"]}. Een benoemde haak markeert een genest object, dus filter[color]=red&filter[size]=l bouwt {"filter":{"color":"red","size":"l"}}. Beugels kunnen nestelen, dus a[b][c]=1 bouwt {"a":{"b":{"c":"1"}}}.
Deze syntaxis komt voort uit de manier waarop PHP en Ruby on Rails formuliergegevens serialiseren, en veel JavaScript-bibliotheken zoals qs volg het Het maakt geen deel uit van een kern URL standaard, dat is precies waarom een plain URLSearchParams in de browser zal het niet worden uitgebreid, waardoor u een letterlijke sleutel krijgt van tags[] in plaats van een array De Toolz.dev parser begrijpt de conventie en breidt deze uit naar de overeenkomende structuur, en het laat je dat gedrag uitschakelen wanneer je in plaats daarvan de letterlijke toetsen wilt.
Hier ziet u hoe de belangrijkste conventies op één lijn liggen, zowel bij het parseren als bij het bouwen van
| Array-stijl | Gecodeerd als | Parses to | Gemeenschappelijk in |
|---|---|---|---|
| Herhaalde sleutel | tags=a&tags=b |
["a","b"] |
Browsers, de meeste back-ends |
| Lege beugel | tags[]=a&tags[]=b |
["a","b"] |
PHP, Rails, qs-bibliotheek |
| Geïndexeerde schijf | tags[0]=a&tags[1]=b |
["a","b"] |
qs-bibliotheek, bestelde gegevens |
| Komma-verbonden | tags=a,b |
eén tekenreeks om te splitsen | Sommige API's, compacte URL's |
Wanneer u een queryreeks met het gereedschap bouwt, kiest u welke van deze u wilt uitzenden, zodat de uitvoer overeenkomt met wat het ontvangende systeem verwacht. Wanneer u parseert, detecteert het gereedschap herhaalde toetsen en haakjesnotatie voor u, en met komma's verbonden waarden blijven als een enkele tekenreeks, omdat alleen u weet of een komma een scheidingsteken of een deel van de gegevens is.
Waarom veranderen plusborden in ruimtes?
In de queryreeks van een URL wordt een letterlijke ruimte heel vaak gecodeerd als een plusteken in plaats van %20. Dit is een regel die is geërfd van de application/x-www-form-urlencoded formaat dat HTML-formulieren gebruiken, en de WhatWg URL-standaard codificeert het: bij het parseren van formuliergecodeerde gegevens, a + wordt gedecodeerd naar een spatie Dus q=json+parser moet ontleden json parser, en de Toolz.dev tool doet dit standaard.
De subtiliteit is dat deze regel van toepassing is op de querycomponent, niet op het pad. A + in een padsegment is een letterlijke plus. En af en toe bevatten uw gegevens echt plustekens die bewaard moeten blijven, zoals een telefoonnummer of een zoekopdracht C++. Voor die gevallen heeft de tool een schakelaar om plus-als-ruimte uit te schakelen, dus de plus overleeft de retourvlucht. Dit is het soort detail dat voor algemene doeleinden geldt URL-encoder zal niet voor u beslissen, omdat het niet weet of het naar een vraag of een pad kijkt.
Dit goed krijgen is ook van belang bij het bouwen. Wanneer het gereedschap een waarde codeert, codeert het procentueel gereserveerde tekens en gebruikt het standaard een plus voor spaties in de vormgecodeerde stijl, dus de tekenreeks die het produceert is er een die browsers en achtereinden decoderen zoals u het bedoeld had.
Hoe verschilt dit van een volledige URL-parser?
Een query string parser en een volledige URL parser overlappen elkaar maar beantwoorden verschillende vragen, en het gebruik van de juiste slaat een stap op Een URL parser breekt een volledige link in zijn componenten, het schema, host, poort, pad, query, en fragment, en is wat je wilt wanneer je debugging waar een verzoek gaat of waarom een redirect of een CORS check zich vreemd gedraagt Een query string parser richt zich alleen op de query en verandert deze in gestructureerde, bewerkbare JSON, inclusief arrays en geneste sleutels, en kan de query terug bouwen.
de URL-parser op Toolz.dev is de tool voor anatomie: geef het een link en het toont u de host versus oorsprong onderscheid, de standaard poort, en de stukken van het pad De query string parser is de tool voor het werken met parameters: geef het dezelfde link en het geeft u de parameters als JSON die u kunt bewerken, en dan opnieuw een query string van uw bewerkingen, In de praktijk gebruik ik ze samen, de URL parser om een link te begrijpen en de query string parser om de parameters te wijzigen, en als ik bezig met het samenstellen van een campagne link reach voor de UTM-bouwer in plaats daarvan is dit een query string builder gespecialiseerd voor analytische tags.
Wanneer grijp ik hier eigenlijk naar?
Het eerlijke antwoord is wanneer een URL meer doet dan naar een pagina verwijzen Ik gebruik het om webhooks en OAuth-omleidingen te debuggen, waarbij de parameters de volledige payload dragen en één verkeerd gecodeerde waarde de stroom verbreekt Ik gebruik het om de trackingparameters op een marketinglink te lezen, zodat ik precies kan zien wat een campagne doorstaat Ik gebruik het om een query string die een collega in een chat geplakt heeft om te zetten in JSON Ik kan het in een testopstelling laten vallen, en om het omgekeerde te doen, een klein object in een query string veranderen voor een snel handmatig verzoek.
Een uitgewerkt voorbeeld maakt de uitbetaling concreet Een OAuth-provider verwijst terug naar uw app met zoiets als ?code=abc123&state=xyz789&scope=read%20write&error=. Geplakt in de parser, die oplost in een schoon object: code en state als hun letterlijke waarden, scope gedecodeerd naar read write omdat %20 is een ruimte, en error als een lege string in plaats van een ontbrekende sleutel, die u vertelt dat de provider de parameter heeft verzonden maar deze leeg heeft gelaten. Als u dat van de onbewerkte URL per oog leest, mist u waarschijnlijk de gecodeerde ruimte scope en lees het lege verkeerd error, en beide zijn precies de details die beslissen of uw terugbelhandler correct vertakt. Als u de gedecodeerde tabel ziet, wordt de dubbelzinnigheid verwijderd, en als u vervolgens het verzoek moet reproduceren, verandert de bouwmodus uw bewerkte object in één stap terug in een geldige terugbel-URL.
Omdat zoveel van dat werk URL's omvat die tokens, ondertekende waarden en tracking-ID's bevatten, en dit doen in een tool die volledig in uw browser draait, doet ertoe. Niets dat u plakt, wordt verzonden, gelogd of opgeslagen, en de tool blijft werken met het netwerk uit, zodat u veilig een ondertekende terugbel-URL kunt inspecteren vanaf de productie in plaats van een opgeschoonde kopie. Ik pleit er breder voor om dit soort werkclient-kant in de Gegevensprivacy in online tools gids, en deze parser bevindt zich naast de andere link- en teksthulpprogramma's die ik in de versie heb beschreven Webontwikkelaar Toolkit. Als een deel van uw werk het omzetten van rommelige invoer in schone slugs en identificatiegegevens is, zal de Slug Generator is een natuurlijke metgezel voor de uitvoerzijde van URL-werk.
Veelgestelde vragen
Wat is een query string?
Een query string is het deel van een URL na het vraagteken dat parameters draagt als sleutel-waarde paren die door ampersands worden samengevoegd, zoals?q=json& page=2. Servers en client code lezen het om resultaten te filteren, campagnes te volgen, of status door te geven Elke sleutel en waarde is URL-gecodeerd zodat spaties en gereserveerde tekens overleven, en het fragment na een hash maakt er geen deel van uit.
Hoe worden herhaalde sleutels behandeld bij het parseren?
Standaard wordt een sleutel die meer dan één keer verschijnt gecombineerd tot een array, dus tags=react&tags=laravel parseert naar {"tags":["react","laravel"]}. U kunt overschakelen om alleen de eerste waarde of alleen de laatste waarde te behouden, omdat verschillende back-ends duplicaten anders oplossen en u wilt dat de JSON overeenkomt met het systeem waarop u zich richt.
Wat betekenen haakjes als tags [] of filter [kleur]?
Beugelnotatie codeert arrays en geneste objecten binnen een platte queryreeks. tags[]=react&tags[]=laravel bouwt een array op, en filter[color]=red&filter[size]=l bouwt het geneste object {"filter":{"color":"red","size":"l"}}. Het is gebruikelijk in PHP-, Rails- en formulierbibliotheken, dus breidt de parser het uit naar de matchingstructuur, en u kunt dat uitschakelen om de letterlijke sleutels te behouden.
Waarom wordt een plusteken een spatie?
In de query string van een URL wordt een letterlijke spatie vaak gecodeerd als een plusteken, een regel die wordt overgenomen van HTML formulierinzending, dus de parser converteert + standaard terug naar een spatie Als uw gegevens echte plus tekens bevatten die moeten worden bewaard, zoals C++ of een telefoonnummer, zet de plus-als-spatie optie uit en de plus blijft behouden.
Kan ik een query string bouwen van JSON?
Ja. Schakel over naar de bouwmodus en plak een JSON-object van sleutel-waardeparen. Het gereedschapspercentage codeert elke sleutel en waarde en voegt deze samen met ampersands, en u kunt kiezen hoe arrays worden gecodeerd: herhaalde toetsen, lege haakjes, geïndexeerde haakjes of een door komma's gescheiden lijst, zodat de uitvoer overeenkomt met wat het ontvangende systeem verwacht.
Wat is het verschil tussen deze en een volledige URL-parser?
Een volledige URL-parser breekt een hele URL in schema, host, poort, pad, query en fragment Een query string parser richt zich op de query alleen, maakt er gestructureerde bewerkbare JSON van inclusief arrays en geneste sleutels, en kan de query terug bouwen Gebruik de URL parser om een link te inspecteren, en deze tool om de parameters ervan te lezen of te wijzigen.
Verwerkt het een volledige URL of alleen het querygedeelte?
Beide Als je een volledige URL plakt, laat de parser alles vallen tot en met het vraagteken en negeert het fragment na de hash, zodat je alleen de parameters krijgt Als je een kale query string plakt zonder vraagteken, wordt deze geparseerd zoals-is, wat handig is wanneer je alleen de parameters hebt gekopieerd.
Wordt mijn URL ergens naartoe gestuurd?
Nee. Parseren, decoderen en coderen worden allemaal uitgevoerd als JavaScript in uw browser, dus er wordt niets verzonden, gelogd of opgeslagen. U kunt het bevestigen door naar het netwerktabblad te kijken terwijl u een URL parseert, of door de verbinding met internet te verbreken, omdat de tool offline blijft werken zodra de pagina is geladen.
Inspecteer of monteer parameters met de gratis Query String Parser. Het parseert een URL naar JSON en bouwt een queryreeks terug, waarbij herhaalde sleutels, haakjesarrays en codering volledig in uw browser worden verwerkt.
