Estrattore di percorsi JSON

Come funziona

1. Incolla il tuo JSON: inserisci un oggetto o un array JSON nel campo di input.
2. Inserisci un'espressione JSONPath: digita un percorso come $.store.book[*].author o $.users[?(@.age > 18)] per selezionare i dati desiderati.
3. Visualizza i risultati estratti: i valori corrispondenti appaiono all'istante nel pannello di uscita. Copia il risultato o esportalo.

Perché usare l'estrattore JSONPath?

Quando lavori con risposte API complesse o JSON profondamente annidato, estrarre valori specifici a mano è lento e soggetto a errori. JSONPath è il linguaggio di query per JSON, simile a XPath per XML. Permette di puntare esattamente ai dati di cui hai bisogno con un'espressione di percorso concisa, che si tratti di un singolo valore annidato, di tutti gli elementi di un array o di record filtrati che corrispondono a una condizione. Questo strumento rende l'esplorazione JSONPath interattiva senza scrivere codice.

Funzionalità

• Supporto completo di JSONPath: notazione con punti, notazione tra parentesi quadre, jolly (*), discesa ricorsiva (..), filtri (?()) e slice di array.
• Valutazione in tempo reale: i risultati si aggiornano mentre digiti la tua espressione JSONPath.
• Output formattato: i valori estratti sono mostrati come JSON formattato in modo leggibile.
• Corrispondenze multiple: restituisce tutti i nodi corrispondenti del documento JSON.
• Segnalazione errori: messaggi chiari quando l'espressione di percorso non è valida o non produce alcuna corrispondenza.

Domande frequenti

Cos'è JSONPath?

JSONPath è un linguaggio di query per documenti JSON, analogo a XPath per XML. Un percorso come $.users[*].name seleziona il campo name di ogni oggetto nell'array users. È ampiamente utilizzato per il test di API, la trasformazione di dati e l'elaborazione JSON.

Come filtrare gli elementi di un array secondo una condizione?

Usa un'espressione di filtro: $.items[?(@.price < 50)] restituisce tutti gli elementi il cui prezzo è inferiore a 50. Il simbolo @ fa riferimento all'elemento in corso di valutazione.

Supporta la ricerca ricorsiva?

Sì. L'operatore .. esegue una ricerca ricorsiva a tutti i livelli. Per esempio, $..name trova tutte le chiavi name ovunque siano nella struttura JSON, indipendentemente dalla profondità di annidamento.

Da un post di blog a RFC 9535: la strada di 17 anni verso uno standard JSONPath

Stefan Gössner ha proposto JSONPath in un singolo post di blog nel febbraio 2007, adattando l'idea di XPath a JSON. Ha pubblicato un'implementazione JavaScript di riferimento, ha abbozzato la sintassi (la radice $, operatori figlio punto e parentesi, .. per discesa ricorsiva, * per jolly, [inizio:fine:passo] per slicing di array, [?(...)] per espressioni filtro) e l'ecosistema più ampio ha seguito. Le implementazioni proliferarono: jsonpath per JavaScript, JsonPath per Java, jq (Stephen Dolan, 2012) che è JSONPath-adiacente ma una sua cosa, jsonpath-ng per Python, JMESPath (AWS, 2014) come rivale più rigoroso. Il problema: ogni implementazione ha derivato. Sintassi di filtro, semantica di ricorsione, corrispondenza regex, identificatori radice, tutti sottilmente diversi tra le librerie. Uno studio comparativo del 2023 di Carsten Bormann et al. ha testato 41 implementazioni JSONPath distinte contro lo stesso input e ha ottenuto 41 set di risultati diversi per la stessa espressione. Il Gruppo di Lavoro JSONPath dell'IETF si è riunito nel 2020 per correggere ciò. RFC 9535 «JSONPath: Query Expressions for JSON» è stato pubblicato nel febbraio 2024, diventando il primo standard formale per JSONPath, 17 anni dopo il post originale di Gössner. RFC 9535 codifica la sintassi, definisce un formato di output normalizzato, richiede la normalizzazione Unicode per i confronti di stringhe, e aggiunge una suite di test di conformità.

Cheat sheet della sintassi JSONPath

I sette operatori che coprono la maggior parte delle query del mondo reale:

• $ radice. Ogni percorso inizia qui. $ da solo restituisce l'intero documento.
• .nome figlio per nome. $.store.book seleziona il campo book all'interno di store. I nomi con spazi o caratteri speciali necessitano della notazione parentesi: $['book title'].
• [0] indice di array. $.book[0] primo elemento. $.book[-1] ultimo elemento (aggiunta RFC 9535).
• [inizio:fine:passo] slice di array. Stile Python: $.book[1:3] elementi 1 e 2, $.book[::2] ogni altro elemento. passo può essere negativo per invertire.
• * jolly. $.book[*].title il titolo di ogni libro. Funziona anche come jolly di proprietà: $.store.* tutti i figli immediati di store.
• .. discesa ricorsiva. $..title trova ogni campo title a qualsiasi profondità. Potente ma lento su grandi documenti.
• [?(...)] espressione filtro. $.book[?(@.price < 10)] tutti i libri dove il prezzo è inferiore a 10. @ significa «l'elemento corrente». RFC 9535 nomina questo ? e standardizza gli operatori di confronto == != < <= > >= più booleani && ||. La modalità rapida di questo viewer non valuta le espressioni filtro, usa una libreria come jsonpath-plus se ne hai bisogno.

Dove ricorri davvero a JSONPath

• Filtraggio dell'output kubectl. kubectl get pods -o jsonpath='{.items[*].metadata.name}' viene fornito in Kubernetes ed è un consumatore JSONPath usato quotidianamente. La variante Kubernetes elimina il $ iniziale e ha alcune peculiarità degne di nota se vivi in quell'ecosistema.
• Test API con Postman o Insomnia. Le asserzioni di test come pm.expect(jsonData.items[0].status).to.eql('active') sono solitamente espresse come JSONPath sotto il cofano.
• Dashboard Grafana / observability. I pannelli di origine dati JSON interrogano le metriche usando JSONPath; i collettori OpenTelemetry usano una sintassi simile a JSONPath per estrarre gli attributi di span.
• Estrazione CLI veloce. Abbina questo strumento con curl | jq per esplorazione API dal vivo: prototipa il percorso nel viewer, poi traduci in sintassi jq per gli script shell. (jq usa la notazione punto ma non è strettamente JSONPath.)
• ETL e ingegneria dei dati. Mappature Airflow XCom, file seed dbt, ed estrazione di colonne JSON SQL usano tutti espressioni simili a JSONPath per raggiungere payload annidati.
• Ispezione di token. Approfondisci un JWT decodificato: $.payload.iss per l'emittente, $..roles[*] per ogni ruolo concesso ovunque nell'albero dei claim.
• Progettazione di handler webhook. Prima di scrivere il codice dell'handler, incolla un payload webhook reale e prototipa i percorsi che estraggono i campi a cui il tuo sistema tiene. Risparmia un viaggio di andata e ritorno con il servizio a monte.

Errori che mordono

• Deriva di implementazione. Un percorso che funziona in una libreria può produrre risultati diversi, o nessun risultato, in un'altra. Prima di RFC 9535 nulla era standardizzato. Ora cerca «conforme RFC 9535» nella documentazione della tua libreria (la suite di test IETF è pubblicata con la RFC).
• Virgolette del filtro. $.book[?(@.title=="Foo")] richiede virgolette doppie all'interno del filtro in RFC 9535; molte librerie più vecchie accettano anche virgolette singole 'Foo'. Mescolarle è una causa comune di «errore di sintassi» in produzione.
• La discesa ricorsiva è avida. $..* restituisce ogni valore nel documento, inclusi oggetti e array annidati stessi, non solo foglie. Su grandi documenti questo può richiedere secondi. Restringi prima il percorso, poi scendi.
• Chiavi intere vs stringa. JSON ha solo chiavi stringa, anche quando sembrano numeriche. $.users.123 e $.users[123] significano cose diverse in alcune librerie: il primo cerca una proprietà letteralmente chiamata "123", il secondo può essere interpretato come indice di array 123.
• Slice negativi. $.book[-1:] significa «l'ultimo elemento» in RFC 9535 e nella maggior parte delle implementazioni, ma prima del 2024 alcune librerie trattavano gli indici negativi come errori. Se prendi di mira parser più vecchi, usa indici assoluti.
• Dimenticare $. Un percorso senza $ iniziale è invalido in RFC 9535. Alcune implementazioni accettano .store.book come abbreviazione, altre lo rifiutano. Prefissa sempre con $.
• Performance. La discesa ricorsiva .. su un documento da 10 MB può essere O(n) per corrispondenza. Per colonne di data warehouse o loop caldi, pre-estrai una volta con $.., memorizza nella cache il risultato, poi cammina l'array memorizzato. Non eseguire mai un JSONPath complesso su ogni richiesta.

