ToolDeck

Analyseur d'URL

Décomposez une URL en ses composants — protocole, hôte, chemin, paramètres, hash

Essayer un exemple

Qu'est-ce que l'analyse d'URL ?

L'analyse d'URL est le processus qui consiste à décomposer un Localisateur de Ressource Uniforme en ses composants individuels : protocole (schéma), hostname, port, pathname, paramètres de requête et identificateur de fragment. Toute URL suit une structure définie par RFC 3986 et le standard WHATWG URL. Un analyseur d'URL lit la chaîne brute, identifie chaque segment grâce à ses caractères délimiteurs (://, :, /, ?, #, &, =) et les retourne sous forme de champs séparés et accessibles.

Les navigateurs analysent les URL à chaque fois que vous saisissez une adresse ou cliquez sur un lien. Le constructeur JavaScript URL, le module urllib.parse de Python et le package net/url de Go implémentent tous des analyseurs qui suivent les mêmes règles structurelles. Analyser une URL est l'opération inverse de l'encodage d'URL : au lieu de transformer des caractères pour un transport sécurisé, vous décomposez une URL déjà formée en les parties qui la constituent.

Une URL typique comme https://api.example.com:8080/v1/users?page=2&limit=10#section contient six composants distincts. Les caractères délimiteurs — ://, :, /, ?, &, = et # — sont ce qui rend l'analyse déterministe : chacun signale une frontière et permet à l'analyseur d'extraire les champs sans ambiguïté.

Pourquoi utiliser un analyseur d'URL en ligne ?

Décomposer une URL manuellement à l'œil est source d'erreurs, surtout lorsque la chaîne contient des caractères encodés, plusieurs paramètres de requête ou des ports non standard. Cet outil analyse l'URL en utilisant le même algorithme conforme au standard WHATWG que les navigateurs, et affiche chaque composant dans un tableau clair et copiable.

Analyse instantanée dans votre navigateur
Collez n'importe quelle URL et voyez immédiatement tous ses composants décomposés. Pas de rechargement de page, pas d'appel serveur, pas d'attente.
🔒
Vos URLs restent privées
L'analyse s'effectue entièrement dans votre navigateur grâce à l'API URL native. L'URL que vous saisissez ne quitte jamais votre machine.
🔍
Inspectez chaque détail
Visualisez le protocole, le hostname, le port, le pathname, la chaîne de requête, le fragment hash et chaque paramètre de requête individuel avec sa valeur décodée.
📋
Copiez les composants individuellement
Cliquez sur le bouton de copie à côté de n'importe quel champ pour récupérer la valeur exacte. Plus besoin de sélectionner et découper manuellement des sous-chaînes.

Cas d'utilisation de l'analyseur d'URL

Débogage du routage frontend
Vérifiez que les segments de chemin et les fragments hash correspondent à votre configuration de routeur. Repérez les barres obliques mal placées ou les paramètres de requête inattendus avant qu'ils ne provoquent des erreurs 404.
Validation des endpoints d'API backend
Vérifiez que les URLs de requêtes entrantes contiennent le hostname, le port et la structure de chemin corrects avant de rédiger vos gestionnaires de routes ou vos middlewares.
Test des règles de redirection DevOps
Lors de la rédaction de règles de redirection Nginx, Apache ou CDN, analysez les URLs d'origine et de destination pour confirmer que chaque composant est correctement associé.
Vérification des liens en QA
Analysez les URLs issues de rapports de test ou de tickets de bug pour isoler quel paramètre de requête ou fragment provoque le chargement de la mauvaise page.
Extraction d'URLs dans les pipelines de données
Extrayez les hostnames ou segments de chemin à partir d'URLs contenues dans des fichiers de logs ou des données analytics pour construire des rapports par domaine ou filtrer le trafic par endpoint.
Apprentissage de la structure des URLs
Les étudiants et développeurs découvrant les protocoles web peuvent coller de vraies URLs et voir immédiatement quel délimiteur marque quelle frontière.

Référence des composants d'URL

Le tableau ci-dessous présente chaque propriété retournée par le constructeur JavaScript URL lors de l'analyse d'une URL. Les mêmes composants existent dans le résultat urlparse de Python, la structure url.URL de Go et la sortie parse_url de PHP, bien que les noms de propriétés diffèrent selon les langages.

