FreeToolsForWeb
帮助请我喝杯咖啡

YAML 验证与检查工具 — 找出错误和隐藏陷阱

验证 YAML，精确给出每个错误的行号和列号，并揪出解析器会默默接受的错误：yes/no 布尔值、制表符、重复键。

16 行
第 15 行第 5 列的 YAML 无效：duplicated mapping key：同一个映射中出现了两次相同的键。
13 image: postgres:16
14 restart: always
15 restart: unless-stopped
^
检查结果（5）
services:
  web:
    image: nginx:1.27
    ports:
      - '8080:80'
      - '22:22'
    environment:
      COUNTRY: 'NO'
      DEBUG: 'yes'
      APP_VERSION: 1.1
  db:
    image: postgres:16
    restart: unless-stopped

存在重复键：按最后一个值生效显示，这也是许多解析器默认的静默处理方式。 格式化视图是根据解析后的数据重建的，因此不会保留注释和锚点。请在原始文件中修复问题。

完全在你的浏览器中运行。你的 YAML 绝不会被上传，配置文件中的密钥始终留在你的电脑上。 浏览全部免费工具.

发现问题，或者觉得哪里可以更好？每条消息我们都会阅读，并尽快修复。

这款免费的 YAML 验证器检查 YAML 文件的语法错误，并显示确切的行号和列号，附带上下文行，并在问题位置下方标出插入符号。粘贴 Kubernetes 清单、docker-compose.yml、GitHub Actions 工作流或 OpenAPI 规范，一秒钟就能知道它能否解析，如果不能，又是在哪里出了问题。

解析器接受你的文件，并不等于文件的含义就是你以为的那样。检查工具还会标出那些 YAML 1.1 解析器（PyYAML、SnakeYAML、Go yaml.v2）与 YAML 1.2 解读不同的值：NO 变成 false，0755 变成 493，22:22 变成 1342，1.10 变成 1.1。它会列出所有重复键及其两处行号、缩进中的制表符，以及冒号后没有空格的“key:value”。它检查的是语法和这些陷阱，不会按 Kubernetes API 等 schema 进行验证。

使用方法

  1. 把 YAML 粘贴到编辑器中。页面预载了一个故意带有几处错误的 docker-compose 示例，用来展示会被标出的问题。
  2. 查看状态栏：绿色表示有效，红色显示错误及其行号和列号，以及周围的几行。
  3. 点击检查列表中的任意一项，跳转到编辑器中对应的行进行修改。
  4. 在格式化的 YAML 视图和 JSON 视图之间切换，检查文件实际是如何被解析的：yes/no 或 0755 带来的意外在这里一目了然。
  5. 如有需要，复制或下载格式化后的输出；修改时请继续在原文件上进行，这样注释才能保留。

常见问题

什么是 YAML 的“挪威问题”？

在 YAML 1.1 中，不加引号的 y、yes、n、no、on 和 off（各种常见大小写形式）都是布尔值。所以一个包含挪威代码 NO 的国家代码列表，得到的是 false，而不是字符串“NO”。YAML 1.2（2009 年）修正了这个问题：只有 true 和 false 是布尔值。许多广泛使用的解析器仍遵循 1.1，包括 PyYAML、Ruby 的 Psych、Java 的 SnakeYAML 和 Go 的 yaml.v2，所以稳妥的做法是给这类值加上引号："NO"、"yes"、"on"。

为什么 YAML 不允许使用制表符？

YAML 规范禁止用制表符缩进，因为制表符的宽度没有定义，而缩进正是 YAML 表达结构的方式。制表符可以出现在值和注释中，只是不能出现在行首的空白里。请把编辑器设置为在 .yml 和 .yaml 文件中插入空格；每级两个空格是最常见的约定。

YAML 中允许重复键吗？

不允许。YAML 规范要求映射中的键必须唯一，但各解析器的处理方式不一：有的会报错（本验证器就是如此），有的则悄悄保留最后一个值。这让重复键非常危险：在很长的清单中，你修改了第一次出现的键，却看不到任何效果。本工具会列出每个重复键，以及该键首次定义所在的行。

