Ik verloor een keer een middag door een URL die er goed uitzag. Een OAuth-callback bleef maar falen, de omleidings-URI "matched" degene die bij de provider was geregistreerd, en ik kon niet zien waarom de handdruk brak. Het antwoord, toen ik het ding eindelijk in een parser plakte, was een sleepboot op het pad op de ene plaats en geen in de andere, plus een state parameter die dubbel gecodeerd was dus %20 waren geworden %2520. Voor het menselijk oog waren de twee URL's identiek. Voor de OAuth-server waren het verschillende strings, en het was juist om de mismatch te verwerpen.
Dat is het probleem met URL's: ze zijn compact, ze zijn gemakkelijk verkeerd te lezen, en de details die dingen breken - een gecodeerde slash, een verdwaalde poort, een herhaalde query-sleutel, een fragment waar je een pad verwachtte - zijn precies degene die zich verstoppen in een muur van personages Ik bouw [Toolz.dev] (/, en ik besteed genoeg tijd aan het staren naar query strings terwijl ik debug dat ik een URL-parser om voor mij te staren. Plak een link, zorg dat elk onderdeel gelabeld wordt en elke queryparameter gedecodeerd in een tabel. In deze handleiding wordt uitgelegd wat die componenten zijn, waarom de verschillen ertoe doen en hoe ze te gebruiken.
tl;dr: Een URL is gemaakt van een schema (
https), optionele inloggegevens (user:pass@), een gastheer (example.com) met een optionele poort, een pad (/blog/post), een queryreeks (?id=42), en een fragment (#section). de URL-parser Splitst een link in die delen met behulp van de eigen WhatWG-URL-engine van de browser, decodeert de query in een geordende sleutelwaardetabel (herhaalde sleutels worden gescheiden gehouden), toont de effectieve poort voor het schema en gaat ervan uit dathttps://Als u een kaal domein plakt. Het draait volledig in uw browser, dus links met tokens blijven privé.
Wat zijn de onderdelen van een URL?
Elke URL volgt dezelfde grammatica, gedefinieerd door de WHATWG URL Standard - de specificatiebrowsers daadwerkelijk implementeren Zodra u de onderdelen een naam kunt geven, worden de meeste URL-bugs duidelijk Hier is de volledige anatomie, met behulp van een opzettelijk druk voorbeeld:
https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘ └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme user pass hostname port path query fragment
dat afbreken:
| samenstellend | Voorbeeldwaarde | Wat is het |
|---|---|---|
| gemeen spel | https |
het protocol. Bepaalt de standaardpoort en hoe het verzoek wordt gedaan. |
| gebruikersnaam | john |
optionele referentie, voordat de @. |
| consigne | s3cret |
optioneel certificaat, na de : in de gebruikersinfo. |
| hostnaam | shop.example.co.uk |
Het domein of het IP-adres, zonder poort. |
| haven | 8443 |
optioneel. Valt terug naar het standaardschema wanneer het wordt weggelaten. |
| waard | shop.example.co.uk:8443 |
Hostname plus poort, wanneer een poort aanwezig is. |
| afstamming | https://shop.example.co.uk:8443 |
Schema plus host - de eenheid die browsers gebruiken voor beveiliging. |
| paadje | /catalog/shoes |
De bronlocatie op de host. |
| vraagteken | ?color=red&size=42 |
Sleutelwaardeparameters na de ?. |
| item | #reviews |
client-side anker na de #, nooit naar de server gestuurd. |
De parser legt elk van deze uit als zijn eigen rij met een kopieerknop, zodat je nooit meer een hostnaam uit een monster-URL hoeft te halen. Het markeert ook een aantal dingen die de onbewerkte tekenreeks verbergt: of de getoonde poort expliciet is of het standaardschema is, en of de host een benoemd domein of een onbewerkt IP-adres is.
Wat is het verschil tussen hostnaam, host en herkomst?
Deze drie struikelen mensen voortdurend, en de verwarring veroorzaakt echte bugs - CORS-fouten, fouten bij het scopen van cookies, mismatches omleiden Het zijn geen synoniemen De WhatWg URL-standaard is de definitiebrowsers daadwerkelijk geïmplementeerd, en het is de plek om een discussie over wat als oorsprong geldt, op te lossen.
hostnaam is gewoon het domein of IP: shop.example.co.uk. Geen poort, geen schema. Het is wat je zou in een DNS-lookup plaatsen.
waard is de hostnaam plus de poort, Maar alleen wanneer een poort in de URL aanwezig is. om shop.example.co.uk:8443 De gastheer is shop.example.co.uk:8443. Voor een vlakte https://shop.example.co.uk/ De host en hostnaam zijn identiek, omdat de standaardpoort 443 wordt geïmpliceerd in plaats van geschreven. Die "alleen wanneer de huidige" regel is subtiel en daarom kan dezelfde site twee verschillende hosts lijken te hebben.
afstamming is schema plus gastheer: https://shop.example.co.uk:8443. Dit is degene waar browsers het meest om geven, omdat het beleid van dezelfde oorsprong - de basis van webbeveiliging - de oorsprong vergelijkt, en niet de hostnamen. Twee URL's delen alleen een oorsprong als hun schema, hostnaam, en poort alle match. http://example.com en https://example.com zijn verschillende oorsprong omdat het schema verschilt. https://example.com en https://example.com:8443 zijn verschillende oorsprong omdat de poort verschilt, ook al is de hostnaam hetzelfde. Als een ophaalactie faalt met een CORS-fout, is het vergelijken van de twee oorsprongsgetallen in de parser meestal de snelste manier om de mismatch te herkennen.
Hoe parseer ik een queryreeks?
De queryreeks is waar het grootste deel van de dagelijkse pijn leeft, omdat het een platte, zonder ontmaskering is die eigenlijk gestructureerd en procent-gecodeerd is. De parser splitst het voor je: alles na de ?, gebroken op &, met elk key=value Paar gedecodeerd en in een tabel in de oorspronkelijke volgorde vermeld.
Hierbij spelen twee gedragingen uit. eerst, decodering. een parameter geschreven als q=trail%20runner Op de draad wordt weergegeven als trail runner in de kolom Waarde, omdat %20 is een procent-gecodeerde ruimte. de rauwe search string wordt nog steeds onaangeroerd weergegeven in de componentenlijst, dus je kunt de gecodeerde en gedecodeerde formulieren vergelijken - van onschatbare waarde als je dubbele codering vermoedt, zoals mijn %2520 Outh-bug.
ten tweede, Herhaalde toetsen. Een URL kan dezelfde sleutel meer dan eens legitiem dragen: ?tag=react&tag=typescript&tag=node. Veel naïeve parsers laten deze samenvallen, waarbij alleen de eerste of laatste waarde behouden blijft en in stilte gegevens verloren gaan Dat is verkeerd - herhaalde sleutels zijn hoe HTML-formulieren velden met meerdere selecties indienen en hoe veel API's arrays uitdrukken De parser houdt elke gebeurtenis als zijn eigen rij, op volgorde, zodat je alle drie de tags ziet Wanneer je de query kopieert als JSON, worden herhaalde sleutels een array, wat de vorm is die de meeste code verwacht.
U hebt niet eens een volledige URL nodig om dit te gebruiken Plak slechts een query string - color=red&size=42 - en de tool parseert het op zichzelf. Het is de snelste manier die ik ken om een webhook-payload of een trackinglink te begrijpen die iemand je heeft doorgestuurd.
Hoe gebruik ik de URL-parser?
De tool is ontworpen om uit je weg te gaan Plak een URL in de enkele invoer en deze parseert live terwijl je typt - geen knop om op te drukken Een voorbeeldlink is vooraf geladen zodat je de volledige uitsplitsing onmiddellijk kunt zien, en een knop Wissen leegt het veld.
U hoeft het schema niet te typen. Plak een kale gastheer zoals example.com/pricing En de parser prepends https:// automatisch, dan vertelt u dat het deed met een kleine noot, zodat je nooit in de war over waar het schema kwam Plak een expliciet schema - http://, ftp://, ssh:// - en dat respecteert het in plaats daarvan.
De uitgang heeft vier zones. Bovenaan is de Genormaliseerde URL - de canonieke vorm van de browser's-engine geproduceerd, met een kopieerknop, wat handig is om subtiele normalisatieverschillen op te vangen. Daaronder de details tabel, één gelabelde rij per onderdeel, elk onafhankelijk kopieerbaar. daarna Padsegmenten, opgebroken in geïndexeerde chips dus een diep pad zoals /api/v2/users/42/orders is in één oogopslag leesbaar. Eindelijk de Queryparameters tabel, gedecodeerd en geordend, met een "kopieer als JSON" actie die de hele query in een schoon object verandert.
Alles draait in uw browser met behulp van de native URL-engine. Dat is een bewuste keuze: URL's bevatten routinematig toegangstokkens, sessie-ID's, ondertekende parameters en interne hostnamen, en niets daarvan mag naar een server worden verzonden om alleen te worden gelezen. Niets dat u plakt, verlaat uw apparaat en de tool blijft offline werken. Het is dezelfde privacy-first benadering achter de hele toolkit, waar ik op inga in de Handleiding voor webontwikkelaars.
Wanneer reageer ik op een URL-parser?
In mijn eigen werk komen er steeds weer een paar situaties naar voren. Debugging-omleidingen en terugbellen is de grote - OAuth-stromen, betalingsretour-URL's, SSO-handshakes, die allemaal mislukken bij kleine mismatches die alleen zichtbaar worden als je beide URL's ontleed. Audittrackinglinks controleren is een andere: marketing-URL's zijn vaak een basispagina plus een tiental UTM- en AD-platformparameters, en ze lezen als een tafel die met loensen slingert naar een tekenreeks van 300 tekens. Als u die links bouwt in plaats van ze te lezen, dan UTM-bouwer is de andere helft van dezelfde workflow.
Dan is er API-werk - het inspecteren van de queryparameters die een client daadwerkelijk heeft verzonden, of het reverse-engineeren van hoe een eindpunt zijn filters verwacht. En Beveiligingsbeoordeling: Een onbekende link in een e-mail of een logboek is veel veiliger om te begrijpen door de onderdelen te ontleden (welke host doet dit? zowaar wijzen op? Is die hostnaam een IP?) dan door erop te klikken. De parser onthult de echte hostnaam en markeert IP-letterlijke hosts, wat precies de informatie is die u wilt voordat u een link vertrouwt. Ik schreef meer over het samenstellen van dit soort inspectiekits in de API-debugger-tools voor debuggen.
Hoe verhoudt parsing zich tot codering en slugs?
Een URL-parser is een hoek van een kleine familie van linktools en als je weet welke je nodig hebt, bespaart je tijd. taalkundige ontleding leest een bestaande URL en trekt deze uit elkaar. codering doet de tegenovergestelde richting op het niveau van het teken - het veranderen van spaties en speciale tekens in hun procent-gecodeerde vormen zodat ze overleven binnen een URL, en weer terug Wanneer u veilig een waarde in een query string moet insluiten, of decoderen een die is verminkt, dat is de URL-encoder/decoder, en het parseeert natuurlijk met de parser: parse om de structuur te zien, codeer om een gebroken waarde te herstellen.
Slug generatie is een derde, gerelateerde taak: het nemen van een menselijke titel zoals "10 Tips voor snellere bouwsels en quot; en er een schone van maken 10-tips-for-faster-builds pad segment. Dat is wat de Slug Generator handvat, en het is wat het netjes produceert path component de parser leest later terug Zie het als een pijplijn: slugify om goede paden te bouwen, encodeer om waarden URL-veilig te maken, parseer om de voltooide link te inspecteren Elke tool doet één deel van de URL-levenscyclus en doet dit in de browser.
Hoe zit het met IP-adressen en geïnternationaliseerde domeinen?
Niet elke gastheer is een keurige example.com. Sommige URL's wijzen op onbewerkte IP-adressen en de parser herkent beide vormen. een IPv4 letterlijke like http://192.168.1.10:3000/ heeft een hostnaam van 192.168.1.10, en de tool markeert het als een IP in plaats van een domein - handig wanneer u een link controleert en direct wilt weten of het zich richt op een benoemde site of een kaal adres, wat een veelgebruikt signaal is in verdachte links IPv6-literals zijn tussen vierkante haakjes in een URL gewikkeld, zoals in http://[2001:db8::1]:8080/, en de haakjes maken deel uit van de hostsyntaxis, geen decoratie; de parser-handgrepen die haakjes vormen in plaats van stikken in de dubbele punten, die anders eruit zouden zien als poortscheiders.
Geïnternationaliseerde domeinnamen zijn het andere randgeval. Een host geschreven in niet-ASCII-tekens - bijvoorbeeld een domein met al dan niet geaccentueerde letters - wordt door de browser & # 39; s URL-engine omgezet in zijn Punycode xn-- formulier voor het daadwerkelijke verzoek, omdat DNS alleen ASCII spreekt. Het zien van de genormaliseerde href In de parser laat je precies zien wat de browser zal oplossen, wat af en toe mensen verbaast die verwachtten dat hun mooie Unicode-domein ongewijzigd zou reizen. Voor het top-level domein extraheert de parser het uiteindelijke label van een benoemde host, dus shop.example.co.uk meldt een TLD van uk. Dat is een opzettelijk eenvoudige regel: het probeert niet uit meerdere delen bestaande achtervoegsels te verwijderen .co.uk in een registereerbaar domein, omdat het op de juiste manier om dat op de juiste manier te doen, de openbare achtervoegsellijst vereist, wat een grote bewegende dataset is. Voor een snelle inspectie is het laatste label het nuttige signaal, en voor alles wat rigoureus is, zou u naar een speciale bibliotheek gaan.
Een uitgewerkt voorbeeld verbindt het met elkaar. Stel dat een betalingsprovider uw retour-URL blijft afwijzen. jij hebt geregistreerd https://app.example.com/checkout/return Maar het falende verzoek laat zien https://app.example.com:443/checkout/return/. beiden ontleden. de parser toont de eerste heeft host app.example.com (standaardpoort, geen sleep op het pad) en de tweede heeft host app.example.com ook - maar zijn pad is /checkout/return/ met een achterblijvende slash, en de poort werd expliciet geschreven als :443. Twee verschillen waar het oog over glijdt, beide fataal tot een exacte matchcontrole. Zodra u ze als afzonderlijke gelabelde componenten kunt zien, ligt de oplossing voor de hand: normaliseer de achterste slash en laat de overbodige expliciete poort vallen.
Veelvoorkomende fouten bij het lezen van URL's
De terugkerende fouten zijn de moeite waard om te noemen. het fragment verwarren met het pad of de query - alles daarna # is het fragment, het wordt volledig door de browser afgehandeld en wordt nooit naar de server gestuurd, dus een parameter die u na plaatst # zal uw backend niet bereiken. Ervan uitgaande dat een ontbrekende poort betekent geen poort - een weggelaten poort betekent het schema feil (443 voor HTTPS, 80 voor HTTP), die de parser expliciet maakt, zodat je weet welke poort een verzoek echt zal raken.
Dubbele codering negeren - als een waarde eruit ziet als %2520 in plaats van %20, het werd twee keer gecodeerd; ontleden het, en als de gedecodeerde waarde nog steeds een percentagereeks bevat, decodeer opnieuw. Vertrouwen op de zichtbare tekst van een link - de tekst die je ziet en de feitelijke href Kan volledig verschillen, wat het hele mechanisme is achter phishing; parsing onthult de echte bestemmingshost. en Herhaalde querysleutels behandelen als duplicaten om te verwijderen - het zijn vaak betekenisvolle arrays, en als je ze laat vallen, verliezen ze gegevens.
Veelgestelde vragen
Wat zijn de onderdelen van een URL?
Een URL heeft een schema (https), optionele referenties (user:pass@), een host (example.com) met een optionele poort, een pad (/blog/post), een optionele queryreeks (?id=42) en een optioneel fragment (#section). Deze parser scheidt en labelt elk.
Hoe parseer ik een queryreeks?
Plak de volledige URL en lees de querytabel, of plak alleen de queryreeks op zichzelf. De parser splitst het op ampersands, decodeert de codering van het percentage en de codering van elk sleutelwaarde. Herhaalde toetsen zoals tag=A&tag=b worden als afzonderlijke rijen bewaard.
Wat is het verschil tussen hostnaam, host en herkomst?
Hostname is slechts het domein of IP (example.com). Host voegt de poort toe wanneer er een aanwezig is (example.com:8443). Origin is de regeling plus host (https://voorbeeld.com:8443) en is wat browsers gebruiken voor dezelfde veiligheidscontrole.
Welke poort wordt gebruikt als een URL geen poortnummer heeft?
De regeling beslist. HTTPS staat standaard op 443, HTTP naar 80, SSH tot 22 en FTP tot 21. Deze parser toont de effectieve poort en markeert deze als de standaard, zodat u weet welke poort een verzoek daadwerkelijk zou gebruiken.
Decodeert de parser met percentage gecodeerde tekens?
Ja, voor querywaarden. Een parameter zoals name=john%20DOE wordt gedecodeerd weergegeven als "John Doe" in de tabel. De RAW-zoekreeks wordt ook onaangeroerd weergegeven, zodat u de gecodeerde en gedecodeerde formulieren kunt vergelijken.
Kan ik een URL ontleden zonder het https-gedeelte te typen?
Ja. Als u een kale host of pad plakt, zoals voorbeeld.com/pricing, gaat de parser automatisch https:// en merkt op dat het schema is aangenomen. Plak een schema expliciet, zoals http:// of ftp://, om die veronderstelling te overschrijven.
Waarom wordt mijn URL niet geparseerd?
Meestal ontbreekt of is de host misvormd, het schema wordt onjuist geschreven, of de tekenreeks bevat tekens die illegaal zijn in een URL en niet percentencodes zijn. Controleer op spaties, haakjes zonder haakjes of een ontbrekende schuine streep na het schema.
Is het veilig om URL's te plakken met tokens of sessie-ID's?
Ja. Parsing wordt volledig in uw browser uitgevoerd met behulp van de native URL-engine. De link wordt nooit naar een server gestuurd, nooit gelogd en nooit opgeslagen, dus URL's met toegangstokens, API-sleutels of interne hostnamen blijven op uw apparaat.
