Extracteur JSONPath, gratuit

Comment ça marche

1. Collez votre JSON : saisissez un objet ou un tableau JSON dans le champ d'entrée.
2. Entrez une expression JSONPath : tapez un chemin comme $.store.book[*].author ou $.users[?(@.age > 18)] pour sélectionner les données voulues.
3. Visualisez les résultats extraits : les valeurs correspondantes apparaissent instantanément dans le panneau de sortie. Copiez le résultat ou exportez-le.

Pourquoi utiliser l'extracteur JSONPath ?

Quand vous travaillez avec des réponses d'API complexes ou du JSON profondément imbriqué, extraire des valeurs spécifiques à la main est lent et source d'erreurs. JSONPath est le langage de requête pour JSON, semblable à XPath pour XML. Il permet de cibler exactement les données dont vous avez besoin à l'aide d'une expression de chemin concise, qu'il s'agisse d'une valeur imbriquée unique, de tous les éléments d'un tableau ou d'enregistrements filtrés correspondant à une condition. Cet outil rend l'exploration JSONPath interactive sans écrire de code.

Fonctionnalités

• Prise en charge complète de JSONPath : notation par points, notation entre crochets, jokers (*), descente récursive (..), filtres (?()) et tranches de tableaux.
• Évaluation en direct : les résultats se mettent à jour à mesure que vous tapez votre expression JSONPath.
• Sortie formatée : les valeurs extraites sont affichées sous forme de JSON joliment formaté.
• Correspondances multiples : renvoie tous les nœuds correspondants du document JSON.
• Signalement des erreurs : messages clairs lorsque l'expression de chemin est invalide ou ne produit aucune correspondance.

Questions fréquentes

Qu'est-ce que JSONPath ?

JSONPath est un langage de requête pour documents JSON, analogue à XPath pour XML. Un chemin comme $.users[*].name sélectionne le champ name de chaque objet dans le tableau users. Il est largement utilisé pour le test d'API, la transformation de données et le traitement JSON.

Comment filtrer les éléments d'un tableau par une condition ?

Utilisez une expression de filtre : $.items[?(@.price < 50)] renvoie tous les éléments dont le prix est inférieur à 50. Le symbole @ fait référence à l'élément en cours d'évaluation.

Prend-il en charge la recherche récursive ?

Oui. L'opérateur .. effectue une recherche récursive à tous les niveaux. Par exemple, $..name trouve toutes les clés name où qu'elles soient dans la structure JSON, quelle que soit la profondeur d'imbrication.

D'un article de blog à RFC 9535 : la route de 17 ans vers un standard JSONPath

Stefan Gössner a proposé JSONPath dans un seul article de blog en février 2007, adaptant l'idée XPath au JSON. Il a publié une implémentation JavaScript de référence, esquissé la syntaxe (la racine $, les opérateurs enfant point et crochet, .. pour la descente récursive, * pour le joker, [début:fin:pas] pour le découpage de tableau, [?(...)] pour les expressions de filtre) et l'écosystème plus large a suivi. Les implémentations ont proliféré : jsonpath pour JavaScript, JsonPath pour Java, jq (Stephen Dolan, 2012) qui est apparenté à JSONPath mais sa propre chose, jsonpath-ng pour Python, JMESPath (AWS, 2014) comme rival plus strict. Le problème : chaque implémentation a dérivé. La syntaxe de filtre, la sémantique de récursion, la correspondance regex, les identifiants racine, tous subtilement différents selon les bibliothèques. Une étude comparative de 2023 par Carsten Bormann et al. a testé 41 implémentations JSONPath distinctes contre la même entrée et obtenu 41 ensembles de résultats différents pour la même expression. Le groupe de travail JSONPath de l'IETF s'est réuni en 2020 pour corriger cela. RFC 9535 «JSONPath: Query Expressions for JSON» a été publié en février 2024, devenant le premier standard formel pour JSONPath, 17 ans après le post original de Gössner. RFC 9535 codifie la syntaxe, définit un format de sortie normalisé, exige la normalisation Unicode pour les comparaisons de chaînes, et ajoute une suite de tests de conformité.

Aide-mémoire de syntaxe JSONPath

Les sept opérateurs qui couvrent la plupart des requêtes du monde réel :

