YAML转JSON转换器

页面内自研解析器：缩进定层级、引号保类型、锚点与多文档给行号报错，标量按 YAML 1.2 core schema 推断并附 1.1 对照。

输入上限 20 万字符；JSON 下载不带 BOM（BOM 会让 JSON.parse 直接报错）。下方类型推断对照表默认 12 行，「加载更多」展开其余行。

标量类型推断对照（本页 = YAML 1.2 core schema；1.1 列为 js-yaml 默认行为）
YAML 写法本页推断YAML 1.1 的行为
123整数 123整数 123（相同）
1e3数值 1000字符串（1.1 浮点必须带小数点）
0x1F4整数 500整数 500（相同）
010十进制 10八进制 8（前导零是八进制）
0755十进制 755八进制 493
0o17八进制 15字符串（1.1 不认 0o 前缀）
1_000_000整数 1000000整数 1000000（下划线相同）
yes字符串 "yes"布尔 true
on字符串 "on"布尔 true
~nullnull（相同）
"true"字符串 true（引号强制）字符串 true（相同）
2026-10-03字符串（不自动转日期）日期对象（timestamp 类型）

使用方法

  1. YAML转JSON转换器打开时就预置了 17 行服务配置示例，点「转换为 JSON」右侧立即出结果，无需任何配置；把你的 YAML 粘进左侧输入框即可替换。
  2. 多行输入时按 Ctrl / Cmd + Enter 也能触发（Enter 留给换行）。输出框的键顺序与原文一致，数值缩进 2 空格。
  3. 看统计条：示例 17 行输入解析出 10 个顶层键，JSON 输出 337 字节——字节数可用于估算写库或传输体积。
  4. 点「下载 JSON 文件」拿到不带 BOM 的 .json，可直接喂给 JSON.parse 或程序配置加载器；点「复制 JSON」走剪贴板。
  5. 解析失败时红色错误区给出「第 N 行 + 原因」：Tab 缩进、缺冒号、锚点、第二个 --- 各有专属文案，按提示改行即可。

YAML转JSON转换器能解决什么问题

第一个场景是配置跨语言消费。Kubernetes 清单、GitHub Actions、docker-compose 都是 YAML，而绝大多数程序运行时要 JSON——把 deployment.yaml 转成 JSON 给脚本、模板引擎或接口传参，是流水线里的高频动作。

第二个场景是排查缩进事故。YAML 对空格敏感而对宽度宽容，报错常发生在几行之外；本页按行号报错并区分「Tab 缩进」「层级跳跃」「缺冒号」，把最常见的那类「看起来一样其实差一个空格」的问题钉死到行。

第三个场景是理解类型歧义。yes 到底是布尔还是字符串？0755 是八进制还是十进制？本页按 YAML 1.2 core schema 推断并同屏给出 1.1 对照表，写跨语言配置时不再被解析器差异暗算。

本页只做 YAML → JSON 单向转换：反向走JSON转YAML转换器；只排版不改语义走YAML格式化；只查语法错不产 JSON 走YAML校验。

原理与规则说明

缩进语义是解析主轴。YAML 用前导空格数表达嵌套，但规范不规定步长——2 空格、4 空格甚至 1 空格都合法，本页按「每层相对缩进」递归下降，同一块内对齐即视为同层。唯一硬禁的是 Tab：a:\n\tb: 1 会在第 2 行报「以 Tab 缩进」，因为 YAML 1.2 规范明确禁止 Tab 用于缩进，而它在编辑器里肉眼不可见，是事故首选来源。同层缩进不一致（比如 2 空格混 3 空格）会报「第 N 行缩进 X 没有对应的父级键」。

