JSON → YAML 转换器，免费

工作原理

1. 粘贴 JSON：输入任意合法的 JSON · 从扁平的键值对到深层嵌套的对象和数组。
2. 即时转换：工具将 JSON 转换为带有正确缩进的 YAML，去除字符串键的引号，并转换 null、布尔值和数字类型。
3. 配置输出：设置缩进宽度（2 或 4 空格），并在集合的块式或流式风格之间选择。
4. 复制 YAML：结果可直接粘贴到配置文件、CI/CD 流水线或 Kubernetes 清单中。

为什么将 JSON 转换为 YAML？

YAML 是基础设施工具（Kubernetes、Docker Compose、GitHub Actions、Ansible 和 Helm charts）首选的配置格式 · 比 JSON 更易读，支持注释，且不要求每个字符串都加引号。将 API 响应、package.json 片段或数据结构从 JSON 转为 YAML 是 DevOps 和后端开发中的常见任务。YAML 的基于缩进的结构对人类阅读更友好，而 JSON 在 API 和程序化生成中更受青睐 · 此转换器架起了两者之间的桥梁。

类型映射

• 字符串 · 尽可能不加引号，含特殊字符时加引号
• 数字 · 直接映射为 YAML 数字标量
• 布尔值 · 在 YAML 中为 true / false
• null · 在 YAML 中为 null 或 ~
• 数组 · 带 - 前缀的 YAML 块序列
• 对象 · 具有键: 值对的 YAML 映射

什么是 JSON 到 YAML 转换?

JSON 到 YAML 转换将键值对树从一种序列化格式翻译为另一种,同时保留底层数据。两种格式描述同样的数据形状(字符串、数字、布尔值、null、数组、对象),但 JSON 使用大括号和中括号,而 YAML 使用缩进和短划线。同一份配置「name: app, version: 1, ports: 80, 443」可以用任何一种表达,转换器在两者之间移动而不丢失含义。

JSON 由 Douglas Crockford 在 2001 年前后发明,并在 2006 年标准化为 RFC 4627,2013 年标准化为 ECMA-404,是 Web API 的通用语言。YAML 1.0(2001)、1.1(2005)和 1.2(2009)由 Clark Evans、Ingy doet Net 和 Oren Ben-Kiki 设计为 JSON 的超集,针对人类可读性优化,支持注释、多行字符串、锚点和别名。现代 DevOps 工具(Kubernetes、Docker Compose、GitHub Actions、Ansible、Helm)默认采用 YAML,因为配置由人类编写和审查。

这个转换器并排配对两种格式。在左侧粘贴 JSON,点击 JSON 到 YAML,右侧面板会以您选择的缩进深度(2 或 4 个空格)更新为有效的 YAML。反向按钮反向运行同样的过程。转换使用从 jsDelivr 加载的 js-yaml 库(Vitaly Puzrin,2011),该库准确地实现了 YAML 1.2 规范,足以往返 Kubernetes 清单、Helm 图表和 OpenAPI 规范。

转换器内部有什么

界面使用双面板网格布局:JSON 在左,YAML 在右。在小于 768 像素的屏幕上,布局垂直堆叠。在面板之上,缩进选择器让您选择每级 2 或 4 个空格。活动选择被高亮显示,缩进适用于两个转换方向。

每个面板有自己的操作按钮。JSON 面板提供 JSON 到 YAML(转换)和清除。YAML 面板提供 YAML 到 JSON(反向)、复制(剪贴板)和下载 .yaml(保存为带 .yaml 扩展名和 UTF-8 编码的文件)。转换器下方的错误横幅会显示带有行号和简短消息的解析错误,所以您可以在不离开工具的情况下修复无效输入。

在底层,JSON 到 YAML 的转换使用 JSON.parse 加上 js-yaml 的 dump 函数。YAML 到 JSON 的方向使用 js-yaml 的 load 函数加上使用 2 空格缩进的 JSON.stringify。两个方向都是输入的纯函数,转换之间不携带状态,刷新页面会重置一切。

