Solo perché la data è scritta nello schema JSON, non significa che il validatore debba controllare la data.

format: date è scritto nel JSON Schema, ma una data inesistente supera la verifica. Di solito non si tratta di un bug nella libreria. Il modo in cui viene gestito format dipende dalla configurazione del validatore. Quando incontri un risultato "verifica riuscita", dovresti prima confermare se controlla il tipo, la struttura o controlla anche la semantica della data.

Questo articolo è adatto a sviluppatori e revisori che devono eseguire una verifica strutturata dei dati del documento e hanno a cuore l'accuratezza dei campi data. Dopo aver letto questo, sarai in grado di determinare cosa significa una verifica superata e utilizzare test di controesempio per fissare le regole della data.

Questo articolo utilizza campioni sintetici per dimostrare il metodo di elaborazione. Il codice è stato controllato con esempi in un ambiente isolato e non è una garanzia di tutti i file reali o delle prestazioni del prodotto. Prima di elaborare documenti importanti, conservare gli originali e rivederli rispettando i limiti e gli elementi di accettazione nel testo.

Cosa controlla esattamente la verifica della data di JSON Schema? Conclusione di una frase

Innanzitutto verificare se il controllo format è abilitato nel validatore, quindi verificare se le regole semantiche della data (se esiste effettivamente e come interpretarla) sono altrimenti responsabili.

la tua situazione	Pratiche consigliate	motivo
Controlla `format: date` solo con il validatore predefinito	Per prima cosa conferma se FormatChecker è abilitato esplicitamente	Il modo in cui viene gestito `format` dipende dalla configurazione del validatore
È necessario identificare date come `2026-02-30`	Inseriscilo nel set di test come controesempio	La stringa sembra una data, il che non significa che esista nel calendario.
L'ordine del giorno e del mese della data di origine è sconosciuto.	Segna l'ambiguità, nessuna ipotesi automatica	Il superamento della verifica `date` può solo mostrare che il valore convertito è valido
Campi con ora e fuso orario	Utilizzare protocolli temporali indipendenti	I primi dieci caratteri non devono essere intercettati ed elaborati casualmente
Utilizzato per la verifica della data di traduzione	Salva sia `raw_text` che i valori normalizzati	I revisori devono vedere sia il contenuto originale che la spiegazione sistematica

Due assegni apparentemente identici

2026-02-30 è una stringa e assomiglia a una data, ma non esiste il trentesimo giorno di febbraio. Solo controllando le forme regolari non si verificherà questo tipo di problema. Di seguito viene utilizzato jsonschema di Python per confrontare i risultati del validatore predefinito e abilitare esplicitamente FormatChecker.

Testare la configurazione con una data impossibile

from jsonschema import Draft202012Validator, FormatChecker

schema = {"type": "string", "format": "date"}
structural = Draft202012Validator(schema)
strict = Draft202012Validator(schema, format_checker=FormatChecker())

def valid(v, value):
    return not list(v.iter_errors(value))

assert valid(structural, "2026-02-30")
assert not valid(strict, "2026-02-30")
assert valid(strict, "2024-02-29")
assert not valid(strict, "2025-02-29")
assert not valid(strict, "26/09/2026")
assert not valid(strict, 20260926)

L'esempio sintetico verifica solo date. Altri formati possono avere dipendenze facoltative o differenze di implementazione e dovrebbero essere testati caso per caso in un ambiente bloccato. I nomi di formato sconosciuti non possono essere interpretati come il segno che è stato implementato qualche tipo di controllo e gli errori di ortografia possono darti un senso di sicurezza insignificante.

Il formato della data non è una regola di interpretazione della data

03/04/2026 nella fonte potrebbe significare il 4 marzo o il 3 aprile. La regione di origine, la specifica del campo o il protocollo esplicito sono richiesti prima di convertirlo nel formato ISO. Il superamento della verifica date può solo dimostrare che il valore convertito è valido, ma non può dimostrare che hai selezionato il mese corretto.

