URL-parser

URL-parser er et gratis værktøj, der opdeler en webadresse i protokolskema, sti og forespørgselsstreng.

Hvad udtrækker en URL-parser?

En URL-parser finder de enkelte dele af en webadresses struktur, så du ikke selv behøver at opdele teksten. Værktøjet returnerer tre felter ved hjælp af PHP-funktionen parse_url.

• Protokol angiver protokollen eller adresseringsskemaet, for eksempel https eller http.
• Sti angiver stien, for eksempel /account/orders/42.
• Forespørgsel indeholder teksten efter spørgsmålstegnet, der indleder forespørgselsdelen, og før et eventuelt ikke-kodet nummertegn, for eksempel page=2&sort=date.

Parsing er nyttig, når du gennemgår API-anmodninger, callback-URL'er, applikationslogfiler eller data fra tredjeparter. Du kan skelne routingoplysninger fra forespørgselsparametre, før du foretager fejlfinding, logning eller ændrer adressen.

De returnerede felter omfatter ikke separate værdier for værtsnavn, port eller fragment. Har du brug for disse dele, skal du bruge et mere omfattende bibliotek til URL-parsing i din applikation.

Hvordan bruger jeg URL-parseren?

Indtast hele URL'en eller en del af den, og gennemgå de værdier for protokolskema, sti og forespørgsel, som værktøjet returnerer. En komplet, absolut URL giver normalt det tydeligste resultat, fordi protokolskemaet er angivet direkte.

1. Kopiér URL'en fra browseren, et API-svar, en webhook-post eller en serverlog.
2. Medtag forespørgselsstrengen, hvis du vil kontrollere parametrenes navne eller værdier.
3. Sammenlign den returnerede sti med den route, som din applikation forventer.
4. Kontrollér, om protokolskemaet og forespørgslen er angivet de steder, hvor din integration kræver dem.

Behandlingen foregår på serveren. Dit input sendes til serveren via HTTPS og gemmes ikke. Undgå alligevel at indsende aktive adgangstokens, signerede downloadlinks, sessions-id'er eller andre loginoplysninger, hvis et anonymiseret eksempel kan besvare det samme spørgsmål.

Eksempler og fortolkning af resultater

Ved en absolut API-URL adskiller parseren protokollen fra routen og den rå forespørgselsstreng.

Input https://api.example.co.uk/v1/orders/42?expand=items&currency=GBP

Scheme https

Path /v1/orders/42

Query expand=items&currency=GBP

Forespørgslen returneres som én samlet del. Efter den almindelige konvention for formularer og forespørgselsstrenge adskiller et og-tegn felterne, mens det første lighedstegn i hvert felt adskiller navnet fra værdien. Parsing af URL'en bekræfter ikke i sig selv, at expand eller currency er en parameter, som API'et genkender.

En relativ reference kan også indeholde en sti og en forespørgsel uden at angive et protokolskema.

Input /search?q=red%20shoes&page=2

Scheme no scheme component

Path /search

Query q=red%20shoes&page=2

Det er ofte helt forventeligt, at protokolskemaet mangler i links, der er oprettet internt på et website. Hvis dataene derimod skal indeholde absolutte callback-URL'er, kan det samme resultat afsløre, at præfikset https:// mangler.

Denne parser validerer ikke URL'er. Den kan hjælpe med at finde mistænkelige strukturer, for eksempel et manglende protokolskema, en uventet sti eller forespørgselstekst på det forkerte sted. Et parsingsresultat beviser dog ikke, at adressen findes, kan slås op via DNS eller returnerer et vellykket HTTP-svar.

Hvad sker der med mellemrum, tegnsætning og usædvanligt input?

Reserverede tegn påvirker, hvordan en URL opdeles, mens kodede tegn som regel forbliver i den del, hvor de forekommer. Parseren adskiller delene uden at afkode eller normalisere deres indhold.