为什么我的 YAML 提示“bad indentation of a mapping entry”？

要么是该行的缩进与同级的其他键不一致，要么是某个值中包含冒号加空格，需要加引号。例如 title: Note: read this 会失败，因为解析器会以为有第二个键。应写成 title: "Note: read this"。检查报错的那一行及其上一行；错误常常始于上一行。

YAML 是 JSON 的超集吗？

YAML 1.2 的设计目标是让有效的 JSON 同时也是有效的 YAML，实际上任何 JSON 文档都能在这里解析。反过来则不成立：YAML 增加了注释、锚点和别名、多行字符串以及单文件多文档。用 JSON 视图可以查看 YAML 文件如何对应到普通的 JSON 数据。

能验证 Kubernetes 或 GitHub Actions 的 schema 吗？

不能。它检查 YAML 语法和上述陷阱——大多数实际故障都源于这些——但它不知道 Kubernetes Deployment 或 GitHub 工作流允许哪些键。如需 schema 验证，请使用 kubectl apply --dry-run=server、kubeconform，或在 VS Code 的 YAML 扩展中配合相应的 JSON Schema。

YAML 1.1 与 YAML 1.2：含义会改变的值

本验证器按 YAML 1.2 规则（js-yaml）解析。如果你的文件由 YAML 1.1 解析器读取，以下不加引号的值含义会不同，检查工具会对每一个发出警告：

• yes、no、on、off、y、n → 在 1.1 中是布尔值，在 1.2 中是字符串。GitHub Actions 工作流以 on: 开头，1.1 解析器会把它读成键 true。

• 0755 → 在 1.1 中是八进制 493，在 1.2 中是十进制 755。文件权限和以零开头的邮政编码都会受影响。

• 22:22 → 在 1.1 中是 1342（六十进制），在 1.2 中是字符串“22:22”。Docker Compose 文档建议给端口映射加引号，正是出于这个原因。

• 1.10 → 在两个版本中都是数字 1.1。版本号请加引号。

• 2024-01-05 → 在大多数解析器中是时间戳，而不是字符串。

避开所有这些问题的规则：任何本意是文本、看起来却像别的东西的值，都加上引号。

常见 YAML 错误及修复方法

• “bad indentation of a mapping entry”：缩进不一致，或未加引号的值中包含“: ”。

• “end of the stream or a document separator is expected”：通常是某一行的缩进比同级少，或者闭合引号后面还有文字。

• “can not read a block mapping entry; a multiline key may not be an implicit key”：通常是上一行缺少冒号，或者有引号打开后没有闭合。

• “unexpected end of the stream within a double quoted scalar”：报错行上方某处有一个未闭合的 "。

• 以 @、`、*、&、!、| 或 > 开头的值具有特殊含义或为保留字符。请加引号。

• 前面有空格的 # 表示注释开始，所以 password: abc #123 存储的是 abc。包含“ #”的值请加引号。

相关免费工具

  • JSON 格式化 — 格式化、压缩和校验 JSON，解析错误精确到行和列。在浏览器中运行，无需上传。
  • JSON 转 TypeScript — 粘贴 JSON 示例，即可得到 TypeScript 接口、Zod 模式、JSON Schema，或 Go、Python、Java、C#、Kotlin、Swift 和 Rust 的类型定义。
  • SQL 格式化 — 把杂乱的 SQL 格式化为可读、缩进一致的查询，支持 PostgreSQL、MySQL、T-SQL、BigQuery 等。在浏览器中运行。
  • 正则表达式测试 — 用示例文本测试正则表达式，实时高亮匹配结果，显示捕获组并预览替换效果。免费，在浏览器中运行。
  • 文本对比（Diff） — 比较文本、代码或 JSON 文件的两个版本，准确看出哪些行、词和字符发生了变化。