URL-parser

Parse og dekod enhver URL til komponentene sine — skjema, vert, port, sti, spørreparametre og fragment. All behandling i nettleseren din.

Umiddelbar parsing Alle komponenter Behandling på klientsiden

Slik bruker du URL-parser

Parse enhver URL i tre enkle trinn

1

Lim inn URL-en din

Skriv inn enhver URL i inndatafeltet — fullstendige URL-er med spørrestreng fungerer best.

2

Umiddelbar nedbryting

URL-en parses i sanntid til alle komponentdelene sine.

3

Undersøk parameterne

Se dekodede spørreparametre i en tabell, og kopier enkeltkomponenter.

Hva er en URL?

En URL (Uniform Resource Locator) er en webadresse som angir plasseringen til en ressurs i et datanettverk og mekanismen for å hente den. URL-er består av flere komponenter, inkludert protokoll, domenenavn, port, sti, spørreparametre og fragment.

URL-struktur

En URL er satt sammen av flere deler:

Protokoll

Kommunikasjonsprotokollen (http, https, ftp osv.)

Vertsnavn

Domenenavnet eller IP-adressen til serveren

Port

Nettverksportnummeret (standard: 80 for HTTP, 443 for HTTPS)

Sti

Den spesifikke ressursstien på serveren

Spørrestreng

Nøkkel-verdi-parametre for dynamisk innhold

Fragment

Et anker som peker til en bestemt del av siden

Ofte stilte spørsmål

Hvilke URL-komponenter gjenkjenner parseren?

Parseren henter ut skjema (protokoll), vertsnavn, port, sti, spørrestrengparametre (som tabell), fragment (hash), brukernavn, passord, opprinnelse og søkestreng.

Dekoder den URL-kodede tegn?

Ja. Alle URL-kodede tegn (som %20, %3A) dekodes automatisk i utdataene for lesbarhet.

Kan jeg parse relative URL-er?

Verktøyet fungerer best med absolutte URL-er (som begynner med http:// eller https://). Relative URL-er krever en basis-URL som nettleseren leverer automatisk.

Hva er forskjellen på URI, URL og URN?

URI er paraplybegrepet definert i RFC 3986: en identifikator satt sammen av skjema, sti, spørring og fragment. En URL er en URI som finner en ressurs (https://ezparser.com/url-parser), mens en URN navngir en uten plassering (urn:isbn:0451450523). I hverdagens webarbeid er URL nesten alltid det du mener.

Hvordan fungerer prosentkoding?

Hver byte som ikke er et ureservert tegn (A-Z, a-z, 0-9, - . _ ~), skrives som % etterfulgt av to heksadesimale siffer: mellomrom blir %20, og e-akutt i UTF-8 blir %C3%A9. Reserverte tegn som / ? # & = bærer betydning i URL-strukturen, så de må kodes når de brukes som data. I spørrestrenger mapper eldre skjemakodere også mellomrom til + - dette verktøyet dekoder begge formene.

Hva kalles delene av en URL?

https://user:[email protected]:8443/v2/users?page=2#results brytes ned i skjema (https), userinfo (user:pass@), vert (api.example.com), port (8443), sti (/v2/users), spørring (page=2) og fragment (#results). RFC 3986 del 3 definerer grammatikken; denne parseren merker hver komponent for deg.

Løser //, /./ og /../ inne i stier faktisk til noe?

Ja - RFC 3986 del 6 definerer normalisering: /a/./b løses til /a/b, /a/../b til /b, og et tomt segment // trekkes sammen til /. Nettlesere og HTTP-klienter anvender dette før en forespørsel sendes, derfor når URL-er som bare skiller seg i punktsegmenter vanligvis samme ressurs. Skjemabasert normalisering gjør også verten til små bokstaver og fjerner en standardport :443.

Finnes det en maksimal URL-lengde?

RFC 3986 setter ingen grense. I praksis godtar Chrome omtrent 2 MB, men de fleste servere begrenser forespørselslinjen til nær 8 KB (Apaches standard LimitRequestLine er 8190 byte), og API-er som Twitter/X dokumenterer grenser på 2048 tegn. Å holde URL-er under 2000 tegn er den konvensjonelle trygge sonen for deling og SEO.

{-- * External Resources Component(#18 Phase 3b 内容佐证工程) * 工具页「权威引用」区块:RFC / W3C / WHATWG / ECMA / IANA / 官方规范站 / Wikipedia。 * * - 接受 :slug 属性 → 经 config/tool-sources.php 家族矩阵渲染该工具的权威引用 * - slug 未命中映射时不渲染(无权威来源的工具静默跳过) * - 链接 title 保持英文(引用源专名);description 经 * common.resources.descriptions.{key} 本地化,lang 未命中回退英文(线上不裸奔) * - 链接保持 dofollow(rel="noopener noreferrer") * * @param string|null $slug --}}