• Et ikke-kodet spørgsmålstegn indleder forespørgselsdelen. Et bogstaveligt spørgsmålstegn, der skal bruges som data uden for en eksisterende forespørgsel, bør procentkodes, hvis det ellers ville fungere som skilletegn for forespørgslen.
• Et og-tegn adskiller normalt forespørgselsparametre, men værktøjet returnerer hele forespørgselsstrengen frem for at fortolke hver enkelt parameter.
• Et ikke-kodet nummertegn (#) er skilletegnet for fragmentet i standardiseret URL-syntaks. Fragmentdata er ikke blandt de felter, der returneres her.
• Mellemrum bør normalt kodes, ofte som %20. Et plustegn kan repræsentere et mellemrum i formularkodede forespørgselsdata, men den fortolkning hører til afkodning af forespørgslen og ikke parsing af URL'en.
• Tegn med accent og ikke-latinsk tekst i stier eller forespørgsler bør procentkodes med UTF-8, når modtagersystemet kræver det. Internationaliserede domænenavne bruger deres ASCII-kompatible form for at sikre bred kompatibilitet med protokoller.
• Tal behandles ikke på en særlig måde under parsing. De forbliver almindelige tegn i en sti eller forespørgselsværdi.

Et tomt input har ingen brugbar URL-struktur at undersøge. Meget lange URL'er kan desuden ramme begrænsninger andre steder, blandt andet i browsere, webservere, proxyservere og applikationsframeworks. Værktøjet afgør ikke, om et andet system accepterer en bestemt URL-længde.

Hvornår giver det mening at parse en URL?

Parsing er relevant, når du skal undersøge, hvordan en adresse er opbygget, før kode eller infrastruktur behandler den. Typiske eksempler er kontrol af webhook-callbackadresser før udrulning, gennemgang af viderestillingsmål, adskillelse af API-routes fra filtre og læsning af URL'er kopieret fra reverse proxy-logfiler.

Det er normalt ikke nødvendigt, hvis en kendt og allerede struktureret URL kun skal behandles maskinelt, og din applikation i forvejen bruger et URL-bibliotek. Parsing er heller ikke den rette metode, hvis du vil teste tilgængelighed, følge viderestillinger, afkode alle forespørgselsparametre eller kontrollere, om et domæne er troværdigt.

Brug de indbyggede URL-funktioner i dit miljø til gentagne eller automatiserede opgaver. PHP har parse_url, JavaScript i browseren har URL-grænsefladen, Node.js indeholder URL-klassen, og Python har urllib.parse. Et lille kommandolinjescript er bedre egnet end manuel parsing, når du skal behandle en logfil med tusindvis af adresser.

Undlad at parse en URL alene for at omformatere den, hvis den allerede har præcis det format, som modtagersystemet kræver. Genkodning eller genopbygning af adresser uden en klar grund kan ændre forespørgselssignaturer, dublerede parametre eller reserverede tegn.

Ofte stillede spørgsmål

Kan jeg parse en URL uden http eller https?

Ja, PHP-funktionen parse_url kan fortolke relative referencer og delvise URL'er, men der returneres intet protokolskema, hvis det ikke er angivet. Vær forsigtig med protokolrelative adresser, der begynder med to skråstreger, da deres betydning afhænger af det omgivende dokument eller den applikation, de bruges i.

Bevares gentagne forespørgselsparametre?

Forespørgslen returneres som en rå del, så gentagne navne kan bevares i deres oprindelige rækkefølge. Hvordan værdier som tag=red&tag=blue omdannes til arrays eller individuelle værdier, afhænger af den parser til forespørgselsstrenge, der bruges bagefter.

Er det sikkert at indsætte en signeret URL?

Inputtet sendes via HTTPS og gemmes ikke, men en signeret URL kan stadig give adgang til privat indhold, så længe signaturen er gyldig. Fjern tokenet, eller erstat værtsnavnet og værdierne med repræsentative pladsholdere, når de præcise loginoplysninger ikke er nødvendige.

Hvorfor opfører en gyldig URL sig anderledes i min applikation?

Forskelle kan skyldes frameworkspecifik afkodning af forespørgsler og Unicode-normalisering. Applikationer kan også anvende yderligere regler efter parsing, blandt andet lister over tilladte værtsnavne og begrænsninger for viderestillinger. Sammenlign den rå URL byte for byte, og kontrollér derefter, hvad din applikation afkoder eller omskriver, før anmodningen sendes.