SQL → JSON 转换器，免费

关于 SQL → JSON 转换

此工具解析 SQL CREATE TABLE 语句并将其转换为 JSON schema 格式。它提取列名、数据类型（INT、VARCHAR、TEXT、BOOLEAN、DATE、TIMESTAMP、DECIMAL）和约束（NOT NULL、PRIMARY KEY、DEFAULT 值）。JSON 输出适合用于 API 文档、数据库设计或迁移工具。

支持的 SQL 数据类型

• INT / INTEGER· 32 位整数值
• VARCHAR(n)· 带最大长度的变长文本
• TEXT· 长度不限的文本
• BOOLEAN / BOOL· 真/假值
• DATE· 不含时间的日历日期
• TIMESTAMP· 带时区支持的日期和时间
• DECIMAL(p,s)· 精确的十进制数

常见问题

支持哪些 SQL 方言？

此转换器处理 MySQL、PostgreSQL、SQL Server 和 SQLite 使用的标准 SQL 语法。方言特有的功能可能无法完全识别。

它处理复杂约束吗？

转换器识别 NOT NULL、PRIMARY KEY、DEFAULT 和基本类型信息。CHECK 或 FOREIGN KEY 等复杂约束会以文本注释形式存储。

可以直接使用 JSON 输出吗？

可以！JSON 输出采用可读格式，可用于 API schema、TypeScript 接口或文档生成器。

模式而非数据：本工具的功能

本转换器接受SQL CREATE TABLE 语句，输出JSON Schema：即列、类型和基本约束的描述，适用于API契约、TypeScript类型生成以及文档存储迁移。它不将 INSERT 行或查询结果集转为JSON。「SQL to JSON」的搜索需求大约各占一半：一类是模式转换，一类是行级转换；如果您期望的是行到对象的转换，则需要另一个工具。模式转换路径是面向开发者的场景：您有一个表定义，需要一个结构化描述供其他工具消费。

SQL简史

20世纪70年代初，SQL由唐纳德·D·钱伯林和雷蒙德·F·博伊斯在IBM圣何塞研究实验室设计。最初的名称是SEQUEL：结构化英语查询语言，作为IBM实验性关系型数据库System R的高层接口而构想。关系模型本身于1970年由埃德加·F·科德发表；钱伯林和博伊斯的贡献是一套普通分析师也能读懂的语法，以自然英语子句（SELECT … FROM … WHERE …）为蓝本，而非科德的代数符号。博伊斯（他的名字也出现在博伊斯-科德范式中）于1974年以26岁英年早逝，未能亲见他共同发明的语言商业化发布。该语言于1975年更名为SQL，原因是与霍克·西德利公司的SEQUEL商标存在冲突，尽管在美国「sequel」的原始读音至今与国际通行的「ess-cue-ell」读法并存。

1986年，ANSI对SQL进行了标准化（SQL-86）；1987年，ISO批准了基本相同的版本（ISO/IEC 9075），此后每三到五年修订一次：SQL-92（仍是大多数教程的基准）、SQL:1999（递归查询、触发器）、SQL:2003（XML类型、MERGE）、SQL:2011（时态表）、SQL:2016（JSON支持），以及最近的SQL:2023（多维数组、属性图查询）。尽管经历了竞争技术的冲击（90年代的对象数据库、2000年代末的NoSQL、2010年代的数据湖），SQL作为结构化数据的主流查询语言已持续了五十余年。到2024年，即便是大多数NoSQL平台也重新引入了SQL或类SQL层（Cassandra的CQL、MongoDB的 $sql 聚合阶段、DynamoDB的PartiQL、Spark SQL、Trino、DuckDB、BigQuery、Snowflake），印证了迈克·斯通布雷克的预言：该语言将比任何单一存储引擎存活更久。

JSON简述