标量类型按 YAML 1.2 core schema 推断：布尔只认 true/True/TRUE 与 false/False/FALSE，空值认 null/Null/NULL/~，整数认十进制、0x 十六进制、0o 八进制、0b 二进制，浮点含科学计数。YAML转JSON转换器刻意不认 yes/no/on/off——那是 YAML 1.1 的布尔词表，1.2 已移除；本页把它们当字符串，与 1.1 解析器的结果差异全部列在上面的对照表里。选 1.2 的理由有两个：JSON 里本就没有「yes 布尔」的对应类型，转出 true 反而丢字面量；010 在 1.1 是八进制 8，跨解析器极不一致，按十进制 10 处理最不容易出错。

引号是唯一可靠的类型逃生门。想保住 "500m"、"0755"、"2026-10-03" 的字符串语义，加引号即可，双引号支持 \n、\t 转义，单引号用 '' 表示字面单引号。示例里 cpu: "500m" 若不加引号会被当字符串原样保留（无碍），但 version: "1.30" 不加引号就会变成数值 1.3 丢掉末尾零。

锚点、别名与合并键明确不支持并报错。&anchor 定义、*alias 引用、<<: 合并键是 YAML 的去重机制，自研解析器实现它们的代价是把解析从「单遍下降」变成「两遍求值 + 环检测」，体积会翻倍。本页的取舍是：遇到即报「第 N 行含锚点定义（&name），本页解析器不支持」并给出行号，请先展开为字面值再转换。--- 允许出现在开头（合法的单文档写法），出现第二个即报多文档错误——JSON 一个文件只有一个根，多文档没有对应的 JSON 结构，静默只转第一个文档会把后半段配置无声吞掉。

流式集合按行内语法展开。{ region: hz, zone: a } 与 [api, web] 是块结构的单行等价形式，本页按括号深度与引号状态切分逗号，所以值里带逗号的 a: [1, "x,y"] 不会切错。

完整示例（数值仅作演示）

预置的 17 行示例覆盖了最常出错的五类结构：

整份输出 10 个顶层键、JSON 文本 337 字节，统计条上的两个数字与输出框实际内容一致，可复制出去用 JSON.parse 复核。

输入范围与对照表

本页输入上限 20 万字符（自研解析器是同步递归下降，超长输入会阻塞页面主线程）；嵌套深度实测 40 层无压力，5000 个顶层键解析约 18 毫秒，日常配置文件远碰不到上限。最易踩坑的标量写法对照（工具区表格默认 12 行、可加载更多、可导出 CSV）：

写法常见误以为本页实际推断
yes / no布尔字符串（1.1 才是布尔）
on / off开关布尔字符串
010十进制 10十进制 10（1.1 会给八进制 8）
0755权限八进制十进制 755，要八进制请写 0o755（=493）
1e3字符串数值 1000
~字符串波浪号null
"true"（就是字符串）字符串，引号是唯一强制手段
2026-10-03日期字符串（1.1 才转日期对象）

输入范围、边界与精度说明

数值得失精度只在推断那一步。整数超过 2^53 - 1 = 9007199254740991 后转成 JS Number 会丢精度（例如 9007199254740993 可能读成 ...992），这类大 ID 值请加引号变字符串再转；浮点 1.75 存的是 IEEE 754 双精度，输出与输入在十进制显示上逐位一致，但请记住 0.1 这类小数在二进制里本就不可精确表示，这与本页实现无关，是所有 JSON 处理器的共同边界。

重复键后值覆盖前值。a: 1 与 a: 2 同层出现时按 YAML 实践取后者，输出里只有一个 a: 2。JSON 规范对重复键未定义行为，多数解析器同样保留最后值，所以这不是信息丢失而是两边共同语义。

.inf 与 .nan 被拒收。JSON.stringify 会把 Infinity 与 NaN 静默写成 null——一个看起来成功、实际丢数据的转换比报错糟糕得多。本页在推断阶段就直接报错，提示加引号变字符串或改写为具体数值。

注释按规范剥离：# 出现在行首、或前面是空白时到行尾整体忽略，引号内的 # 不算注释（url: "http://x.com/#frag" 的锚点部分安然无恙）。不含空格的行内 #（如 a: 1#注）按 YAML 规范不算注释起始，会保留在值里。