历史和背景

Douglas Crockford 规范 JSON(2001)

Douglas Crockford 在 2001 年 4 月在 State Software 工作时记录了 JSON 语法,当时他意识到 JavaScript 的对象字面量语法可以作为一种独立于语言的数据格式。该规范故意保持极简:六种类型、两种集合、没有注释、没有模式。RFC 4627 于 2006 年发布,ECMA-404 于 2013 年发布。极简主义正是使 JSON 在 Web 上无处不在的原因。

YAML 1.0 发布(2001)

Clark Evans、Ingy doet Net 和 Oren Ben-Kiki 在 2001 年 5 月发布了 YAML 1.0,与 JSON 同年。该首字母缩写最初是 Yet Another Markup Language,但被追溯命名为 YAML Ain't Markup Language,以澄清 YAML 针对配置数据,而不是文档标记。1.0 规范雄心勃勃,支持锚点、别名、多文档流、自定义标签和注释。

YAML 1.1 和挪威问题(2005)

YAML 1.1(2005 年 1 月)收紧了规范,但保留了著名的布尔值强制行为,即字符串 yes、no、on、off、y、n、true、false 加上它们的大写变体都变成布尔值。这就是挪威问题:未引用的 ISO 国家代码 NO 变成布尔值 false。该 bug 困扰了早期 Kubernetes 用户,直到 YAML 1.2(2009)删除了替代布尔拼写。

YAML 1.2 声明 JSON 为子集(2009)

YAML 1.2(2009 年 10 月)明确使 JSON 成为 YAML 的严格子集,因此任何有效的 JSON 文档也是有效的 YAML 文档。这是一个重大的设计胜利:处理 YAML 1.2 的工具可以免费解析 JSON,简化了转换器和验证器的实现。今天大多数工具仍在使用的版本是 1.2 或兼容 1.1 的配置文件。

Kubernetes 推出 YAML 清单(2015)

Google 在 2015 年 7 月发布的 Kubernetes 1.0 使用 YAML 清单定义集群资源(Pods、Deployments、Services)。该选择是由习惯于文本编辑器和版本控制的运维团队的可读性驱动的。Helm(2016)在上面添加了模板,GitHub Actions(2018)采用 YAML 作为工作流,Ansible 剧本(2012 至 2018)将 YAML 巩固为占主导地位的 DevOps 配置语言。

js-yaml 成为事实上的 JavaScript 库(2011 年起)

Vitaly Puzrin 在 2011 年发布了 js-yaml,作为 PyYAML 的纯 JavaScript 移植。后续版本(2014 年的 2.0、2015 年的 3.0、2021 年的 4.0)跟踪 YAML 1.2 规范,添加了模式以选择退出危险功能,并达到每周超过 5000 万次 npm 下载。该库由 webpack、parcel 和 esbuild 打包用于任何浏览器端 YAML 工作,这就是这个转换器在底层使用的。

实用工作流

编写 Kubernetes 清单

当您通过 kubectl run --dry-run=client -o json 生成 Pod 或 Deployment 时,会得到 JSON。在此粘贴,点击 JSON 到 YAML,您就有一个准备提交到 git 的清单。转换保留嵌套规范、环境变量和资源限制,与 Kubernetes 读取它们的方式完全一致。

Docker Compose 服务定义

队友给您发送了一个新服务的 JSON 片段。粘贴进来,转换,然后将 YAML 放入您的 docker-compose.yml。2 空格缩进是 Compose 的默认值,所以将缩进选项保持为 2。

GitHub Actions 工作流

当您从基于 JSON 的模板生成器搭建工作流或从 JSON API 响应中复制一个步骤时,在此粘贴并转换。输出直接放入 .github/workflows/*.yml。注意 GitHub Actions 在某些字段中也接受 JSON,但 YAML 是规范形式。

Ansible 剧本

Ansible 清单通常作为从 CMDB 或资产数据库导出的 JSON 开始。粘贴,转换为 YAML,您就有一个符合 Ansible 预期风格的 hosts 文件或剧本头。使用 2 空格缩进以匹配 Ansible 社区风格指南。

Helm chart 值

供应商为其 Helm chart 提供 JSON 示例配置。转换为 YAML 并放入 values.yaml。转换尊重嵌套键(image.repository、image.tag、resources.limits.memory),与 Helm 期望的方式完全一致。

OpenAPI 3 规范

Swagger Editor 以 JSON 和 YAML 两种格式导出 OpenAPI 规范。当工具发出 JSON 但您的团队在版本控制中使用 YAML(或反之亦然)时,这个转换器是切换格式的最快方法,无需启动 Node、Python 或 yq。

常见陷阱

挪威问题(yes、no、on、off 作为布尔值)

在 YAML 1.1 中,字符串 yes、no、on、off、y、n、true、false(以及它们的大写变体)都是布尔值。所以未引用的 ISO 国家代码 NO 变成布尔值 false。js-yaml 4.x 默认使用 YAML 1.2,只将 true 和 false 视为布尔值,但旧的 YAML 解析器仍可能出错。如果您混合工具版本,请显式引用模糊字符串。

制表符不是有效的 YAML 缩进

YAML 使用空格,而不是制表符,作为缩进。如果您的编辑器默认插入制表符,转换后的 YAML 将在 Kubernetes、Helm 或任何严格的 YAML 加载器中解析失败。配置您的编辑器对 .yaml 和 .yml 文件使用 2 或 4 个空格,或在提交前运行 linter(yamllint)。

锚点和别名在 JSON 转换中不会存活

YAML 支持锚点(&name)和别名(*name)以重用值。当您将 YAML 转换为 JSON 时,锚点会内联展开,因为 JSON 没有等效功能。反向 JSON 到 YAML 转换不会自动重新引入锚点。如果您需要锚点,请在转换后手动编写。

多行字符串需要显式指示符

带有嵌入换行符的 JSON 字符串(Hello\nWorld)使用字面块标量(|)或折叠块标量(>)转换为 YAML。js-yaml 选择正确的形式,但如果您手动编辑结果,请记住 | 保留换行符,> 将它们折叠为空格。

大数字会失去精度

JavaScript 数字是 64 位 IEEE 754 浮点数,所以超过 2 的 53 次方(约 9 万亿)的整数在被 JSON.parse 解析时会失去精度。转换为 YAML 保留有损值,而不是原始值。如果您的数据有 BigInt 风格的标识符,请在转换前将它们编码为 JSON 中的字符串。

注释在 YAML 到 JSON 中丢失

YAML 支持 # 注释,JSON 不支持。当您将带注释的 YAML 转换为 JSON 时,注释会被剥离,因为 JSON 没有相应的语法。如果您通过 JSON 进行 YAML 往返处理,预计每行 # 都会丢失。yq 或 ruamel.yaml 等工具可以保留注释,但符合规范的 js-yaml 会删除它们。

隐私和数据处理

所有转换都通过捆绑到页面中的 js-yaml 库在您的浏览器中运行。我们不会将您的 JSON 或 YAML 发送到服务器,不会记录输入,也不会对您转换的内容运行分析。复制按钮使用需要用户手势的 Clipboard API,下载 .yaml 按钮使用内存中的 blob URL,所以文件永远不会通过任何网络往返。

页面加载后(包括 js-yaml CDN 文件),该工具可以离线工作。您可以从网络断开连接,转换敏感配置(API 密钥、数据库 URL、内部服务名称),而不会有任何信息离开您的设备。js-yaml 文件由 jsDelivr 提供,带有 Subresource Integrity 哈希,所以捆绑包不能被悄悄替换。

什么时候不使用这个转换器

流式传输兆字节数据

转换器将整个输入加载到内存中,解析它,并一次性发出结果。对于数兆字节的 JSON 或 YAML 文件,在 shell 管道中使用 yq 或 jq,或在您喜欢的语言中使用流式解析器。浏览器不是 5 到 10 兆字节以上的正确工具。

JSON 中的二进制数据

如果您的 JSON 有必须检查或修改的 Base64 编码二进制 blob,转换为 YAML 不会解包它们。YAML 支持 js-yaml 处理的标记二进制(!!binary),但字节仍是 Base64。使用专用的二进制编辑器进行实际的字节级工作。

模式验证

这个转换器检查输入是否是有效的 JSON 或 YAML,但它不针对模式(JSON Schema、OpenAPI、Kubernetes CRD、Helm 值)验证。如果您需要知道 Kubernetes 清单对于 1.28 集群在结构上是否正确,请运行 kubectl --dry-run=server 或像 kubeval、kubeconform 这样的工具。

模式感知重构

如果您需要在数百个 YAML 文件中重命名字段,或升级 API 版本(apps/v1beta1 到 apps/v1),请使用 sed、ast-grep 或带显式路径查询的 yq。该转换器只在格式之间转换,不编辑语义内容。

更多问题

JSON 比 YAML 更安全吗?

在安全性方面,是的。PyYAML 的 yaml.load(5.1 之前)和类似的宽容解析器可能通过标记的 Python 对象从不受信任的 YAML 输入执行任意代码。JSON 没有这种功能,每个 JSON 解析器在设计上都是安全的。现代 YAML 解析器(PyYAML 5.1+、js-yaml 自 4.0 起)默认为 safe-load,所以差距已经缩小,但对于不受信任的输入,JSON 仍然是更安全的默认选择。

为什么 YAML 选择缩进而不是大括号?

YAML 作者希望配置读起来像大纲,所以他们使用了与 Python 的有意义空格相同的约定。大括号和中括号是有效的 YAML(流式风格),但带有缩进的块式风格是默认的,因为它对在纯文本中编辑的人类来说扫描更自然。权衡是空格变得有意义,这会让自动修剪尾部空格的编辑器陷入困境。

YAML 总是 JSON 的严格超集吗?

自 YAML 1.2(2009)起,是的。任何有效的 JSON 文档也是有效的 YAML 1.2 文档。YAML 1.1 有一些边缘情况(六十进制数字、挪威问题),其中关系较松散。现代 js-yaml 默认使用 1.2,所以超集属性对这个工具成立。

为什么 Kubernetes YAML 这么冗长?

Kubernetes 清单具有固定的顶级形状(apiVersion、kind、metadata、spec),spec 包含反映 API 内部 Go 结构的嵌套对象。冗长是将面向对象 API 映射到平面文本格式的副作用。Kustomize、Helm 和 Pulumi 等工具减少了冗长,但底层 YAML 是 kubectl 实际发送到集群的内容。

我可以通过 YAML 往返 JSON 而不丢失数据吗?

对于大多数 JSON,可以。字符串、数字、布尔值、null、数组、对象都会存活。边缘情况包括非常大的整数(精度损失)、Unicode 代理对(取决于解析器)和键顺序(YAML 可能重新排序)。如果您的 JSON 键必须保持其原始顺序,请使用尊重插入顺序的工具(Python 的 OrderedDict、JavaScript 中的 json-stable-stringify)。

TOML 和 HCL 呢?

TOML(Tom 的明显最小语言,2013 年由 Tom Preston-Werner 创建)由 Cargo(Rust)、pyproject.toml(Python)等使用。HCL(HashiCorp 配置语言,2014)由 Terraform 使用。两者都针对配置用例,但使用不同的语法。这个转换器只处理 JSON 和 YAML。对于 TOML 或 HCL,请使用专用转换器或带有正确插件的 yq。