JSON（JavaScript对象表示法）由道格拉斯·克罗克福德于2001年规范化，衍生自JavaScript对象字面量语法的子集，于2013年标准化为ECMA-404，2017年标准化为IETF RFC 8259。它只有六种值类型（字符串、数字、布尔值、null、数组、对象），没有日期、小数、二进制或模式的原生概念。JSON Schema（一个独立的规范，目前处于2020-12草案阶段）在此之上叠加了结构和类型验证。JSON Schema对本转换器的价值在于：它是一种几乎所有现代代码生成器和验证库都理解的可移植、与模式无关的格式。

机械化转换过程

一个典型输入示例：

CREATE TABLE users (
  id INT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  signup_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  is_active BOOLEAN DEFAULT TRUE
);

对应输出：

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "users",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "maxLength": 255 },
    "signup_at": { "type": "string", "format": "date-time" },
    "is_active": { "type": "boolean", "default": true }
  },
  "required": ["id", "email"]
}

逐步解析：对输入进行词法分析，定位 CREATE TABLE 和表名，找到括号内的列列表，在顶层逗号处拆分列定义（对 DECIMAL(10,2) 或 CHECK (x > 0) 等嵌套括号情形保持尊重），将每一列解析为名称+类型+修饰符，然后将SQL类型映射到最接近的JSON Schema类型。NOT NULL 成为 required 数组的成员。DEFAULT 成为 default 值。PRIMARY KEY 通常成为注解或 required 数组的成员。CHECK、FOREIGN KEY、UNIQUE 和索引通常成为文本注解，因为JSON Schema没有直接对应的等价物。

方言问题

SQL是一个方言族群，而非单一语言。即使是基本的标识符引用方式也存在差异：

• MySQL / MariaDB：反引号：`column_name`。
• PostgreSQL及SQL标准，双引号："column_name"。
• SQL Server / MS Access：方括号：[column_name]。
• SQLite：宽容型，以上三种均接受。

类型名称也存在差异。MySQL中的 INT(11) 是显示宽度提示，PostgreSQL会拒绝。PostgreSQL中的 SERIAL 是 INT NOT NULL AUTO_INCREMENT PRIMARY KEY 的简写；IDENTITY 在SQL Server中扮演相同角色；SQLite使用 AUTOINCREMENT。MySQL中 BOOLEAN 底层实际上是 TINYINT(1)。地理类型（GEOMETRY、POINT）、JSON列类型（JSON、JSONB）、数组类型（PostgreSQL的 INTEGER[]）和全文向量类型（pgvector中的 VECTOR(1536)）没有JSON Schema等价物，最终作为不透明的字符串注解处理。BLOB 和 BYTEA 二进制数据没有原生JSON表示；标准做法是base64字符串化，并附带 contentEncoding 提示。

SQL类型与JSON类型的阻抗失配

SQL拥有丰富的类型系统；JSON只有六种值类型，没有模式。需要了解的几点：

• 数值类型：INT、BIGINT、SMALLINT、TINYINT 全部折叠为JSON number。JavaScript和大多数JSON解析器使用IEEE 754双精度浮点数，只能精确表示最大2^53的整数。BIGINT 超出该范围的值在通过JSON解析器往返时会丢失精度。部分流水线将 BIGINT 序列化为带引号的字符串以保留精度；这是一种已知的JSON-API设计模式。
• Decimal/numeric：SQL中的 DECIMAL(10,2) 用于货币，是精确精度类型，但在序列化为JSON数字时会变成有损浮点数，除非序列化为字符串。正因如此，金融API几乎都将货币序列化为十进制字符串（"19.99"）。
• 日期/时间/时间戳：JSON没有原生时态类型。标准惯例是ISO 8601字符串（"2026-05-02T14:30:00Z"），配合JSON Schema的 { "type": "string", "format": "date-time" } 注解。PostgreSQL中的 TIMESTAMP WITH TIME ZONE 保留时区信息；TIMESTAMP WITHOUT TIME ZONE 则不保留，通过JSON往返时通常会抹平这种区别。
• 布尔值：直接映射为 true 和 false。SQL Server的 BIT 通常以1/0形式出现；本转换器将其标准化为 true/false。
• NULL：JSON的 null。值得注意的是，键不存在（{}）与显式null（{"x": null}）在大多数JSON消费方中语义上是有区别的。
• 枚举：SQL的 ENUM('a','b','c') 可以整洁地映射到JSON Schema的 {"enum": ["a","b","c"]}。

