JSON Schema 生成器（根据 JSON 示例）

JSON Schema 描述有效的 JSON 长什么样——有哪些键、它们的类型、哪些是必需的——这样 API、配置文件和表单就可以被自动校验。为一个很大的响应手写 Schema 十分繁琐。粘贴一个或多个示例，就能得到适用于草案 2020-12、2019-09、07、06 或 04 的 Schema：嵌套的对象和数组会被递归描述，每个示例中都有的键会成为必需，整数会变成 integer，并检测 date-time、email、uri、uuid 等常见的字符串格式。

使用方法

1. 粘贴 JSON：示例数组、单个文档，或每行一个文档。
2. 告诉工具示例是如何排列的。
3. 选择你的校验器所用的草案版本。
4. 可选：添加标题和 $id，并选择必需键、additionalProperties: false、格式检测和 enum。
5. 复制 Schema 并进一步完善——添加示例无法体现的描述、范围和模式。

计算公式

null → "null" · true/false → "boolean" · 3 → "integer" · 2.5 → "number" · "…" → "string"（+ format） · [ … ] → "array" + items · { … } → "object" + properties

在同一位置看到的值会被合并：integer 和 number 合并为 number；有时为 null 的值会得到 ["string", "null"] 这样的类型列表；与其他类型混杂的对象或数组会变成 anyOf。只有当该位置的每个对象都有某个键时，它才是必需的。只有该位置的每个字符串都匹配某个格式、且所选草案定义了该格式时才会加上它（date 和 time 从 draft-07 起，uuid 和 duration 从 2019-09 起）。

示例

三个用户示例会生成一个含 7 个属性 的对象 Schema：id（integer）、email（string，format email）、role（string）、joined（string，format date-time——“+09:00” 的偏移也可以）、tags（字符串数组；有一个示例是空数组）、manager（null，只出现一次）和 score（number，只出现一次）。id、email、role、joined 和 tags 是必需的，因为每个示例都有它们；manager 和 score 则不是。