• $ racine. Chaque chemin commence ici. $ seul retourne tout le document.
• .nom enfant par nom. $.store.book sélectionne le champ book dans store. Les noms avec espaces ou caractères spéciaux nécessitent la notation crochet : $['book title'].
• [0] index de tableau. $.book[0] premier élément. $.book[-1] dernier élément (ajout RFC 9535).
• [début:fin:pas] découpage de tableau. Style Python : $.book[1:3] éléments 1 et 2, $.book[::2] un élément sur deux. pas peut être négatif pour inverser.
• * joker. $.book[*].title le titre de chaque livre. Fonctionne aussi comme joker de propriété : $.store.* tous les enfants immédiats de store.
• .. descente récursive. $..title trouve chaque champ title à n'importe quelle profondeur. Puissant mais lent sur les grands documents.
• [?(...)] expression de filtre. $.book[?(@.price < 10)] tous les livres dont le prix est inférieur à 10. @ signifie «l'élément actuel». RFC 9535 nomme ceci ? et standardise les opérateurs de comparaison == != < <= > >= plus les booléens && ||. Le mode rapide de ce viewer n'évalue pas les expressions de filtre, utilisez une bibliothèque comme jsonpath-plus si vous en avez besoin.

Où vous saisissez vraiment JSONPath

