Errori di sintassi JSON comuni: Come riconoscerli e correggerli (Guida RFC 8259)

1. Validazione della sintassi vs. JSON Schema vs. Regole di business

Un equivoco comune tra gli sviluppatori è considerare qualsiasi convalida di dati JSON come un'unica operazione. Nelle architetture software moderne operano invece tre livelli di convalida nettamente separati:

• Convalida della sintassi RFC 8259: Verifica che il payload rispetti fedelmente la grammatica formale di JSON: parentesi graffe e quadre bilanciate, chiavi e stringhe racchiuse tra virgolette doppie, virgole delimitatrici e valori letterali validi (stringhe, numeri, booleani, null). Se manca una virgoletta o una parentesi, il testo non costituisce un documento JSON valido.
• Convalida con JSON Schema: Valuta se un documento JSON sintatticamente ineccepibile rispetti un contratto di dati prestabilito (direttive $schema, tipi di proprietà attesi, campi obbligatori, limiti di array). Un documento può essere impeccabile sul piano sintattico ma violare il proprio schema.
• Convalida delle regole di business: Applica la logica applicativa propria del dominio (ad esempio, il saldo di un conto non può risultare negativo o la data di fine deve seguire quella di inizio). Né i parser sintattici generici né gli schemi interpretano gli invarianti di business.

Lo strumento GoToolstack esegue una rigorosa convalida della sintassi secondo RFC 8259 e formattazione dell'AST; non effettua convalida di JSON Schema né verifica delle regole di business.

2. La formattazione non equivale alla riparazione automatica degli errori

I formattatori JSON (pretty-printer e minifier) riorganizzano spaziature, rientri e ritorni a capo su un Abstract Syntax Tree (AST) già sintatticamente valido. Non svolgono alcuna funzione di correzione automatica.

Quando viene inserito un testo malformato, il motore si arresta al primo byte non valido, emette un messaggio diagnostico esplicito comprensivo di posizione numerica e frammento (ad esempio Trailing comma in object is not allowed at position 45) e azzera il pannello di output. Lo strumento non tenta di interpretare le intenzioni dell'autore, non inserisce parentesi mancanti, non rimuove virgole illegali né converte virgolette singole in modo autonomo. La correzione manuale dell'errore di sintassi è il requisito fondamentale per consentire la formattazione.

3. I 5 errori di sintassi JSON più frequenti

{
  "name": "GoToolstack",
  "active": true,
}

{'status': 'success'}

{count: 42}

{"path": "C:\programs\data.json"}

// Impostazioni server
{"port": 8080}

4. La trappola degli interi a 64 bit: Conservazione dei token senza perdita vs. Rischio di arrotondamento nei sistemi riceventi

Nei motori JavaScript standard i valori numerici sono archiviati nel formato a virgola mobile a doppia precisione a 64 bit IEEE 754. La soglia superiore per gli interi sicuri è:

Number.MAX_SAFE_INTEGER = 9.007.199.254.740.991 (2^53 - 1)

Quando un'API trasmette identificatori estesi a 64 bit, chiavi primarie di database o hash di transazioni (come 9007199254740993), una normale chiamata a JSON.parse() arrotonda silenziosamente il valore a 9007199254740992, alterando il dato senza sollevare eccezioni.

Il motore di GoToolstack adotta un parser personalizzato senza perdita che cattura i valori numerici come token di testo esatti nell'AST. In questo modo, in fase di formattazione, tutte le cifre originali restano intatte. Tuttavia, tale conservazione non garantisce la sicurezza nei sistemi riceventi: se un servizio a valle, un driver di database o un client frontend analizza in seguito il JSON con un parser float64 standard, la perdita di precisione si verificherà comunque. Nelle architetture distribuite è opportuno trasmettere gli identificatori a 64 bit sotto forma di stringhe (es.: "9007199254740993").

5. Chiavi di oggetto duplicate e ambiguità dell'interprete secondo l'RFC 8259

Consideriamo un oggetto contenente chiavi identiche duplicate:

{"user": "alice", "user": "bob"}

Il parser AST di GoToolstack memorizza ciascuna coppia chiave-valore nel suo ordine sequenziale senza sovrascrivere o rimuovere le voci precedenti. Tuttavia, la sezione 4 dell'RFC 8259 dichiara esplicitamente che il comportamento dei parser di fronte a chiavi duplicate è imprevedibile:

• Alcuni parser considerano soltanto la prima chiave ignorando le successive.
• Numerose implementazioni standard (compresi JSON.parse() in JS e json.loads() in Python) sovrascrivono il valore precedente, trattenendo solo l'ultima chiave.
• Alcuni parser rigorosi respingono immediatamente il documento con un errore di sintassi.

Il fatto che GoToolstack conservi le chiavi duplicate nell'output formattato non garantisce affatto che i sistemi di destinazione le interpretino in modo coerente. In produzione, ogni chiave di un oggetto deve essere univoca.

6. Limitazioni tecniche e ambito operativo dello strumento

• Nessuna vista ad albero o validazione di schema: Lo strumento offre un editor di testo grezzo pulito a doppio pannello con diagnostica in tempo reale. Non integra una visualizzazione ad albero collassabile né un validatore per JSON Schema.
• Valori non consentiti: NaN, Infinity e -Infinity non sono ammessi nell'RFC 8259. Valori JavaScript come undefined, funzioni ed elementi con riferimenti circolari non possono essere serializzati.
• Elaborazione lato client: Tutte le operazioni di parsing e formattazione avvengono interamente nella memoria locale del browser; nessun dato viene trasmesso a server remoti.