PropriétéExempleDescription
protocolhttps:Scheme including the trailing colon
hostnameapi.example.comDomain name or IP address
port8080Port number (empty string if default)
pathname/v1/usersPath starting with /
search?page=2&limit=10Query string including the leading ?
hash#sectionFragment identifier including the leading #
originhttps://api.example.com:8080protocol + hostname + port
hostapi.example.com:8080hostname + port
usernameadminCredentials before @ (rarely used in practice)
passwordsecretCredentials before @ (avoid in production URLs)
href(full URL)The complete, serialized URL string

Standard WHATWG URL vs RFC 3986

Deux spécifications définissent comment les URLs doivent être analysées. Elles s'accordent sur la structure de base mais divergent dans les cas limites — et cette divergence est généralement la cause lorsque votre navigateur traite une URL différemment de votre serveur.

WHATWG URL Standard
Utilisé par tous les navigateurs modernes et le constructeur JavaScript URL. Accepte et normalise les entrées approximatives : schémas manquants, barres obliques inverses comme séparateurs de chemin, noms d'hôtes non ASCII via Punycode. Défini comme standard évolutif sur url.spec.whatwg.org.
RFC 3986
La spécification formelle IETF (2005). Plus stricte que WHATWG : rejette certaines entrées acceptées par les navigateurs. Utilisée par de nombreuses bibliothèques côté serveur, dont net/url de Go et urllib.parse de Python. Définie dans RFC 3986.

En pratique, la plupart des différences apparaissent lors de l'analyse d'URLs avec des noms de domaine internationaux (IDN), des schémas manquants ou des caractères inhabituels. L'analyseur WHATWG convertit automatiquement les hostnames IDN en Punycode, tandis que les analyseurs stricts RFC 3986 peuvent les rejeter. Si vous collez une URL dans cet outil et obtenez des résultats différents de ceux de votre code côté serveur, la différence WHATWG vs RFC 3986 en est très probablement la cause.

Exemples de code

Chaque langage majeur dispose d'un analyseur d'URL intégré. Les exemples ci-dessous analysent la même URL et en extraient les composants. Notez les légères différences de nommage selon les langages : Python utilise scheme au lieu de protocol, et Go expose RawQuery au lieu de search.

JavaScript (browser / Node.js)
const url = new URL('https://api.example.com:8080/v1/users?page=2&limit=10#section')

url.protocol  // → "https:"
url.hostname  // → "api.example.com"
url.port      // → "8080"
url.pathname  // → "/v1/users"
url.search    // → "?page=2&limit=10"
url.hash      // → "#section"

// Iterate over query parameters
for (const [key, value] of url.searchParams) {
  console.log(`${key} = ${value}`)
}
// → "page = 2"
// → "limit = 10"

// Modify and re-serialize
url.searchParams.set('page', '3')
url.toString()
// → "https://api.example.com:8080/v1/users?page=3&limit=10#section"
Python
from urllib.parse import urlparse, parse_qs

result = urlparse('https://api.example.com:8080/v1/users?page=2&limit=10#section')

result.scheme    # → 'https'
result.hostname  # → 'api.example.com'
result.port      # → 8080
result.path      # → '/v1/users'
result.query     # → 'page=2&limit=10'
result.fragment  # → 'section'

# Parse query string into a dict
params = parse_qs(result.query)
params['page']   # → ['2']
params['limit']  # → ['10']

# Reconstruct with modifications
from urllib.parse import urlencode, urlunparse
new_query = urlencode({'page': '3', 'limit': '10'})
urlunparse(result._replace(query=new_query))
# → 'https://api.example.com:8080/v1/users?page=3&limit=10#section'
Go
package main

import (
	"fmt"
	"net/url"
)

func main() {
	u, err := url.Parse("https://api.example.com:8080/v1/users?page=2&limit=10#section")
	if err != nil {
		panic(err)
	}

	fmt.Println(u.Scheme)   // → "https"
	fmt.Println(u.Hostname()) // → "api.example.com"
	fmt.Println(u.Port())     // → "8080"
	fmt.Println(u.Path)       // → "/v1/users"
	fmt.Println(u.RawQuery)   // → "page=2&limit=10"
	fmt.Println(u.Fragment)   // → "section"

	// Query params as map
	q := u.Query()
	fmt.Println(q.Get("page"))  // → "2"
	fmt.Println(q.Get("limit")) // → "10"
}
PHP
<?php
$url = 'https://api.example.com:8080/v1/users?page=2&limit=10#section';
$parts = parse_url($url);