解析器边界一览：不支持锚点/别名/合并键（报错含行号）；不支持多文档与 ... 结束符；不支持块标量 | 与 >（多行字符串请用引号单行写）；Tab 缩进、缺冒号、层级跳跃、空输入各有专属报错。这些边界全部是刻意的——一个把不支持特性静默吞掉的转换器，产出的 JSON 比报错危险得多。

常见问题

为什么我的 yes 转出来是字符串 "yes" 而不是 true？

本页按 YAML 1.2 core schema 推断，1.2 已把 yes/no/on/off 从布尔词表移除（历史包袱来自 YAML 1.1，网页表单时代被大量误用）。如果你的下游确实期望布尔，把 yes 改写成 true 即可；如果期望保留字面量，本页的行为才是对的。工具区对照表把 1.1 与 1.2 的逐项差异都列了，跨解析器对数前先查那一张表。

带锚点和别名的文件能用吗？我不想手动展开。

本页明确不支持并给出行号报错。锚点把「解析」升级成「求值」：要先登记锚点、再解析引用、还要检测循环引用，体积翻倍换来的便利在配置转换场景里通常一次用不上。临时方案是把 &name 处的值复制到 *name 的位置——报错信息会指出两个行号，对着改半分钟就能展开完。

转换后数字变成了我要的字符串，或反过来，怎么强制？

加引号或去引号。YAML 里引号内永远是字符串，引号外按 1.2 规则推断。典型如版本号 version: "1.30" 必须带引号，否则变数值 1.3；反之 port: "8080" 想要数字就去掉引号。本页不做任何「智能猜测你想要什么」的隐式转换——猜测一旦错了是静默错误，比报错贵得多。

为什么第二个 --- 会报错？我只想转第一个文档。

多文档 YAML 一个文件里有多个独立根节点，而 JSON 一个文件只允许一个根。如果静默只转第一个文档，你拿到的是一个「看起来成功」的 JSON，后面几个文档的数据无声消失——这比明确报错危险得多。要把多文档拆开，先按 --- 切成多份分别转换；转换目标若支持 JSON Lines，那是另一个格式问题。

Tab 缩进到底错在哪，我看着和空格没区别？

区别在不可见与不一致：Tab 展开宽度取决于查看器设置（2/4/8 都有），同一个文件在不同编辑器里「看起来对齐」但空格数完全不同，YAML 1.2 规范因此直接禁止 Tab 作缩进。本页报「第 N 行以 Tab 缩进」。修法：编辑器开「显示空白字符」，把缩进统一替换成 2 或 4 个空格。

输出 JSON 能直接 JSON.parse 吗？会不会带 BOM？

能，且绝无 BOM。复制与下载两条路径都是纯 UTF-8 无 BOM——BOM（U+FEFF）会让 JSON.parse 直接抛 SyntaxError，这是本页在下载按钮上专门强调的细节；CSV 导出相反必须带 BOM，否则 Excel 打开中文乱码。两个格式两个约定，本页按各自的生态惯例处理。

超大 YAML（几万行）转得动吗？

实测 5000 个顶层键约 18 毫秒，几万行也在百毫秒级，性能不是问题；限制是输入框 20 万字符的硬上限，因为解析在页面主线程同步执行，兆级输入会造成可感知的卡顿。真有超大文件，先拆分或只粘贴需要的段落——配置转换很少需要一次性转整仓。

和站内 XML转JSON、TOML转JSON 是什么关系？配置该选哪个格式？

三者是同一族「配置文本 → JSON」的转换器，输入语法不同：XML转JSON转换器处理标签结构，属性与文本节点要映射决策；TOML转JSON转换器处理强类型 TOML，没有缩进歧义；本页处理 YAML 的缩进与类型推断。选格式看团队：CI/K8s 生态用 YAML，Rust/Python 项目配置常用 TOML，需要属性与命名空间时才是 XML。

相关工具