接口文档补Schema
后端同事交接了十几个 JSON 格式的 API 响应示例,但文档里只写了字段含义,没写 JSON Schema。前端在 TypeScript 里定义类型时,全靠肉眼逐层拆解嵌套对象,一个 5 层深的数组结构能折腾半小时。把示例 JSON 粘贴进工具,立即输出对应的 Schema 定义,直接复制进 .d.ts 文件或 swagger 文档里,类型定义和校验规则一次对齐,免去手动拆解和漏字段的返工。
开发者工具 · JSON / 数据格式
JSON 实例→JSON Schema
JSON Schema 将在这里呈现 —— 点「示例」试试API 返回的 JSON 字段类型不确定,手写 Schema 得一遍遍猜。把 JSON 实例粘贴进来,它自动推断类型、枚举值、嵌套结构,输出可直接用于接口文档或校验库。所有解析在浏览器本地完成,数据不上传——调试内部接口时尤其安心。
后端同事交接了十几个 JSON 格式的 API 响应示例,但文档里只写了字段含义,没写 JSON Schema。前端在 TypeScript 里定义类型时,全靠肉眼逐层拆解嵌套对象,一个 5 层深的数组结构能折腾半小时。把示例 JSON 粘贴进工具,立即输出对应的 Schema 定义,直接复制进 .d.ts 文件或 swagger 文档里,类型定义和校验规则一次对齐,免去手动拆解和漏字段的返工。
低代码平台的业务人员拖了一个「员工信息登记」表单,字段包含姓名、邮箱、部门层级(数组)、入职日期。他们只能填示例数据来定义格式,但后端接口要求每个字段的约束(如邮箱正则、日期格式、数组最大长度)必须写成 JSON Schema。把填好的示例 JSON 丢进工具,生成的 Schema 自动推断出 string、number、array 类型,以及 format: 'email'、pattern 等细节,开发直接拿去做前端校验和后端入参校验的基准,省去两方对字段约束的扯皮。
团队要把一个老项目的 REST API 迁移到 OpenAPI 3.0 规范,但 50 多个接口的 requestBody 和 response 只有示例 JSON,没有对应的 schema。人工对照示例写 schema 时,容易漏掉 optional 字段或搞错 enum 枚举值。用工具批量处理每个示例 JSON,输出精确的 schema 结构,再粘贴到 paths 下的 components/schemas 里,确保每个接口的请求和响应都有可校验的 schema 定义,通过 API 网关的契约检查。
DBA 导出了一条 MongoDB 文档的 JSON 格式记录,字段包含 nested 对象和数组。前端团队需要根据这个结构写一个 JSON Schema,用于在表单提交时做客户端校验。人工写 schema 时,对 nested 对象的 required 字段判断容易出错,比如漏掉内层嵌套的必填项。把导出记录粘贴进工具,生成的 schema 自动标记出所有非 null 字段为 required,并保留数组元素的唯一约束,前端直接引用,校验逻辑与数据库结构保持一致。
微服务配置中心里有一个「消息推送配置」的 JSON 结构,包含 channel(string)、retryPolicy(object)、blacklist(array)。运维同学想约束 channel 只能取 'email' 或 'sms',retryPolicy 里 maxAttempts 必须是 1-5 的整数。手动写 JSON Schema 时,对 enum 和 minimum/maximum 的语法不熟,容易写错。把一条完整的示例配置复制进去,工具自动推断出 string 类型并提示可添加 enum,以及 number 类型的 range 约束,生成的 schema 直接贴进配置中心的 schema 字段,实现配置的自动化校验。
| 输入 | 输出 | 说明 |
|---|---|---|
| { "name": "张三", "age": 30, "isStudent": false } | { "type": "object", "properties": { "name": { "type": "string" }, "age": { "type": "integer" }, "isStudent": { "type": "boolean" } }, "required": ["name", "age", "isStudent"] } | 常规:最典型对象结构,包含字符串、整数、布尔三种基本类型,验证属性类型推断和 required 字段自动生成 |
| [ "苹果", "香蕉", "橘子" ] | { "type": "array", "items": { "type": "string" } } | 常规:纯字符串数组,验证数组类型推断和 items 中元素类型一致性处理 |
| null | { "type": "null" } | 边界:null 值作为唯一输入,验证工具对 null 类型的识别(部分实现会报错或返回空对象) |
| {} | { "type": "object", "properties": {} } | 边界:空对象,验证工具对无属性对象的处理(不会错误添加 required 字段) |
| { "id": 1, "id": 2 } | { "type": "object", "properties": { "id": { "type": "integer" } }, "required": ["id"] } | 边界:重复键名,验证工具是否遵循 JSON 规范(后值覆盖前值),只生成单个属性 |
| { "price": 19.99, "count": 100 } | { "type": "object", "properties": { "price": { "type": "number" }, "count": { "type": "integer" } }, "required": ["price", "count"] } | 易错:整数与浮点数区分,验证工具能否正确将 100 识别为 integer 而非 number(部分实现会统一归为 number) |
| { "data": "2023-01-01" } | { "type": "object", "properties": { "data": { "type": "string" } }, "required": ["data"] } | 易错:日期字符串,验证工具不会过度推断为 date 格式(JSON Schema 无原生日期类型,应保留为 string) |
1.JSON 实例末尾有多余逗号,解析失败
{"name": "Alice", "age": 30,}{"name": "Alice", "age": 30}JSON 规范(RFC 8259)禁止对象或数组末尾出现逗号。JavaScript 对象字面量允许,但 JSON 严格不允许,解析器会直接报错。
2.键名未用双引号包裹
{name: "Alice", age: 30}{"name": "Alice", "age": 30}JSON 要求所有键名必须用双引号括起来。无引号或单引号都是 JavaScript 对象字面量语法,不是合法的 JSON。
3.字符串值用了单引号
{"name": 'Alice'}{"name": "Alice"}JSON 字符串必须用双引号。单引号在 JSON 中不是有效的字符串界定符,解析器会将其视为非法字符。
4.布尔值、null 未小写
{"active": True, "deleted": NULL}{"active": true, "deleted": null}JSON 的布尔值和 null 必须全小写(true、false、null)。Python 或 SQL 中的 True/False/None/Null 都不是合法 JSON 字面量。
5.数字值包含前导零
{"id": 0123}{"id": 123}JSON 数字不允许前导零(除非小数部分如 0.5)。0123 会被解析为八进制(某些语言)或直接报错,应去掉前导零。
6.嵌套对象/数组结构不完整
{"list": [1, 2, 3}{"list": [1, 2, 3]}JSON 的括号必须严格配对:对象用 {},数组用 []。花括号和方括号混用或缺失闭合符号会导致解析失败。
7.字符串中包含未转义的控制字符
{"msg": "Hello
World"}{"msg": "Hello\nWorld"}JSON 字符串中,换行符、制表符等控制字符必须转义为 \n、\t 等形式。直接写入字面换行会破坏 JSON 结构。
Schema = { type: typeof(instance) } ∪ (instance 为对象/数组时递归子结构)
instance输入的 JSON 实例,任意合法值typeof(instance)JSON 类型:string/number/boolean/null/object/array子结构对象时 properties 键值对;数组时 items 元素类型输入实例:{"name": "张三", "age": 30, "tags": ["dev", "ops"]}。推导:根为 object → type: "object",properties 含 name(类型 string)、age(类型 number)、tags(类型 array,items 类型 string)。输出 Schema:{"type": "object", "properties": {"name": {"type": "string"}, "age": {"type": "number"}, "tags": {"type": "array", "items": {"type": "string"}}}}。
可以。本工具完全基于你粘贴的 JSON 实例结构进行递归分析,无论多少层嵌套、数组套对象还是对象套数组,都会逐层生成对应的 Schema 定义。如果 JSON 中包含空数组或空对象,Schema 会将其类型标记为 "array" 或 "object" 但不做内部约束,建议手动补充 expected items 或 properties。
因为你的 JSON 实例中该字段的值为 null。本工具严格依据实例值推断类型,null 值会导致类型被推断为 "null"。如果你预期该字段应该是字符串但可能为空,可以在生成的 Schema 中将 type 改为 ["string", "null"],或使用 anyOf 组合。建议在 JSON 实例中给每个字段填入一个非 null 的典型值,这样生成的 Schema 类型会更准确。
可以。JSON 标准允许 key 为任意 Unicode 字符串,包括中文、日文、特殊符号等。本工具直接保留原始 key 名称生成 Schema 中的 property name,不会做转义或编码。需要注意:如果 key 中包含空格或点号,生成的 Schema 在 JSON Schema 规范中仍然是合法的,但在某些编程语言的语法中引用这类 key 可能需要使用方括号语法(如 obj['my key'])。
本工具仅根据单个 JSON 实例的值推断类型和基础格式(如 string、number),不会自动添加 minLength、minimum、maxLength 等边界约束,因为这些信息从单条数据中无法得知。你需要在生成的 Schema 基础上,根据业务需求手动补充约束。例如:如果字段是邮箱,手动添加 "format": "email";如果是手机号,添加 "pattern": "^1[3-9]\\d{9}$"。
本工具默认将整个 JSON 实例视为一个整体,如果输入是一个数组,会生成针对该数组的 Schema(type: array, items: ...)。如果你期望的是数组中每个对象的 Schema,需要先确定数组内所有元素结构是否一致。如果一致,生成的 items 部分就是每个元素的 Schema;如果不一致(异构数组),建议手动拆分为多个 Schema 或使用 oneOf/anyOf 组合。
是的,完全在浏览器本地运行。所有 JSON 解析、类型推断和 Schema 生成逻辑均由前端 JavaScript 完成,没有任何数据发送到后端服务器。你可以断网使用,处理敏感数据(如内部 API 文档、客户信息)时无需担心隐私泄露。关闭页面后,粘贴的内容和生成的 Schema 不会被缓存或记录。
差异通常来自推断策略不同。本工具采用严格类型推断:每个字段的类型完全基于实例值,不会自动合并多种可能(例如实例中字段全是字符串,就不会生成多类型组合)。而有的工具会默认给所有字段加上 "null" 类型或添加额外约束。建议:如果你需要最简洁的 Schema,本工具的结果更直接;如果你需要更宽松的校验(允许 null 或缺失字段),可以手动调整。
本工具采用递归分析,对于几千行的 JSON 通常能秒级处理。但如果 JSON 嵌套极深(超过 100 层)或包含大量重复对象(如数万个元素的数组),可能会短暂卡顿。建议分批测试:先贴一个代表性片段验证结构,确认 Schema 符合预期后再处理完整数据。如果浏览器确实卡死,可以刷新页面重试,或者将 JSON 拆分为多个小文件分别生成。
隐私保证所有计算与处理均在你的浏览器本地完成,输入数据不会上传服务器,也不会保存或共享。