JSON ↔ YAML 转换器 — 在线进行 JSON 与 YAML 的相互转换 _

什么是 JSON ↔ YAML 转换？

JSON（JavaScript Object Notation，RFC 8259）是一种严格的、以花括号为界的结构化数据文本格式；YAML（YAML Ain't Markup Language，1.2 版）是 JSON 的超集，使用缩进、换行与更易读的语法来表达同一套值模型。两者之间的转换可以让同一份配置在机器友好（JSON 用于 API、Schema 校验、程序化变换）与人类友好（YAML 用于代码评审、Kubernetes 清单、GitHub Actions 工作流）之间切换，而无需重新输入任何一个键。

JSON ↔ YAML 转换是如何工作的？

每一次转换都在你的浏览器中使用打包好的 js-yaml（MIT，4.1.0 版）本地运行。主要步骤如下：

1. 模式选择器（自动识别 / JSON → YAML / YAML → JSON）决定运行哪条流水线。在自动识别模式下，由输入中第一个非空白字符决定方向 — { 或 [ 表示 JSON；其它字符则视为 YAML。
2. JSON → YAML：JSON.parse 验证输入并产出一个 JavaScript 值；jsyaml.dump(value, { indent, lineWidth: -1, sortKeys: false }) 写出 YAML 1.2 形式。开启多文档时，输入数组的每个元素会被独立输出为一个文档，并用 --- 分隔符拼接。
3. YAML → JSON：jsyaml.loadAll 解析输入中的每个文档（自动处理 --- 分隔符）并放入数组；单文档输入会被解包，使 JSON 输出就是文档本身，而不是只含一个元素的数组。
4. 缩进（2 或 4 空格）以及美化打印开关均可配置。关闭美化打印时，将通过 JSON.stringify(value) 输出无空白的压缩 JSON。
5. 输出写入只读文本框。YAML 解析失败时，错误信息会包含 js-yaml 在 e.mark 中报告的 1-基准行列号，让你能直接跳到出错位置。

为什么使用此工具进行 JSON 与 YAML 互转？

• 隐私：每一次解析、转换与输出都在你的浏览器中完成。数据 — 包括 Kubernetes Secret、签名后的 JWT、专有配置 — 永远不会到达我们的服务器。
• 多文档 YAML：jsyaml.loadAll 能识别 --- 分隔符并返回文档数组，转换器在单文档场景下自动解包，在多文档场景下保留为 JSON 数组。
• 锚点与别名可解析：YAML 的 &anchor / *alias 机制由 js-yaml 的默认 schema 处理。定义一次、引用两次的值会往返为一个 JSON 对象，其中所有引用持有相等的值。
• 无 CDN、无遥测：js-yaml.min.js 与页面同源加载，因此本工具可在离线环境、企业代理与气隙网络中正常使用。

JSON ↔ YAML 转换的常见应用场景有哪些？

在 DevOps、平台工程与 API 工具链中，JSON 与 YAML 互转随处可见：

• Kubernetes 清单：把 YAML 形式的 Deployment、ConfigMap 或 HelmRelease 转为 JSON，让内部策略校验器（Joi、Ajv、OPA Rego）以编程方式 lint，然后再转回 YAML 提交到集群。
• CI/CD 工作流：把 GitHub Actions 的 workflow.yml 往返通过 JSON，让代码生成器重写矩阵或作业依赖，再将整理后的 YAML 推到 PR。
• OpenAPI 规范：把后端自动生成文档导出的 JSON openapi.json 转为 openapi.yaml，作为人工维护的参考检入仓库。

JSON ↔ YAML 的往返示例长什么样？

粘贴 {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"name":"web"},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"web"}}}} 并在 JSON → YAML 模式下按下转换，会得到 8 行带缩进的 YAML，第一行是 apiVersion: apps/v1。把该 YAML 在 YAML → JSON 模式开启美化打印的情况下喂回去，JSON.stringify(value, null, 2) 会逐字节恢复原对象，键顺序也会被保留 — 因为 js-yaml 的默认 schema 在两个方向上都遵循插入顺序。

这个 JSON ↔ YAML 转换器是完全在我的浏览器中运行的吗？

是的。每次解析、转换与输出都作为 JavaScript 在你的浏览器标签页中本地运行。打包的 js-yaml 库与页面同源加载 — 不使用 CDN，不使用 fetch，不使用 XMLHttpRequest，也不会用 navigator.sendBeacon 上报输入。页面加载后即可离线使用，因为它就是一个把第三方库就近打包的静态 HTML/CSS/JS 包。Kubernetes Secret、JWT 载荷、签名后的 CloudFormation YAML 与专有配置都不会离开你的设备。

转换器如何处理多文档 YAML？

YAML 支持在同一个数据流中放置多个由仅含 --- 的行分隔的文档。在 YAML → JSON 方向，转换器会调用 jsyaml.loadAll，它会把每个文档作为 JavaScript 值返回。若只发现一个文档，JSON 输出直接是该文档；若发现两个或以上，JSON 输出就是数组。在 JSON → YAML 方向，当输入是 JSON 数组且多文档开关开启时，每个数组元素会作为独立文档输出，并在它们之间加入 --- 分隔符 — 这对于从 JSON 资源数组生成可直接 kubectl apply 的 YAML 包很有用。

支持 YAML 的锚点与别名吗？

支持 — &anchor 定义与 *alias 引用都会在加载步骤中由 js-yaml 的默认 schema 解析。形如 defaults: &d\n retries: 3\n timeout: 30\njob_a:\n <<: *d\njob_b:\n <<: *d 的 YAML 会被解析为一个 JSON 对象，其中 job_a 与 job_b 都包含 retries: 3, timeout: 30。合并键 <<（一个 YAML 1.1 扩展，js-yaml 仍然支持）在默认 schema 上同样可用。

YAML 注释在 JSON 与 YAML 之间往返时会被保留吗？

不会 — js-yaml 会在解析步骤中剥离注释，因此 YAML → JSON → YAML 的往返会丢失每一行以 # 开头的注释。这是 load/dump 模型的已知限制；如果保留注释非常重要，请使用注释感知的库（例如 yaml npm 包，它提供为保留 trivia 而设计的 CST + AST API），而不是 js-yaml。对大多数配置转换工作流而言这种取舍是可以接受的：往返后的 YAML 仍然保留所有键、值、锚点与别名，只是不带人工撰写的注释。

自定义 YAML 标签会发生什么？

转换器使用 js-yaml 的 DEFAULT_SCHEMA，能识别 !!str、!!int、!!float、!!bool、!!null、!!seq、!!map、!!binary 与 !!timestamp — 这是 YAML 1.2 core 与 JSON schema 中的全部标签。自定义或特定应用的标签（例如 CloudFormation 的 !Ref、Ansible 的 !vault）不会被识别，并会以清晰的错误信息指出哪个标签不支持。对于 CloudFormation，请先用 aws cloudformation package + --output-template-file 流程展开自定义标签，再粘贴到本转换器。

这个 JSON ↔ YAML 转换器内置了 js-yaml@4.1.0 并与页面同源加载，开箱即用地支持多文档流以及锚点/别名，并以行列号报告 YAML 解析错误，让你能直接修复源文件。无上传、无 CDN、无遥测 — 每一个字节都留在你的浏览器中。