适用场景

• 为现有数据库表生成OpenAPI/Swagger模式，用于返回相同结构的API。
• 自举TypeScript/Zod/io-ts类型：一旦拥有JSON Schema，quicktype 或 json-schema-to-typescript 等工具便可自动生成类型定义。
• SQL → MongoDB/Firestore/DynamoDB迁移：通常首先需要的是文档结构列表；JSON Schema是该规划工作的一个清晰中间格式。
• 前端模拟数据：在后端尚未存在时，前端工程师需要行结构的JSON描述，以便通过 faker.js、MSW或 json-server 等工具生成虚假数据。
• 内部数据字典文档：DBT模型文档、设计Wiki、模式即代码仓库均使用表结构的JSON描述。
• 测试夹具生成：基于属性的测试库（hypothesis、fast-check）和工厂库需要预期结构的描述来生成符合规范的测试数据。

现代替代方案

• 数据库原生JSON输出。PostgreSQL有 row_to_json()、json_agg() 和 jsonb_ 系列；MySQL有 JSON_OBJECT() 和 JSON_ARRAYAGG()；SQL Server有 FOR JSON。如果您控制数据库，通常可以完全跳过转换器，直接从查询中输出JSON。
• ORM内省。Prisma、Drizzle、SQLAlchemy、TypeORM、Sequelize-auto等库可以对现有表进行内省，并以各自格式输出类型定义或模式文件，通常比原始JSON Schema更贴近您实际需要的内容。
• 模式即代码工具。Atlas（HCL）、Liquibase（YAML）、Sqitch（SQL）和DBML（数据库标记语言）以各自的DSL描述表结构，拥有比JSON Schema更丰富的约束词汇。

更多问题

如果我的CREATE TABLE包含外键约束，该如何处理？

JSON Schema没有原生外键概念。最简洁的表示方式是使用自定义注解（例如非标准的 x-foreign-key 属性），注明被引用的表和列。本转换器在输出中将关系保留为文本备注；如需完全形式化的引用建模，JSON Schema的 $ref 加独立定义块最为接近，但对于多对多场景略显笨拙。若需更丰富的关系建模，可考虑DBML或Atlas HCL。

为什么输出不包含CHECK约束？

JSON Schema可以表达许多简单的CHECK约束：CHECK (age >= 0) 对应 {"minimum": 0}，CHECK (status IN ('a','b')) 对应 {"enum": ["a","b"]}；但CHECK子句中的任意SQL表达式（函数调用、连接、子查询）没有JSON Schema等价物。转换器会识别简单情形，并将复杂约束保留为文本注解，而非静默丢弃。

可以将INSERT行转为JSON吗？

本工具不行，它只处理模式层面的转换（CREATE TABLE）。对于行级转换，通常推荐使用数据库原生方式：PostgreSQL的 SELECT row_to_json(t) FROM tbl t，MySQL的 JSON_OBJECT()，或导出为CSV后使用CSV转JSON工具。mysqldump --xml 通过管道接XML转JSON转换器是另一条成熟路径。

为什么BIGINT在JSON中会有问题？

JavaScript的 JSON.parse 使用IEEE 754双精度浮点数，只能精确表示最大2^53 = 9,007,199,254,740,992的整数。超出该范围的数字会丢失精度。SQL BIGINT 最大可达2^63 ≈ 9.2×10^18（约920亿亿），远超安全JSON整数范围。在JSON中安全传输BIGINT的跨平台惯例是将其序列化为字符串，并在目标端以BigInt解析；许多API（Twitter/X的推文ID、Stripe ID、PostgreSQL的 bigserial）正是如此实现的。

有任何内容会发送至服务器吗？

不会。解析器在您的浏览器中运行；JSON输出在本地构建。粘贴的SQL永远不会离开您的设备，这一点很重要，因为您的CREATE TABLE语句可能包含专有列名、内部表命名规范或其他您不希望被记录的细节。页面加载后可离线使用。

相关工具