• Filtrage de sortie kubectl. kubectl get pods -o jsonpath='{.items[*].metadata.name}' est livré dans Kubernetes et est un consommateur JSONPath utilisé quotidiennement. La variante Kubernetes laisse tomber le $ initial et a quelques particularités à noter si vous vivez dans cet écosystème.
• Test d'API avec Postman ou Insomnia. Les assertions de test comme pm.expect(jsonData.items[0].status).to.eql('active') sont généralement exprimées en JSONPath sous le capot.
• Tableaux de bord Grafana / observabilité. Les panneaux de source de données JSON interrogent les métriques en utilisant JSONPath ; les collecteurs OpenTelemetry utilisent une syntaxe semblable à JSONPath pour extraire les attributs de span.
• Extraction CLI rapide. Associez cet outil avec curl | jq pour l'exploration d'API en direct : prototypez le chemin dans le viewer, puis traduisez en syntaxe jq pour les scripts shell. (jq utilise la notation point mais n'est pas strictement JSONPath.)
• ETL et ingénierie des données. Les mappings Airflow XCom, les fichiers seed dbt, et l'extraction de colonnes JSON SQL utilisent tous des expressions semblables à JSONPath pour atteindre les payloads imbriqués.
• Inspection de tokens. Plongez dans un JWT décodé : $.payload.iss pour l'émetteur, $..roles[*] pour chaque rôle accordé n'importe où dans l'arbre de revendications.
• Conception de gestionnaire webhook. Avant d'écrire le code du gestionnaire, collez un vrai payload webhook et prototypez les chemins qui extraient les champs qui intéressent votre système. Évite un aller-retour avec le service amont.

Erreurs qui mordent

• Dérive d'implémentation. Un chemin qui fonctionne dans une bibliothèque peut produire des résultats différents, ou aucun résultat, dans une autre. Avant RFC 9535, rien n'était standardisé. Maintenant cherchez «conforme RFC 9535» dans la doc de votre bibliothèque (la suite de tests IETF est publiée avec la RFC).
• Citation des filtres. $.book[?(@.title=="Foo")] nécessite des guillemets doubles à l'intérieur du filtre dans RFC 9535 ; beaucoup d'anciennes bibliothèques acceptent aussi les guillemets simples 'Foo'. Les mélanger est une cause courante d'«erreur de syntaxe» en production.
• La descente récursive est gloutonne. $..* retourne toute valeur dans le document, y compris les objets et tableaux imbriqués eux-mêmes, pas seulement les feuilles. Sur de grands documents cela peut prendre des secondes. Restreignez d'abord le chemin, puis descendez.
• Clés entier-vs-chaîne. JSON n'a que des clés chaîne, même quand elles semblent numériques. $.users.123 et $.users[123] signifient des choses différentes dans certaines bibliothèques : la première cherche une propriété littéralement nommée "123", la seconde peut être interprétée comme l'index de tableau 123.
• Tranches négatives. $.book[-1:] signifie «le dernier élément» dans RFC 9535 et la plupart des implémentations, mais avant 2024 certaines bibliothèques traitaient les indices négatifs comme des erreurs. Si vous ciblez d'anciens parseurs, utilisez des indices absolus.
• Oublier $. Un chemin sans $ initial est invalide dans RFC 9535. Certaines implémentations acceptent .store.book comme raccourci, d'autres le rejettent. Préfixez toujours par $.
• Performance. La descente récursive .. sur un document de 10 Mo peut être O(n) par correspondance. Pour les colonnes d'entrepôt de données ou les boucles chaudes, pré-extrayez une fois avec $.., mettez en cache le résultat, puis parcourez le tableau en cache. N'exécutez jamais un JSONPath complexe à chaque requête.

JSONPath vs jq vs JMESPath vs JSON Pointer

• JSONPath (RFC 9535). Meilleur pour les requêtes ad-hoc et les fichiers de configuration. La syntaxe est familière d'XPath, le standard est récent, plusieurs bibliothèques de langue le supportent.
• jq. Un langage complet de transformation de données, pas seulement une requête de chemin. Ajoute map/filter/reduce, fonctions de chaîne, mathématiques, formatage. Mieux quand vous avez besoin de remodeler les données, pas seulement de les extraire. A sa propre syntaxe avec notation point mais diverge de JSONPath au niveau des filtres.
• JMESPath. Une alternative de 2014 utilisée par l'AWS CLI (aws ec2 describe-instances --query "..."). Plus strict et fonctionnel que JSONPath, a une vraie grammaire dès le premier jour, supporte les projections et opérateurs pipe. Moins courant en dehors de l'écosystème Amazon.
• JSON Pointer (RFC 6901). Un standard de 2013 pour adresser une valeur unique : /store/book/0/title. Ne peut pas faire de jokers, filtres ou récursion. Utilisé par JSON Patch (RFC 6902), JSON Schema $ref, et l'API de patch Kubernetes. Choisissez ceci quand vous avez besoin de pointage exact, pas de requête.

Plus de questions fréquentes

JSONPath est-il identique à XPath ?

Inspiré par lui, pas identique. XPath a été finalisé par le W3C en 1999 pour XML, JSONPath a été esquissé par Gössner en 2007 pour apporter la même idée à JSON. Les plus grandes différences : JSONPath utilise . et [] au lieu de /, JSONPath n'a aucun concept de namespaces ou d'attributs XML, JSONPath a été standardisé bien plus tard (2024 vs 1999), donc pendant des années c'était une syntaxe de facto avec de nombreuses implémentations incompatibles.

Pourquoi le même JSONPath donne-t-il des résultats différents dans différents outils ?

Parce que JSONPath n'a pas été standardisé jusqu'à RFC 9535 (février 2024). Avant cela, chaque implémentation faisait ses propres choix concernant la syntaxe de filtre, le support regex, les identifiants racine, les règles d'échappement, et les cas limites (tableaux vides, clés manquantes, coercition de type dans les filtres). Une étude du groupe de travail IETF de 2023 a testé 41 implémentations sur la même entrée et obtenu 41 ensembles de résultats différents. RFC 9535 corrige cela pour les bibliothèques nouvelles et mises à jour ; les anciennes bibliothèques divergeront jusqu'à ce qu'elles migrent. Vérifiez toujours si votre bibliothèque revendique «conformité RFC 9535».

Puis-je modifier le JSON avec JSONPath, ou seulement lire ?

RFC 9535 définit strictement JSONPath comme un langage de requête : il retourne des valeurs d'un document, il ne mute pas. Pour modifier le JSON, utilisez JSON Patch (RFC 6902), qui utilise les chemins JSON Pointer et les opérations add/remove/replace/copy/move/test. Certaines bibliothèques combinent les deux (par ex. jsonpath-plus en JavaScript a une extension de mutation apply()) mais ce n'est pas du JSONPath standard.

JSONPath supporte-t-il les expressions régulières dans les filtres ?

RFC 9535 a ajouté deux fonctions regex : match(node, regex) correspond à toute la chaîne, search(node, regex) correspond à n'importe quel sous-chaîne. Exemple : $.book[?(match(@.isbn, "^978-"))]. La saveur regex est I-Regexp (RFC 9485, un profil de regex XML Schema), pas PCRE ou regex JavaScript. Les anciennes bibliothèques utilisaient la saveur regex de leur langue hôte, ce qui rend les requêtes regex particulièrement non portables.

Mon JSON est-il envoyé quelque part quand j'utilise cet outil ?

Non. L'évaluation du chemin s'exécute entièrement dans le moteur JavaScript de votre navigateur. Ouvrez l'onglet Réseau dans DevTools et exécutez une requête, vous verrez zéro requête sortante pendant l'évaluation. Sûr pour les réponses API avec secrets, les dumps de base de données avec PII, ou les fichiers de configuration contenant des identifiants.