Valida

Validazione come parsing di accettazione o rifiuto

Prima che un'applicazione si fidi di un documento, deve rispondere a una domanda più ristretta: questo testo è ben formato per il formato che dichiara di essere? La validazione in questa famiglia significa controlli sintattici e strutturali—un parser consapevole degli standard può consumare l'input senza errori?—, non certificazione completa di regole di business o schema (a meno che la definizione di «valido» di un formato non includa già lo schema).

Gli strumenti Valid condividono questa missione su HTML, XML, SVG, JSON, YAML e CSV. Iniziate con Valid JSON se state debuggando payload API; la stessa idea vale per markup e testo tabulare nei fratelli sotto.

Cosa significa «valido» per formato

I formati non concordano su quanto in profondità va «valido»:

• JSON — grammatica ECMA-404 / RFC 8259: parentesi graffe corrispondenti, chiavi tra virgolette, nessuna virgola finale, forme numeriche legali. Non c'è un passo standard «JSON Schema» dentro la sola validazione di parse.
• YAML — successo di caricamento YAML 1.1/1.2: struttura di indentazione, tag consentiti e stili scalari. YAML può esprimere tipi e ancoraggi che JSON non può; un caricamento riuscito non equivale a «sicuro caricare YAML non fidato» in ogni runtime.
• XML — ben formato (tag corrispondenti, nomi legali, regole sulle entità). La validità di schema (XSD/DTD) è uno strato separato e più rigoroso.
• HTML — le regole di parsing HTML viventi differiscono da XHTML. I validatori possono segnalare elementi non chiusi, tag fuori posto o costrutti obsoleti a seconda del profilo di conformità del motore.
• SVG — vocabolario grafico basato su XML. XML ben formato è necessario; SVG valido implica anche annidamento e attributi corretti per il namespace SVG, anche se strumenti leggeri spesso si concentrano prima su parse e ben formato.
• CSV — righe di campi separati da un delimitatore (spesso virgola) con regole di quoting (famiglia RFC 4180). «Valido» di solito significa conteggi di colonne coerenti, escape corretto delle virgolette e codifica leggibile—non che i valori delle celle corrispondano a uno schema di business.

Sapere quale strato serve evita falsa fiducia: XML ben formato può violare una XSD di settore; JSON parseabile può ancora mancare di campi obbligatori.

Subtool in questa famiglia

• Valid HTML — controllare markup HTML per problemi comuni a livello parser in pagine e frammenti.
• Valid XML — controllare documenti e snippet XML ben formati.
• Valid SVG — controllare sorgente SVG come markup grafico strutturato.
• Valid JSON — accettare o rifiutare testo JSON secondo regole grammaticali standard.
• Valid YAML — analizzare YAML e mostrare errori di caricamento o struttura.
• Valid CSV — controllare testo tabulare delimitato per coerenza strutturale.

Scegliete lo strumento che corrisponde al Content-Type o all'estensione file che avete realmente. Non validate YAML con un parser JSON né HTML con un checker solo XML a meno che non richiediate intenzionalmente il dialetto più rigoroso (ad esempio XHTML).

Perché la validazione lato browser aiuta

La validazione locale accorcia il ciclo di feedback quando create fixture, modificate frammenti CMS o ispezionate un body di risposta copiato. Vedete errori orientati alle righe prima di committare file o deployare config. Tenere il documento nel browser evita anche di caricare bozze sensibili su un servizio di lint remoto—anche se appunti e condivisione schermo espongono comunque il contenuto.

La validazione qui complementa i test unitari: i test devono ancora asserire fixture canoniche in CI con le stesse librerie usate dai parser di produzione. I controlli online servono per esplorazione e triage; la CI serve per regressione.

Forme di errore da riconoscere

JSON. Token inatteso, stringa non terminata, virgola finale, apici singoli, NaN. Editor che accettano JSONC passano in locale e falliscono nei parser strict di produzione.

YAML. Tab vs spazi, indentazione errata sotto una chiave, stringhe non quotate ambigue (booleanizzazione on/off in YAML 1.1) e chiavi duplicate a seconda delle impostazioni del loader.

XML/SVG. Tag di chiusura non corrispondenti, < grezzo nel testo, prefissi non definiti, più elementi top-level o caratteri di controllo illegali. File SVG pensati come frammenti embedded in HTML possono fallire come documenti XML autonomi.

HTML. Tag sovrapposti, attributi obsoleti ed errori su elementi void. I parser HTML spesso recuperano; un validatore che segnala problemi può descrivere comunque un albero che un browser renderà—trattate gli avvisi come segnali di qualità, non sempre come fallimenti duri a runtime.

CSV. Virgolette non escapate, newline embedded nei campi senza quoting, delimitatori misti (virgola vs punto e virgola) e righe irregolari dove il conteggio colonne varia.

Validazione versus trasformazione

I validatori rispondono sì/no (e dove è fallito). Formatter e converter cambiano byte. Un documento può essere invalido e «sembrare a posto» nel parser indulgente HTML di un browser, o essere JSON valido ma sbagliato per lo schema API. Pipeline tipica:

1. Validare la sintassi per il formato dichiarato.
2. Validare opzionalmente contro uno schema (JSON Schema, XSD, ecc.) nel codice applicativo.
3. Solo allora trasformare, unire o persistere.

Saltare il passo 1 spreca tempo su errori di trasformazione misteriosi che erano fallimenti di parse fin dall'inizio.

Note di sicurezza per formato

• XML: billion laughs / espansione entità e attacchi entità esterne (XXE) contano quando i parser risolvono DTD o entità. Preferite parser con entità esterne disabilitate per input non fidati.
• YAML: alcuni loader possono costruire oggetti arbitrari (tag stile !!python/object). Preferite API safe-load per YAML non fidato.
• HTML/SVG: attributi script e gestori eventi sono una superficie XSS quando il markup è embedded nelle pagine. Validazione ≠ sanitizzazione.
• CSV: injection di formule nei client foglio di calcolo (=CMD(...)) è un rischio quando CSV si apre in Excel; validità strutturale non neutralizza questo.
• JSON: generalmente più sicuro da parsare dei formati sopra, ma payload enormi possono comunque causare DoS di memoria; limitate la dimensione sui server.

Workflow pratici

• Incollate un body di errore API in Valid JSON prima di incolpare la logica applicativa.
• Controllate un frammento di config Kubernetes o CI con Valid YAML quando l'indentazione sembra sospetta.
• Confermate un export da foglio di calcolo con Valid CSV prima di scrivere un importer.
• Verificate icone modificate a mano con Valid SVG prima del bundling.

Limitazioni

Questi strumenti non sostituiscono schemi di dominio, audit di accessibilità o suite complete di conformità HTML (ad esempio ogni controllo WHATWG). Non provano che XML soddisfi una XSD particolare, che JSON soddisfi OpenAPI o che le colonne CSV corrispondano a un DDL di database. Non sanitizzano neanche contenuto attivo. Usateli come prima porta: struttura prima, significato dopo.

Strumenti correlati

Dopo la validazione JSON, usate Pretty-print JSON per il layout o From JSON to XML per proiezione ad albero. La validazione dice se il documento è commestibile; altre famiglie decidono cosa cucinare.