Confronto delle librerie di parsing ed elaborazione JSON

In sintesi: classifica prima l'esigenza, poi confronta le implementazioni — usa JSON.parse nativo per valori di sola lettura, jsonc-parser quando servono offset o devi preservare la formattazione originale, e aggiungi librerie di query o patch solo dove necessario; carica su richiesta le librerie grandi pagina per pagina e scarta quelle non mantenute.

Ogni libreria sostiene di essere "veloce, piccola e completa". Ciò che le distingue davvero è quanta informazione riescono a darti quando qualcosa va storto.

1. Quattro categorie per scopo

Identifica prima in quale categoria ti trovi, poi confronta le implementazioni concrete — altrimenti è facile usare una libreria di query per fare il lavoro di un parser.

2. Confronto fianco a fianco

I messaggi di errore di JSON.parse variano molto tra engine. V8 produce qualcosa come Unexpected token } in JSON at position 42, ma la precisione della posizione dipende dalla versione dell'engine; jsonc-parser invece restituisce un oggetto strutturato e stabile { error, offset, length }, adatto ai marker dell'editor.

3. Quattro punti decisionali chiave

3.1 Hai bisogno degli offset

Se stai costruendo un editor e vuoi "clicca sull'errore per saltare alla riga corrispondente", devi avere un offset. Il test è semplice: se il tuo messaggio di errore può solo stampare "JSON non valido", gli utenti dovranno cercarlo da soli.

复制import { parse, printParseErrorCode } from 'jsonc-parser';

const errors: Array<{ error: number; offset: number; length: number }> = [];
parse(text, errors, { allowTrailingComma: true, disallowComments: false });

if (errors.length > 0) {
  const firstError = errors[0];
  console.error(`${printParseErrorCode(firstError.error)} at offset ${firstError.offset}`);
}

3.2 Devi preservare il testo originale

Solo lettura di valori → va bene qualsiasi parser. "Cambia un campo e lascia tutto il resto esattamente com'era" → devi usare un'API di modifica, non "parse → cambia l'oggetto → serializza".

Quest'ultima perde: commenti, ordine delle chiavi (in alcune implementazioni), stile di indentazione, notazione dei letterali numerici (1e3 diventa 1000) e forme di escape (\u4e2d diventa il carattere reale).

3.3 I comportamenti limite sono espliciti

Prima di scegliere una libreria, controlla tre cose nella documentazione:

1. Come vengono gestite le chiavi duplicate (conserva l'ultima / genera errore);
2. Se gli interi grandi perdono precisione (la maggior parte delle librerie JS sì, perché passano tutte da Number);
3. L'ambito supportato per BOM, commenti e virgole finali.

Se non c'è documentazione, scrivi un piccolo esempio e provalo tu. È più affidabile che leggere il README.

3.4 Stato di manutenzione

Il rischio di una libreria JSON non è la mancanza di funzionalità, ma l'abbandono a lungo termine: nessuno rilascerà più patch di sicurezza (prototype pollution, ReDoS).

4. Confronto con altri linguaggi

Quando si scambiano dati tra linguaggi diversi, gli inciampi più facili restano sempre la precisione dei numeri e i formati temporali; la scelta della libreria può solo attenuarli, non eliminarli.

5. Combinazioni tipiche

Opzione 1: sito di strumenti (lato browser)

复制Parsing and error location: jsonc-parser
Editor: CodeMirror 6 + @codemirror/lang-json
Query: jsonpath-plus
Patch: fast-json-patch
Share links: lz-string

Il tratto distintivo di questa combinazione è che tutto gira localmente e nessun dato viene caricato, il che corrisponde alle aspettative di privacy di un sito di utilità.

Opzione 2: API gateway lato server

复制Validation: Ajv (compile the schema once, reuse it)
Parsing: native JSON.parse (together with a body size limit)
Deferred parsing of large fields: keep the raw string, parse only when needed

Non introdurre librerie di query/patch nello strato gateway per implementare logica di business — quello è compito dello strato di business.

Opzione 3: CLI e script

复制Pick fields: jq
Format conversion: yq / dasel
Interactive browsing: jless
Batch validation: ajv-cli

6. L'impatto reale di dimensione del bundle e prestazioni

• jsonc-parser è molto piccolo e adatto al bundle principale;
• json5 è leggermente più grande di jsonc-parser perché supporta più sintassi;
• jsonpath-plus include la valutazione delle espressioni ed è sensibilmente più grande, quindi dovrebbe essere caricato su richiesta per pagina;
• fast-json-patch è di dimensioni medie e serve solo quando hai una funzione di confronto.

L'ottimizzazione è semplice: importa dinamicamente per pagina, e non metterli nel chunk di prima schermata.

复制const { JSONPath } = await import('jsonpath-plus');

7. Checklist

• [ ] Scegli le librerie per scopo; non usare una libreria di query per il parsing;
• [ ] Usa jsonc-parser quando servono localizzazioni precise degli errori;
• [ ] Usa API di modifica quando commenti e formattazione devono essere preservati;
• [ ] Prova nella pratica i tre comportamenti limite: chiavi duplicate, interi grandi e BOM;
• [ ] Monitora lo stato di manutenzione della libreria e gli avvisi di sicurezza;
• [ ] Importa dinamicamente su richiesta le librerie grandi.

FAQ

Come scelgo una libreria JSON in base alla dimensione del progetto?

Gli strumenti piccoli che leggono solo dati delle API possono restare su JSON.parse nativo. I progetti che richiedono localizzazioni degli errori di livello editor o devono preservare la formattazione originale dovrebbero usare jsonc-parser. Un gateway lato server ha bisogno solo di validazione e parsing, lasciando le librerie di query e patch allo strato di business, mentre gli script CLI possono usare direttamente jq, yq e ajv-cli.

Perché lo stato di manutenzione conta più del numero di funzionalità?

Il vero rischio di una libreria JSON è l'abbandono a lungo termine, non la mancanza di funzionalità: nessuno rilascerà patch di sicurezza per prototype pollution o ReDoS. Per quanto completa sia la lista delle funzionalità, una libreria ferma ti lascia a rattopparla da solo. Tratta manutenzione e avvisi di sicurezza come criteri rigidi invece di confrontare tabelle di funzionalità.

Devo usare JSON.parse per cambiare un campo e preservare commenti e indentazione?

No. Analizzare, cambiare l'oggetto e poi serializzare perde commenti, ordine delle chiavi, stile di indentazione, notazione dei letterali numerici (1e3 diventa 1000) e forme di escape (\u4e2d diventa il carattere reale). Cambiare un campo lasciando intatto tutto il resto richiede un'API di modifica come modify e applyEdits in jsonc-parser.