YAML 至 JSON：轻松转换配置

YAML 到 JSON 转换的实际作用

YAML和JSON描述相同的形状——映射、列表、字符串、数字、布尔值和空——因此转换主要是将一种语法重新序列化为另一种语法。变化的是表面：缩进变成大括号，注释消失，锚点变成副本，多行字符串折叠成 `\n` 转义符。这些转换中的每一个都在某种程度上是有损的，这就是为什么转换步骤值得刻意执行，而不是将其视为格式化的事后想法。

转换的实际原因是 JSON 是下一个工具想要的。 Kubernetes 接受 YAML，但 `kubectl`、jq 管道、API 调用和 JavaScript 都可以更轻松地使用 JSON。正确地转换一次，胜过并行手动编辑两种格式。

多文档YAML：无声的第一个文档问题

一个 YAML 文件可以容纳多个以 `---` 分隔的文档。大多数转换器会悄悄地返回第一个并丢弃其余的 - 因此带有 Deployment、Service 和 ConfigMap 的清单包会成为一个对象，而不会发出任何警告。正确的转换要么发出一组文档，要么明确询问您想要哪个文档。如果转换器不提供此类控制，则会丢失数据。

错误应该指向行和列

YAML对空白的容忍度正是小错误难以发现的原因。制表符对于缩进是非法的，缺少冒号会将映射转换为字符串，并且某些解析器会接受重复的键，而其他解析器会拒绝重复的键。当转换失败时，唯一有用的消息会命名行和列并显示有问题的摘录：

                spec:
  containers:
	- name: web      # tab used for indentation
error: line 3, column 0 — tabs cannot be used for indentation
              

重复键是一种危险的情况：YAML 解析器通常保留最后一个值并且什么也不说。如果 `replicas: 3` 出现两次，那么你得到的 JSON 看起来完全有效，但却是错误的数字。

引用旅行中仍然存在的规则

JSON 对字符串的要求比 YAML 更严格，因此转换时会在裸值周围添加引号。这是正常的，但两个 YAML 怪癖会导致真正的错误：`yes`、`no`、`on` 和`off` 在 YAML 1.1 中是布尔值，但在 JSON 语义中是字符串，而邮政编码和电话号码等前导零值在被视为数字时会丢失零。如果字段必须在转换过程中保留字符串，请在源中引用它。

在本地运行它，特别是对于集群配置

Kubernetes 清单通常在 `Secret` 对象中携带凭据、ConfigMap 中的连接字符串以及 CI 文件中的令牌。将它们粘贴到 Web 服务中会将它们传递给您无法控制的服务器。基于浏览器的转换器在您正在阅读的同一选项卡中进行解析和序列化，因此不会传输任何内容 - 并且在网络中断的情况下继续工作的页面是它的证明而不是承诺。

合理的工作流程

1. 首先验证 YAML 并修复任何报告的行、列和摘录。
2. 选择如何处理多文档文件 - 数组或特定文档。
3. 使用与您的代码库样式匹配的缩进（2 或 4 个空格）进行转换，如果您要比较输出，则使用排序键。
4. 将 YAML 保留为 git 中的真实来源，并将 JSON 视为生成的工件；评论仅存在于YAML中。