OmniDocТе, що дата записана у схемі JSON, не означає, що валідатор повинен перевіряти дату.
У схемі написано `format: date`, але неправильна дата проходить перевірку. Це не обов'язково може означати, що в бібліотеці є помилка. Спосіб обробки `format` залежить від конфігурації валідатора. Коли ви отримуєте «перевірку успішно», спочатку запитайте, чи перевірено тип, структуру чи також перевірено семантику дати.
format: date записаний у схемі JSON, але неіснуюча дата проходить перевірку. Зазвичай це не помилка в бібліотеці. Спосіб обробки format залежить від конфігурації валідатора. Коли ви натрапите на результат «перевірка успішна», вам слід спочатку перевірити, чи перевіряється тип, структура чи семантика дати.
Ця стаття підходить для розробників і рецензентів, яким потрібно виконати структуровану перевірку даних документів і піклуються про точність полів дати. Прочитавши це, ви зможете визначити, що означає проходження перевірки, і використовувати контрприклад тестування, щоб виправити правила дат.
У цій статті використовуються синтетичні зразки для демонстрації методу обробки. Код було перевірено з прикладами в ізольованому середовищі, і це не є гарантією всіх реальних файлів або продуктивності продукту. Перед обробкою важливих документів збережіть оригінали та перегляньте їх відповідно до меж і пунктів прийняття в тексті.
Що саме перевіряє перевірка дати схеми JSON? Висновок одним реченням
Спочатку перевірте, чи ввімкнено перевірку format у валідаторі, а потім перевірте, чи семантичні правила дати (чи вона насправді існує та як її інтерпретувати) є іншим відповідальним.
| ваша ситуація | Рекомендовані практики | причина |
|---|---|---|
Перевірте лише format: date за допомогою валідатора за замовчуванням | Спочатку переконайтеся, що FormatChecker явно ввімкнено | Спосіб обробки format залежить від конфігурації валідатора |
Необхідно визначити такі дати, як 2026-02-30 | Додайте його в тестовий набір як контрприклад | Рядок виглядає як дата, що не означає, що він існує в календарі. |
| Порядок числа і місяця вихідної дати невідомий. | Позначте неоднозначність, без автоматичного вгадування | Перевірка date може лише показати, що перетворене значення дійсне |
| Поля з часом і часовим поясом | Використовуйте незалежні протоколи часу | Перші десять символів не слід перехоплювати та обробляти випадково |
| Використовується для перевірки дати перекладу | Збережіть як raw_text, так і нормалізовані значення | Рецензенти повинні бачити як оригінальний вміст, так і систематичне пояснення |
Дві, здавалося б, ідентичні перевірки
2026-02-30 є рядком і виглядає як дата, але немає 30-го числа лютого. Тільки перевірка правильних форм дозволить пропустити цю проблему. Нижче використовується jsonschema Python для порівняння результатів валідатора за замовчуванням і явного ввімкнення FormatChecker.
Перевірте конфігурацію з неможливою датою
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)Синтетичний приклад лише перевіряє date. Інші формати можуть мати необов’язкові залежності або відмінності в реалізації, і їх слід тестувати в кожному окремому випадку в заблокованому середовищі. Назви невідомого формату не можуть означати, що була реалізована певна перевірка, а орфографічні помилки можуть дати вам відчуття безглуздої безпеки.
Формат дати не є правилом інтерпретації дати
03/04/2026 у джерелі може означати 4 березня, а може означати 3 квітня. Вихідний регіон, специфікація поля або явний протокол необхідні перед перетворенням у форму ISO. Перевірка date може лише підтвердити, що конвертоване значення дійсне, але не може підтвердити, що ви вибрали правильний місяць.
| Вихідна інформація | що робити | Чого не варто робити |
|---|---|---|
| Календарна дата, якої не існує | Повідомити про помилку та переглянути джерело | Автоматично перейти до наступного місяця |
| Невідомий порядок сонця і місяця | Неоднозначність тегів | Припустіть на основі мови сервера |
| З часом і часовим поясом | Використовуйте незалежні протоколи часу | Випадково перехопити перші десять символів |
| Поле порожнє | Лікувати відповідно до відсутніх правил | Доповніть сьогоднішню дату |
Включіть конфігурацію в регресійне тестування
Помістіть принаймні три типи значень у тестовий набір: законний високосний день, недопустимий високосний день і неправильне значення. Запуск цих контрприкладів під час розгортання ефективніший, ніж просто перевірка наявності файлу схеми. Якщо послугу реалізовано різними мовами, той самий набір тестів слід перевіряти окремо, і не припускайте, що поведінка двох валідаторів за замовчуванням однакова.
Перегляд перекладу зберігає оригінальну дату
При використанні результатів вилучення дати для перевірки перекладу OmniDoc рекомендується зберігати як raw_text, так і нормалізовані значення. Рецензент повинен побачити, «що таке оригінальний вміст» і «як система його інтерпретує», щоб визначити, чи полягає різниця в перекладі, вилученні чи перетворенні формату.
Джерела: Рядок і формат схеми JSON.
📊 Основне порівняння
| Порівняльний пункт | Валідатор за замовчуванням | Явно ввімкніть FormatChecker |
|---|---|---|
| Перевірте обсяг | Види та структури | Додаткова перевірка формату деклараціїformat |
Висновок щодо 2026-02-30 | Не припускайте відмови | Потрібно підтвердити контрприкладами |
| значення при проходженні | Це не означає, що семантика дати правильна | Ще потрібно перевірити пояснення дати на підприємстві |
🎯 Який спосіб вам підходить?
Якщо вам просто потрібно переконатися, що поле є рядком або структуровано правильно
Зазвичай достатньо валідатора за замовчуванням, але майте на увазі, що він не обов’язково перевіряє семантику дати.
Якщо потрібно підтвердити, що дата дійсно існує
Явно ввімкніть FormatChecker і перевірте за допомогою контрприкладів, таких як 2026-02-30.
Якщо ви хочете перевірити дату у вихідному файлі
Спочатку підтвердьте вихідні правила послідовності днів і місяців, а потім збережіть вихідний текст і нормалізовані значення.
Якщо ваш сервіс розгорнуто різними мовами
Той самий набір тестів виконується для кожної реалізації.
❓ Часті запитання (FAQ)
1. Схема записана як format: date, чому погані дати все одно можуть пройти?
Спосіб обробки format залежить від конфігурації валідатора, а семантика дати не обов’язково перевіряється за замовчуванням.
2. Чому 2026-02-30 є корисним тестовим значенням?
Здається, дата, але в лютому немає тридцятого числа. Просто перевіряючи зовнішній вигляд, ви пропустите таку проблему.
3. Що станеться, якщо використовується ім'я невідомого формату?
Не слід розглядати його як перевірений, а орфографічні помилки можуть дати вам помилкове відчуття безпеки.
4. Як потрібно конвертувати 03/04/2026?
Необхідно вказати регіон походження, опис поля або чіткий протокол. Інакше було б неможливо визначити, чи це 4 березня чи 3 квітня.
📝 Підсумок
Проходження перевірки означає лише те, що дані відповідають заявленим правилам, але не означає, що значення кожної дати є правильним. Спочатку підтвердьте область перевірки валідатора, а потім використовуйте контрприклади та вихідні правила, щоб виправити обробку дати, щоб результати були надійнішими.
Спробуйте зараз: завантажте документ, щоб розпочати переклад, зберігаючи вихідний макет
