URL

Komponenter

Hva er URL-parseren?

Lim inn en URL, så bryter verktøyet den opp i delene du faktisk bryr deg om — protokoll, vert, port, sti, query-parametere, hash. Utdataen er JSON, så du kan kopiere den rett inn i en testfixture, en debug-logg, eller hvor enn du trenger komponentene i strukturert form. Parseren følger WHATWG URL Standard, som er det enhver moderne nettleser bruker internt.

Hvorfor en parser? Fordi det er smertefullt å lese en lang URL med fem prosent-kodede query-parametere og et hash-fragment. Nettleseren kan allerede gjøre dette via URL API, men du har ingen rask lim-inn-og-se-flate for det. Det er det dette er. Query-parametere blir også dekodet — %20 blir til mellomrom, %5B blir til [, gjentatte nøkler blir til en array — samme oppførsel som URLSearchParams.

Alt kjører i nettleseren din. Ingen opplasting, ingen server, ingen logger. URL-parsing er deterministisk — ingen KI, ingen gjetting, bare den samme algoritmen som RFC 3986 definerte og som WHATWG-spesifikasjonen har finpusset.

Slik bruker du URL-parseren

Tre steg. Hvert av dem matcher en knapp på siden.

Lim inn en URL eller last inn eksemplet

Slipp en URL inn i venstre panel. Klikk Eksempel for å laste inn et realistisk tilfelle med prosent-koding, gjentatte query-nøkler og hash-fragment. Eksempel-URL:

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active&total%5Bgte%5D=49.99&page=2#summary

Alt URL-konstruktøren godtar fungerer — inkludert <code>file://</code>, <code>mailto:</code>, egendefinerte skjemaer, IPv6-verter og userinfo (<code>user:pass@host</code>).

Les komponentene

Høyre panel viser den parsede URL-en som JSON: protocol, host, port, pathname, pathSegments (stien delt opp i en array), searchParams (dekodede nøkkel-verdi-par, med arrays for gjentatte nøkler) og hash. Oppdateres mens du skriver.

Kopier eller last ned

Klikk Kopier for å sende JSON til utklippstavlen, eller Last ned for å lagre som .json-fil. Minifiser presser JSON ned på én linje hvis du trenger det til en loggradd. Bruk Tøm i input-panelet for å starte på nytt.

Når du faktisk vil bruke dette

Feilsøke redirects og analytics-URL-er

En URL med tolv query-parametere fra en annonsesporings-redirect er uleselig i adresselinjen. Lim den inn her for å se parametrene én per linje, dekodet, med destinasjons-url-parameteren fullt pakket ut. Passer godt sammen med tracker-fjerning i vår URL Cleaner (når den er klar).

Inspisere webhook- og OAuth-callback-URL-er

OAuth-callbacks og webhook-payloads dytter tilstand inn i query-strengen. Å splitte den opp gjør det åpenbart om state-tokenet mangler, om code ble kuttet, eller om redirect_uri er kodet to ganger. RFC 6749 krever de parametrene, og dette løfter alle frem i samme slengen.

Bygge testfixtures

Når du skriver tester mot en URL, vil du som regel ha den som et strukturert objekt, ikke en streng. Lim inn URL-en, kopier JSON, slipp det inn i fixture-filen din. Sparer deg fra å taste protocol: 'https:' for hånd for femte gang i dag.

Sanity-sjekk av supporthenvendelser

"Det knakk da jeg klikket på denne lenken" — lenken er 400 tegn lang med dobbelkodede skråstreker. Parseren viser deg nøyaktig hva nettleseren ville sett, inkludert om %252F betyr en bokstavelig %2F eller en sti-separator som ble kodet to ganger på veien gjennom en proxy.

Vanlige spørsmål

Fungerer det på relative URL-er?

Nei — URL-konstruktøren trenger en absolutt URL (med en protokoll som https:// eller file://). For relative URL-er, legg først til en base som https://example.com, og fjern den så fra resultatet. WHATWG-spesifikasjonen beskriver to-argument-formen (new URL(relative, base)) som nettlesere bruker internt.

Hvordan håndterer den gjentatte query-nøkler?

Gjentatte nøkler kollapser til en array. Så ?tag=red&tag=blue blir "tag": ["red", "blue"] i utdata. Dette stemmer med hvordan de fleste server-frameworks (Express, FastAPI, ASP.NET) parser query-strenger.

Og array-klammeparentes-notasjon som ?items[]=1&items[]=2?

Parseren behandler klammeparentesene som en del av nøkkelen — så du ser "items[]": ["1", "2"]. Det er ærlig mot bytene på kabelen. Hvis du trenger en framework-spesifikk dekoder (PHP, Rails, qs.js), gjør etterbehandlingen på den parsede utdataen.

Er det trygt å lime inn legitimasjon i URL-er (user:pass@host) her?

Parsingen skjer fullstendig i nettleseren din — URL-en forlater aldri maskinen din. Når det er sagt, er det generelt frarådet å legge legitimasjon inn i en URL (RFC 3986 §3.2.1 nevner sikkerhetsrisikoene), og de fleste nettlesere fjerner dem stille. Limer du likevel inn en, dukker feltene username og password opp i utdataen.

Kan den håndtere internasjonaliserte domenenavn (IDN)?

Nettleserens URL-konstruktør håndterer IDN-domener, men utdataen kan vise Punycode-formen (xn--...) i stedet for Unicode-formen. Det er sånn URL-en faktisk ville blitt sendt over kabelen. Trenger du å konvertere mellom de to, kommer et dedikert Punycode-verktøy snart i denne seksjonen.

Hvorfor heter utdataen "Komponenter" i stedet for "JSON"?

Det er JSON — men innrammingen betyr noe. Utdataen er URL-ens deler, strukturert. Behandler du siden som en "URL → JSON-konverterer", mister du poenget: verdien ligger i oppdelingen, ikke i formatet.

Andre URL- og JSON-verktøy

Parsing er én operasjon. Her er hva som passer naturlig sammen med det: