To, że data jest zapisana w schemacie JSON, nie oznacza, że walidator musi sprawdzić datę.

format: date jest napisany w schemacie JSON, ale nieistniejąca data przechodzi weryfikację. Zwykle nie jest to błąd w bibliotece. Sposób obsługi format zależy od konfiguracji modułu sprawdzania poprawności. Gdy napotkasz wynik „weryfikacja powiodła się", powinieneś najpierw potwierdzić, czy sprawdza typ, strukturę, czy też sprawdza semantykę daty.

Ten artykuł jest odpowiedni dla programistów i recenzentów, którzy muszą przeprowadzić uporządkowaną weryfikację danych dokumentu i dbają o dokładność pól daty. Po przeczytaniu tego będziesz w stanie określić, co oznacza weryfikacja przechodząca, i skorzystać z testów kontrprzykładowych, aby ustalić reguły dotyczące dat.

W tym artykule wykorzystano próbki syntetyczne w celu zademonstrowania metody przetwarzania. Kod został sprawdzony na przykładach w izolowanym środowisku i nie stanowi gwarancji działania wszystkich rzeczywistych plików lub produktu. Przed przystąpieniem do przetwarzania ważnych dokumentów prosimy o zachowanie oryginałów i zapoznanie się z nimi zgodnie z granicami i pozycjami akceptacji w tekście.

Co dokładnie sprawdza weryfikacja daty w schemacie JSON? Wniosek w jednym zdaniu

Najpierw sprawdź, czy w walidatorze włączona jest kontrolaformat, a następnie potwierdź, czy w inny sposób odpowiadają za to reguły semantyczne daty (czy faktycznie istnieje i jak ją interpretować).

Dwa pozornie identyczne czeki

2026-02-30 to ciąg znaków wyglądający jak data, ale w lutym nie ma 30-go dnia. Tylko sprawdzanie regularnych kształtów pozwoli pominąć tego rodzaju problem. Poniżej zastosowano jsonschema Pythona do porównania wyników domyślnego modułu sprawdzania poprawności i jawnego włączenia FormatChecker.

Przetestuj konfigurację z niemożliwą datą

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)

Syntetyczny przykład weryfikuje jedynie date. Inne formaty mogą mieć opcjonalne zależności lub różnice w implementacji i powinny być testowane indywidualnie dla każdego przypadku w zamkniętym środowisku. Nieznane nazwy formatów nie mogą oznaczać, że zastosowano jakąś kontrolę, a błędy ortograficzne mogą dać poczucie bezsensownego bezpieczeństwa.

Format daty nie jest regułą interpretacji daty

03/04/2026 w źródle może oznaczać 4 marca lub może oznaczać 3 kwietnia. Przed konwersją do postaci ISO wymagany jest region źródłowy, specyfikacja pola lub jawny protokół. Przejście weryfikacji date może jedynie potwierdzić, że przeliczona wartość jest prawidłowa, ale nie może udowodnić, że wybrałeś właściwy miesiąc.

Uwzględnij konfigurację w testach regresji

Zestaw testowy zawiera co najmniej trzy typy wartości: jeden ważny dzień przestępny, jeden nielegalny dzień przestępny oraz jedną błędną wartość. Uruchamianie tych kontrprzykładów podczas wdrażania jest skuteczniejsze niż samo sprawdzanie, czy plik schematu istnieje. Jeśli usługa jest implementowana w różnych językach, ten sam zestaw testów powinien być walidowany oddzielnie, a domyślne zachowanie dwóch walidatorów nie powinno być zakładane jako identyczne.

Recenzja tłumaczenia zachowuje oryginalną datę

Przy użyciu wyniku ekstrakcji daty do weryfikacji tłumaczenia OmniDoc zaleca się zapisywanie zarówno wartości raw_text, jak i znormalizowanych wartości. Recenzenci muszą zobaczyć "czym jest oryginalna treść" oraz "jak system ją interpretuje", aby zidentyfikować różnice w tłumaczeniu, ekstrakcji lub konwersji formatu.

Źródła: Ciąg i format schematu JSON.

📊 Porównanie rdzenia

🎯 Która metoda ci odpowiada?

Jeśli wystarczy potwierdzić, że pole jest ciągiem lub ma właściwą strukturę

Domyślny walidator zwykle wystarcza, ale pamiętaj, że niekoniecznie sprawdza semantykę dat.

Jeśli musisz potwierdzić, że data naprawdę istnieje

Wyraźnie włącz FormatChecker i weryfikuj za pomocą kontrprzykładów, takich jak 2026-02-30.

Jeśli chcesz zweryfikować datę w pliku źródłowym

Najpierw potwierdź reguły źródłowe dla kolejności dzień-miesiąc, a następnie zapisz oryginalny tekst i znormalizowane wartości.

Jeśli Twoja usługa jest wdrażana w różnych językach

Uruchom ten sam zestaw testów osobno w każdej implementacji.

❓ Najczęściej zadawane pytania (FAQ)

1. Schemat napisał format: date, więc dlaczego złe daty mogą nadal mijać?

Obsługa format zależy od konfiguracji walidatora; domyślnie semantyka dat może nie być sprawdzana.

2. Dlaczego 2026-02-30 jest użyteczną wartością testową?

Wygląda na datę, ale luty nie ma trzydziestego dnia. Skupiając się wyłącznie na wyglądzie, pominie się takie problemy.

3. Co się stanie, jeśli użyjesz nazwy nieznanego formatu?

Nie należy uważać, że został sprawdzony; błędy ortograficzne mogą dawać fałszywe poczucie bezpieczeństwa.

4. Jak powinno być konwertowane 03/04/2026?

Wymagane są informacje o regionie źródłowym, opisie pola lub wyraźnej zgodzie. W przeciwnym razie nie da się stwierdzić, czy oznacza to 4 marca, czy 3 kwietnia.

📝 Podsumowanie

Zdanie checkchecku oznacza jedynie, że dane spełniają zadeklarowane reguły i nie oznacza, że każda data jest poprawna. Najpierw potwierdź zakres inspekcji walidatora, a następnie napraw przetwarzanie dat za pomocą kontrprzykładów i reguł źródłowych, aby uzyskać bardziej wiarygodne wyniki.

Doświadczenie teraz: Prześlij dokument, aby zacząć tłumaczyć, zachowując oryginalne formatowanie