Analyseur de query string

Les query strings d'une URL transportent filtres, balises de campagne, pagination et champs de formulaire après le point d'interrogation d'une adresse. Les lire à la main est source d'erreurs : les espaces peuvent apparaître comme des signes plus ou comme percent-twenty, les esperluettes séparent les champs, l'égal sépare les noms des valeurs, et un échappement pourcent mal formé peut corrompre toute une ligne de journal. Cet analyseur de query string convertit dans les deux sens avec un seul contrat. Le mode parse accepte une requête brute (avec ou sans point d'interrogation initial), décode chaque clé et valeur, et renvoie une liste ordonnée de paires plus une carte d'objet simple pour les clés uniques. Le mode serialize accepte les mêmes paires ou une carte d'objet plat et émet une query string correctement encodée en pourcent, prête à coller après un chemin.

Comment les query strings encodent les paires clé-valeur

Un fragment de requête typique ressemble à name equals Ada ampersand city equals New percent-twenty York. L'esperluette est le séparateur de champs ; le premier égal de chaque champ sépare le nom du paramètre de sa valeur. Les valeurs (et parfois les noms) sont encodées en pourcent pour que espaces, esperluettes, lettres non ASCII et caractères réservés survivent au transit par navigateurs, proxies et outils d'analytique.

De nombreux serveurs traitent aussi un plus nu comme un espace selon les règles application/x-www-form-urlencoded des formulaires HTML ; cette capacité le fait par défaut à l'analyse, et vous pouvez le désactiver si vous avez besoin d'un plus littéral. Les champs vides issus d'esperluettes finales ou doublées sont ignorés afin de ne pas inventer de clés fantômes vides. Un paramètre sans signe égal est traité comme une clé avec valeur chaîne vide, comme dans les bibliothèques serveur courantes.

Lorsque la même clé apparaît plusieurs fois, chaque occurrence est conservée dans la liste ordonnée de paires pour ne pas perdre les filtres multi-sélection ni les balises répétées ; la carte d'objet compagnon utilise last-wins pour que les clients simples obtiennent encore un dictionnaire plat. L'encodage utilise encodeURIComponent sur chaque clé et valeur pour que les séparateurs réservés ne fuient jamais dans la chaîne assemblée.

Où un analyseur de query string gagne sa place

Les services backend qui journalisent les requêtes entrantes ont besoin d'un moyen fiable de transformer la partie recherche d'une URL en champs structurés pour les métriques et le support, sans écrire un découpeur improvisé qui gère mal les signes plus ou l'Unicode. Les applications frontend qui reconstruisent des puces de filtre à partir du search de l'emplacement actuel ont besoin de paires ordonnées pour que les facettes multi-valeurs survivent à un aller-retour encode et decode.

Les pipelines QA et CI comparent des vecteurs de requête de référence entre Node et navigateurs pour qu'un espace soit toujours percent-twenty à l'encodage et qu'un plus en entrée style formulaire devienne encore un espace à l'analyse. Les équipes de support collent des liens à demi encodés depuis des tickets et ont besoin d'un décodeur qui échoue clairement sur les escapes tronqués au lieu d'inventer des caractères.

Les auteurs de cursus qui enseignent les fondations du web veulent une page dédiée à la lecture et l'écriture des paramètres de requête plutôt que d'enterrer le sujet sous un encodeur pourcent générique ou un constructeur UTM, car l'intention de recherche diffère : qui cherche un analyseur de query string veut de la structure, pas seulement de l'échappement de caractères. Une validation échouée ne consomme pas le solde.

Gardez les requêtes sous les limites de longueur documentées, figez les paires ordonnées dans les tests, et vous obtiendrez des cartes de paramètres reproductibles pour tableaux de bord, plugins LMS et workers de bord sans monter votre propre boîte à outils URL complète.