Informazioni sulla fonte	cosa fare	Cosa non fare
Data del calendario che non esiste	Segnala un errore e rivedi la fonte	Scorri automaticamente al mese successivo
Ordine sconosciuto del sole e della luna	Ambiguità dell'etichetta	Indovina in base alla lingua del server
Con ora e fuso orario	Utilizzare protocolli temporali indipendenti	Intercetta casualmente i primi dieci caratteri
Il campo è vuoto	Trattare secondo le regole mancanti	Completa la data di oggi

Incorpora la configurazione nei test di regressione

Inserisci almeno tre tipi di valori nel set di test: un giorno bisestile legale, un giorno bisestile illegale e un valore non valido. L'esecuzione di questi controesempi durante la distribuzione è più efficiente rispetto al semplice controllo se il file di schema esiste. Se il servizio è implementato in più lingue, lo stesso set di test dovrebbe essere verificato separatamente e non dare per scontato che il comportamento predefinito dei due validatori sia lo stesso.

La revisione della traduzione mantiene la data originale

Quando si utilizzano i risultati dell'estrazione della data per la verifica della traduzione OmniDoc, si consiglia di salvare sia raw_text che i valori normalizzati. Il revisore deve vedere "qual è il contenuto originale" e "come lo interpreta il sistema" per determinare se la differenza risiede nella traduzione, nell'estrazione o nella conversione del formato.

Riferimenti: Stringa e formato dello schema JSON.

📊 Confronto fondamentale

Voce comparativa	Validatore predefinito	Abilita esplicitamente FormatChecker
Controlla l'ambito	Tipi e strutture	Controllo aggiuntivo per il formato della dichiarazione`format`
Conclusione su `2026-02-30`	Non dare per scontato il rifiuto	Necessita di conferma con controesempi
significato al passaggio	Ciò non significa che la semantica della data sia corretta	Devo ancora controllare la spiegazione della data sull'attività

🎯Quale metodo è adatto a te?

Se devi solo assicurarti che il campo sia una stringa o strutturato correttamente

Il validatore predefinito è solitamente sufficiente, ma tieni presente che non controlla necessariamente la semantica della data.

Se hai bisogno di confermare che la data esiste effettivamente

Abilita esplicitamente FormatChecker e verifica con controesempi come 2026-02-30.

Se vuoi controllare la data nel file sorgente

Per prima cosa conferma le regole di origine della sequenza del giorno e del mese, quindi salva il testo originale e i valori normalizzati.

Se il tuo servizio è distribuito in più lingue

Lo stesso set di test viene eseguito su ciascuna implementazione.

❓ Domande frequenti (FAQ)

1. Lo schema è scritto come `format: date`, perché le date errate possono ancora passare?

Il modo in cui viene gestito format dipende dalla configurazione del validatore e la semantica della data non viene necessariamente controllata per impostazione predefinita.

2. Perché `2026-02-30` è un valore di prova utile?

Sembra una data, ma febbraio non ha trentesimo giorno. Basta controllare l'aspetto per evitare questo tipo di problema.

3. Cosa succede se viene utilizzato un nome di formato sconosciuto?

Non dovrebbe essere trattato come se fosse stato controllato e gli errori di ortografia potrebbero darti un falso senso di sicurezza.

4. Come deve essere convertito `03/04/2026`?

Sono richiesti regione di origine, descrizione del campo o protocollo esplicito. Altrimenti sarebbe impossibile dire se rappresenta il 4 marzo o il 3 aprile.

📝 Riepilogo

Superare la verifica significa solo che i dati rispettano le regole dichiarate, ma non significa che il significato di ciascuna data sia corretto. Innanzitutto confermare l'ambito di controllo del validatore, quindi utilizzare controesempi e regole di origine per correggere l'elaborazione della data, in modo che i risultati siano più affidabili.

Provalo subito: carica il documento per iniziare la traduzione, mantenendo il layout originale