Skip to main content

Générateur de schema JSON

Français

Collez du JSON et générez un JSON Schema.

Tous les calculs sont effectués localement dans votre navigateur. Aucune donnée n'est envoyée au serveur.

Les résultats sont fournis à titre informatif. Vérifiez-les auprès d'autres sources.

Inférer un JSON Schema, et ce que l'inférence ne peut pas savoir

Un schéma généré depuis un échantillon décrit cet échantillon, pas votre modèle de données. Il obtient la forme juste et l'intention fausse, car un seul exemple ne peut dire quels champs sont facultatifs, quelles valeurs forment une énumération et quels null ont un sens.

Comment ça marche

  • Parcourt le JSON et émet un type pour chaque valeur : objet, tableau, chaîne, nombre, booléen ou null.
  • Marque comme requis chaque clé présente dans l'échantillon, car c'est tout ce qu'un exemple unique permet.
  • Descend récursivement dans les objets imbriqués et infère le type des éléments de tableau à partir de ce qu'il trouve.
types inférés
  "texte"     → string
  42          → number (integer sans partie décimale)
  true        → boolean
  null        → null   (et non "facultatif")
  [ ... ]     → array aux éléments inférés
  { ... }     → object avec propriétés

required = toute clé vue dans l'échantillon

Exemple chiffré

Inférence depuis {"id": 1, "name": "Ada", "email": null, "tags": ["a", "b"]}.

  1. id → integer, name → string
  2. email → null, ce qui est presque certainement faux : il faudrait ["string", "null"]
  3. tags → tableau de chaînes
  4. les quatre clés marquées requises
  5. aucun maxLength, aucun format, aucun enum — rien de tout cela n'est visible dans un échantillon

Un schéma structurellement correct qui rejetterait des données valides. Le champ email typé null n'accepte que null, et marquer toutes les clés comme requises rejette tout enregistrement où l'une manque.

Lire le résultat

  • Un null dans l'échantillon ne signifie pas que le type est null. Presque toujours, il signifie que le champ est nullable, donc que le bon type est une union comme ["string", "null"]. L'inférence ne peut pas les distinguer et devine toujours la plus étroite.
  • Tout finit dans required parce que l'absence est invisible. Fournissez plusieurs documents différents et l'union des clés révélera la vraie forme ; avec un seul échantillon vous décrivez ce document.
  • Formats, énumérations et bornes échappent à l'inférence. Une adresse e-mail, un UUID, une date et une chaîne quelconque se ressemblent ; ajouter format, enum, minimum et maxLength est le travail qui transforme une forme en contrat.
  • Les tableaux sont l'inférence la plus faible. Un tableau vide ne donne aucun type d'élément, et un tableau de types mélangés signifie en général que l'échantillon n'est pas représentatif, non que le champ accepte réellement n'importe quoi.

Questions fréquentes

Pourquoi mon schéma généré rejette-t-il des données valides ?
Presque toujours parce que toutes les clés ont été marquées requises, ou parce qu'un champ null dans l'échantillon a été typé null au lieu de nullable. Ce sont deux artefacts de l'inférence à partir d'un seul document, et ils se corrigent à la main.
Comment obtenir un schéma réellement utile ?
Traitez la sortie comme un premier jet. Élargissez les champs nullable en unions, sortez de required les clés réellement facultatives, ajoutez format et enum là où vous connaissez la contrainte, et validez contre plusieurs documents réels plutôt que contre celui qui a servi à générer.

Sources