$parts['scheme'];   // → "https"
$parts['host'];     // → "api.example.com"
$parts['port'];     // → 8080
$parts['path'];     // → "/v1/users"
$parts['query'];    // → "page=2&limit=10"
$parts['fragment']; // → "section"

// Parse query string into an array
parse_str($parts['query'], $params);
$params['page'];    // → "2"
$params['limit'];   // → "10"

Foire aux questions

Quelle est la différence entre une URL et un URI ?
Une URL (Uniform Resource Locator) est un type spécifique d'URI (Uniform Resource Identifier) qui inclut à la fois l'identifiant et le mécanisme d'accès (le schéma, comme https://). Toutes les URLs sont des URIs, mais tous les URIs ne sont pas des URLs. Un URN comme urn:isbn:0451450523 est un URI qui identifie une ressource par son nom sans préciser comment la récupérer. Dans le développement web, les deux termes sont souvent utilisés de manière interchangeable car presque tous les URIs que vous rencontrez sont des URLs.
Comment le constructeur URL gère-t-il les URLs relatives ?
Le constructeur JavaScript URL nécessite une URL de base pour analyser les chemins relatifs. Appeler new URL('/path?q=1') lève une TypeError. Vous devez fournir une base : new URL('/path?q=1', 'https://example.com'). urljoin de Python et url.ResolveReference de Go servent le même objectif. Cet outil attend des URLs complètes et absolues avec un schéma.
Que se passe-t-il lorsqu'une URL n'a pas de numéro de port ?
Lorsque le port est omis, l'analyseur retourne une chaîne vide pour la propriété port. Le navigateur suppose le port par défaut pour le schéma : 443 pour https, 80 pour http, 21 pour ftp. Vous pouvez accéder au port effectif via la propriété origin ou host, mais le champ port lui-même reste vide car aucun port explicite n'a été spécifié.
Une URL peut-elle contenir des caractères Unicode ?
Oui, mais ils doivent être encodés pour la transmission. Le standard WHATWG URL gère cela automatiquement : les noms de domaine internationaux sont convertis en Punycode (préfixe xn--), et les caractères de chemin et de requête en dehors de la plage ASCII sont encodés en pourcentage. Si vous collez une URL contenant de l'Unicode dans cet outil, vous verrez la version normalisée et compatible ASCII dans le résultat analysé.
Quelle est la longueur maximale d'une URL ?
Aucun standard ne définit de longueur maximale pour une URL — RFC 3986 est muet sur ce point. En pratique, les navigateurs imposent des limites : Chrome prend en charge jusqu'à environ 2 Mo dans la barre d'adresse, tandis qu'Internet Explorer (en fin de vie) avait une limite de 2 083 caractères. La plupart des serveurs web sont limités par défaut à 8 Ko (Nginx) ou 8 Ko (Apache) pour la ligne de requête. Si vous devez transmettre de grandes quantités de données, utilisez des corps de requête POST plutôt que des chaînes de requête.
Comment analyser uniquement la chaîne de requête sans l'URL complète ?
En JavaScript, utilisez new URLSearchParams('page=2&limit=10') pour analyser une chaîne de requête seule. En Python, utilisez urllib.parse.parse_qs('page=2&limit=10'). Les deux retournent les paramètres sous forme de paires clé-valeur. C'est utile lorsque vous disposez de la chaîne de requête isolément, par exemple depuis une soumission de formulaire ou une entrée de log qui n'a capturé que la partie requête.
L'analyse d'URL est-elle la même chose que le décodage d'URL ?
Non. L'analyse d'URL divise une URL en composants structurels (schéma, hôte, chemin, requête, fragment). Le décodage d'URL reconvertit les caractères encodés en pourcentage dans leur forme d'origine (%20 redevient un espace, %26 redevient &). Les deux opérations sont complémentaires : on analyse généralement l'URL en premier, puis on décode les valeurs des composants individuels. Décoder avant d'analyser peut briser la structure de l'URL car des délimiteurs décodés comme & et = seraient mal interprétés.