JSONPath vs jq vs JMESPath vs JSON Pointer

• JSONPath (RFC 9535). Meglio per query ad-hoc e file di configurazione. La sintassi è familiare da XPath, lo standard è fresco, molteplici librerie linguistiche lo supportano.
• jq. Un linguaggio completo di trasformazione dati, non solo una query di percorso. Aggiunge map/filter/reduce, funzioni stringa, matematica, formattazione. Migliore quando hai bisogno di rimodellare i dati, non solo estrarli. Ha la propria sintassi con notazione punto ma diverge da JSONPath a livello di filtro.
• JMESPath. Un'alternativa del 2014 usata da AWS CLI (aws ec2 describe-instances --query "..."). Più rigoroso e funzionale di JSONPath, ha una vera grammatica dal primo giorno, supporta proiezioni e operatori pipe. Meno comune al di fuori dell'ecosistema Amazon.
• JSON Pointer (RFC 6901). Uno standard del 2013 per indirizzare un singolo valore: /store/book/0/title. Non può fare jolly, filtri, o ricorsione. Usato da JSON Patch (RFC 6902), JSON Schema $ref, e l'API patch di Kubernetes. Scegli questo quando hai bisogno di puntamento esatto, non di query.

Altre domande frequenti

JSONPath è uguale a XPath?

Ispirato da esso, non identico. XPath è stato finalizzato dal W3C nel 1999 per XML, JSONPath è stato abbozzato da Gössner nel 2007 per portare la stessa idea a JSON. Le differenze più grandi: JSONPath usa . e [] invece di /, JSONPath non ha concetto di namespace o attributi XML, JSONPath è stato standardizzato molto più tardi (2024 vs 1999), quindi per anni è stata una sintassi de facto con molte implementazioni incompatibili.

Perché lo stesso JSONPath dà risultati diversi in strumenti diversi?

Perché JSONPath non è stato standardizzato fino a RFC 9535 (febbraio 2024). Prima di allora, ogni implementazione faceva le proprie scelte su sintassi di filtro, supporto regex, identificatori radice, regole di escape, e casi limite (array vuoti, chiavi mancanti, coercizione di tipo nei filtri). Uno studio del gruppo di lavoro IETF del 2023 ha testato 41 implementazioni sullo stesso input e ha ottenuto 41 set di risultati diversi. RFC 9535 risolve questo per librerie nuove e aggiornate; le librerie più vecchie divergeranno fino a quando non migrano. Verifica sempre se la tua libreria afferma «conformità RFC 9535».

Posso modificare il JSON con JSONPath, o solo leggere?

RFC 9535 definisce JSONPath strettamente come un linguaggio di query: restituisce valori da un documento, non muta. Per modificare JSON, usa JSON Patch (RFC 6902), che usa percorsi JSON Pointer e operazioni add/remove/replace/copy/move/test. Alcune librerie combinano entrambi (e.g. jsonpath-plus in JavaScript ha un'estensione di mutazione apply()) ma non è JSONPath standard.

JSONPath supporta espressioni regolari nei filtri?

RFC 9535 ha aggiunto due funzioni regex: match(node, regex) corrisponde all'intera stringa, search(node, regex) corrisponde a qualsiasi sottostringa. Esempio: $.book[?(match(@.isbn, "^978-"))]. Il sapore regex è I-Regexp (RFC 9485, un profilo di regex XML Schema), non PCRE o regex JavaScript. Le librerie più vecchie usavano il sapore regex del loro linguaggio host, il che rende le query regex particolarmente non portabili.

Il mio JSON viene inviato da qualche parte quando uso questo strumento?

No. La valutazione del percorso gira interamente nel motore JavaScript del tuo browser. Apri la scheda Rete in DevTools ed esegui una query, vedrai zero richieste in uscita durante la valutazione. Sicuro per risposte API con segreti, dump di database con PII, o file di configurazione contenenti credenziali.