YAML Ain’t Markup Language version 1.2
- YAML Ain’t Markup Language (YAML™) version 1.2
- Chapter 1. Introduction to YAML 第1章YAML简介
- Chapter 2. Language Overview 第2章语言概述
- Chapter 3. Processes and Models 第3章.流程和模型
- Chapter 4. Syntax Conventions 第4章：语法约定
- Chapter 5. Character Productions 第5章：角色制作
- Chapter 6. Structural Productions
- Chapter 7. Flow Style Productions
- Chapter 8. Block Style Productions
YAML Ain’t Markup Language (YAML™) version 1.2
YAML不是标记语言（YAML™）版本1.2
Revision 1.2.2 (2021-10-01) 修订版1.2.2（2021-10-01）
This document may be freely copied, provided it is not modified.
本文件可自由复制，但不得修改。
Status of this Document 本文档的状态
This is the YAML specification v1.2.2. It defines the YAML 1.2 data
language. There are no normative changes from the YAML specification
v1.2. The primary objectives of this revision are to correct errors and add
clarity.
这是YAML规范v1.2.2。它定义了YAML 1.2数据语言。与YAML规范v1.2相比，没有规范性变更。本次修订的主要目的是纠正错误并增加清晰度。
This revision also strives to make the YAML language development process more
open, more transparent and easier for people to contribute to. The input
format is now Markdown instead of DocBook, and the images are made from plain
text LaTeX files rather than proprietary drawing software. All the source
content for the specification is publicly
hosted2.
此次修订还努力使YAML语言开发过程更加开放，更加透明，更容易让人们做出贡献。输入格式现在是Markdown而不是DocBook，图像是由纯文本LaTeX文件而不是专有绘图软件制作的。规范的所有源内容都是公开托管的。
The previous YAML specification3
was published 12 years ago. In that time span, YAML’s popularity has grown
significantly. Efforts are ongoing to improve the language and grow it to meet
the needs and expectations of its users. While this revision of the
specification makes no actual changes to YAML, it begins a process by which
the language intends to evolve and stay modern.
之前的YAML规范发布于12年前。在这段时间里，YAML的受欢迎程度显著增长。目前正在努力改进这门语言，使其满足用户的需求和期望。虽然规范的这个修订版没有对YAML进行实际更改，但它开始了一个过程，通过这个过程，语言打算发展并保持现代化。
The YAML specification is often seen as overly complicated for something which
appears to be so simple. Even though YAML often is used for software
configuration, it has always been and will continue to be a complete data
serialization language. Future YAML plans are focused on making the language
and ecosystem more powerful and reliable while simultaneously simplifying the
development process for implementers.
YAML规范通常被视为过于复杂的东西，似乎是如此简单。尽管YAML经常用于软件配置，但它一直是并将继续是一种完整的数据序列化语言。未来的YAML计划专注于使语言和生态系统更加强大和可靠，同时简化实现者的开发过程。
While this revision of the specification is limiting itself to informational
changes only, there is companion documentation intended to guide YAML
framework implementers and YAML language users. This documentation can
continue to evolve and expand continually between published revisions of this
specification.
虽然此规范的修订仅限于信息性更改，但有配套文档旨在指导YAML框架实现者和YAML语言用户。本文档可以在本规范的发布版本之间不断发展和扩展。
See:
- YAML Resources Index YAML资源索引
- YAML Vocabulary Glossary YAML词汇表
- YAML Specification Changes YAML规范变更
- YAML Specification Errata YAML规范勘误表
Abstract
YAML™ (rhymes with “camel”) is a human-friendly, cross language, Unicode based
data serialization language designed around the common native data types of
dynamic programming languages. It is broadly useful for programming needs
ranging from configuration files to internet messaging to object persistence
to data auditing and visualization. Together with the Unicode standard for
characters4, this specification
provides all the information necessary to understand YAML version 1.2 and to
create programs that process YAML information.
YAML™（与“camel”押韵）是一种人性化的，跨语言的，基于Unicode的数据序列化语言，围绕动态编程语言的常见本地数据类型设计。它广泛适用于从配置文件到Internet消息传递到对象持久化到数据审计和可视化的编程需求。与字符的Unicode标准一起，本规范提供了理解YAML版本1.2和创建处理YAML信息的程序所需的所有信息。
Chapter 1. Introduction to YAML 第1章YAML简介
YAML (a recursive acronym for “YAML Ain’t Markup Language”) is a data
serialization language designed to be human-friendly and work well with modern
programming languages for common everyday tasks. This specification is both an
introduction to the YAML language and the concepts supporting it. It is also a
complete specification of the information needed to develop
applications for
processing YAML.
YAML（YAML Ain’t Markup Language的递归缩写）是一种数据序列化语言，旨在对人类友好，并与现代编程语言一起工作，用于常见的日常任务。本规范既是对YAML语言及其支持概念的介绍。它也是开发处理YAML的应用程序所需信息的完整规范。
Open, interoperable and readily understandable tools have advanced computing
immensely. YAML was designed from the start to be useful and friendly to
people working with data. It uses Unicode
printable characters,
some of which provide
structural information and the rest containing the data itself. YAML achieves
a unique cleanness by minimizing the amount of structural characters and
allowing the data to show itself in a natural and meaningful way. For example,
indentation may be used for
structure, colons separate
key/value pairs and
dashes are used to create
“bulleted” lists.
开放、可互操作和易于理解的工具极大地促进了计算。YAML从一开始就被设计成对处理数据的人有用和友好。它使用Unicode可打印字符，其中一些提供结构信息，其余包含数据本身。YAML通过最小化结构字符的数量并允许数据以自然和有意义的方式显示自己来实现独特的清洁性。例如，缩进可以用于结构，冒号分隔键/值对，破折号用于创建“项目符号”列表。
There are many kinds of data structures,
but they can all be adequately [represented](https://yaml.org/spec/1.2.2
/#representation-graph) with three basic primitives:
mappings (hashes/dictionaries),
sequences (arrays/lists) and
scalars (strings/numbers). YAML
leverages these primitives and adds a simple typing system and
aliasing mechanism to form
a complete language for [serializing](https://yaml.org/spec/1.2.2
/#serializing-the-representation-graph) any native data
structure.
While most programming languages can use YAML for data serialization, YAML
excels in working with those languages that are fundamentally built around the
three basic primitives. These include common dynamic languages such as
JavaScript, Perl, PHP, Python and Ruby.
有许多种数据结构，但它们都可以用三个基本原语充分表示：映射（哈希/字典）、序列（数组/列表）和标量（字符串/数字）。YAML利用这些原语，并添加了一个简单的类型化系统和别名机制，以形成一个完整的语言，用于序列化任何本地数据结构。虽然大多数编程语言都可以使用YAML进行数据序列化，但YAML在与基本上围绕三个基本原语构建的语言一起工作时表现出色。这些包括常见的动态语言，如JavaScript，Perl，PHP，Python和Ruby。
There are hundreds of different languages for programming, but only a handful
of languages for storing and transferring data. Even though its potential is
virtually boundless, YAML was specifically created to work well for common use
cases such as: configuration files, log files, interprocess messaging, cross-
language data sharing, object persistence and debugging of complex data
structures. When data is easy to view and understand, programming becomes a
simpler task.
有数百种不同的编程语言，但只有少数语言用于存储和传输数据。尽管YAML的潜力几乎是无限的，但它是专门为常见用例而创建的，例如：配置文件、日志文件、进程间消息传递、跨语言数据共享、对象持久化和复杂数据结构的调试。当数据易于查看和理解时，编程就变得更简单了。
1.1. Goals
The design goals for YAML are, in decreasing priority:
YAML的设计目标是（优先级递减）：
-
YAML should be easily readable by humans.
YAML应该很容易被人类阅读。 -
YAML data should be portable between programming languages.
YAML数据应该在编程语言之间可移植。 -
YAML should match the native data structures of dynamic languages.
YAML应该与动态语言的原生数据结构相匹配。 -
YAML should have a consistent model to support generic tools.
YAML应该有一个一致的模型来支持通用工具。 -
YAML should support one-pass processing.
YAML应该支持一遍处理。 -
YAML should be expressive and extensible.
YAML应该具有表达性和可扩展性。 -
YAML should be easy to implement and use.
YAML应该易于实现和使用。
1.2. YAML History 1.2. YAML历史
The YAML 1.0 specification was published in early 2004 by by Clark Evans, Oren
Ben-Kiki, and Ingy döt Net after 3 years of collaborative design work through
the yaml-core mailing list5. The
project was initially rooted in Clark and Oren’s work on the SML-
DEV6 mailing list (for simplifying
XML) and Ingy’s plain text serialization
module7 for Perl. The language took
a lot of inspiration from many other technologies and formats that preceded
it.
YAML 1.0规范于2004年初由Clark Evans、Oren Ben-Kiki和Ingy döt Net通过yaml-core邮件列表进行了3年的协作设计工作后发布。该项目最初植根于Clark和Oren在SML-DEV邮件列表（用于简化XML）和Ingy的Perl纯文本序列化模块上的工作。该语言从之前的许多其他技术和格式中汲取了很多灵感。
The first YAML framework was written in Perl in 2001 and Ruby was the first
language to ship a YAML framework as part of its core language distribution in
2003.
第一个YAML框架是在2001年用Perl编写的，Ruby是第一个在2003年将YAML框架作为其核心语言发行版的一部分的语言。
The YAML 1.18 specification was
published in 2005. Around this time, the developers became aware of
JSON9. By sheer coincidence, JSON was
almost a complete subset of YAML (both syntactically and semantically).
YAML 1.1 8
规范于2005年发布。大约在这个时候，开发人员开始意识到JSON。巧合的是，JSON几乎是YAML的一个完整子集（无论是语法还是语义）。
In 2006, Kyrylo Simonov produced
PyYAML10 and
LibYAML11. A lot of the YAML
frameworks in various programming languages are built over LibYAML and many
others have looked to PyYAML as a solid reference for their implementations.
2006年，Kyrylo Simonov开发了PyYAML 10
和LibYAML 11
。各种编程语言中的许多YAML框架都是基于LibYAML构建的，许多其他语言都将PyYAML作为其实现的坚实参考。
The YAML 1.23 specification was
published in 2009. Its primary focus was making YAML a strict superset of
JSON. It also removed many of the problematic implicit typing recommendations.
YAML 1.2 3
规范于2009年发布。它的主要重点是使YAML成为JSON的严格超集。它还删除了许多有问题的隐式类型建议。
Since the release of the 1.2 specification, YAML adoption has continued to
grow, and many large-scale projects use it as their primary interface
language. In 2020, the new YAML language design
team began meeting regularly to discuss
improvements to the YAML language and specification; to better meet the needs
and expectations of its users and use cases.
自1.2规范发布以来，YAML的采用率持续增长，许多大型项目将其作为主要的接口语言。2020年，新的YAML语言设计团队开始定期开会，讨论对YAML语言和规范的改进;以更好地满足其用户和用例的需求和期望。
This YAML 1.2.2 specification, published in October 2021, is the first step in
YAML’s rejuvenated development journey. YAML is now more popular than it has
ever been, but there is a long list of things that need to be addressed for it
to reach its full potential. The YAML design team is focused on making YAML as
good as possible.
YAML1.2.2规范于2021年10月发布，是YAML复兴开发之旅的第一步。YAML现在比以往任何时候都更受欢迎，但要充分发挥其潜力，需要解决一长串问题。YAML设计团队专注于使YAML尽可能好。
1.3. Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in RFC 211912.
本文档中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“推荐”、“可能”和“可选”应按照RFC 2119中的描述进行解释。
The rest of this document is arranged as follows. Chapter2 provides a short preview
of the main YAML features. Chapter [3](https://yaml.org/spec/1.2.2/#processes-
and-models) describes the YAML information model and the processes for
converting from and to this model and the YAML text format. The bulk of the
document, chapters 4,
5,
6,
7,
8 and
9, formally define
this text format. Finally, chapter [10](https://yaml.org/spec/1.2.2
/#recommended-schemas) recommends basic YAML schemas.
本文件的其余部分安排如下。第2章简要介绍了YAML的主要特性。第3章描述了YAML信息模型以及在此模型和YAML文本格式之间进行转换的过程。本文件的大部分，第4、5、6、7、8和9章，正式定义了这种文本格式。最后，第10章推荐基本的YAML模式。
Chapter 2. Language Overview 第2章语言概述
This section provides a quick glimpse into the expressive power of YAML. It is
not expected that the first-time reader grok all of the examples. Rather,
these selections are used as motivation for the remainder of the
specification.
本节将快速了解YAML的表达能力。第一次阅读的读者不可能理解所有的例子。相反，这些选择被用作说明书的其余部分的动机。
2.1. Collections
YAML’s [block collections](https://yaml.org/spec/1.2.2/#block-collection-
styles) use indentation for
scope and begin each entry on its own line. Block
sequences indicate each entry
with a dash and space (“- ”).
Mappings use a colon and space (“: ”) to mark each key/value pair.
Comments begin with an octothorpe
(also called a “hash”, “sharp”, “pound” or “number sign” - “#”).
YAML的块集合使用缩进表示作用域，并在其自己的行上开始每个条目。 块序列用破折号和空格（“ - ”）指示每个条目。 映射使用冒号和空格（“ :
”）来标记每个键/值对。 注释以一个octothorpe（也称为“hash”，“sharp”，“磅”或“number sign”-“ # ”）开始。
Example 2.1 Sequence of Scalars (ball players)
例2.1标量序列（球员）
- Mark McGwire
- Sammy Sosa
- Ken Griffey
Example 2.2 Mapping Scalars to Scalars (player statistics)
例2.2标量到标量的映射（玩家统计）
hr: 65 # Home runs
avg: 0.278 # Batting average
rbi: 147 # Runs Batted In
Example 2.3 Mapping Scalars to Sequences (ball clubs in each league)
例2.3将标量映射到序列（每个联赛中的球俱乐部）
american:
- Boston Red Sox
- Detroit Tigers
- New York Yankees
national:
- New York Mets
- Chicago Cubs
- Atlanta Braves
Example 2.4 Sequence of Mappings (players’ statistics)
示例2.4映射序列（玩家统计）
-
name: Mark McGwire
hr: 65
avg: 0.278
-
name: Sammy Sosa
hr: 63
avg: 0.288
YAML also has [flow styles](https://yaml.org/spec/1.2.2/#flow-style-
productions), using explicit [indicators](https://yaml.org/spec/1.2.2
/#indicator-characters) rather than [indentation](https://yaml.org/spec/1.2.2
/#indentation-spaces) to denote scope. The flow
sequence is written as a
comma separated list
within square
brackets. In a similar manner,
the flow mapping uses
curly
braces.
YAML也有流样式，使用显式指示符而不是缩进来表示范围。流序列被写为一个逗号分隔的列表在广场 括号。以类似的方式，流映射使用curly 牙套
Example 2.5 Sequence of Sequences
实施例2.5序列的序列
- [name , hr, avg ]
- [Mark McGwire, 65, 0.278]
- [Sammy Sosa , 63, 0.288]
Example 2.6 Mapping of Mappings 示例2.6映射的映射
Mark McGwire: {hr: 65, avg: 0.278}
Sammy Sosa: {
hr: 63,
avg: 0.288,
}
2.2. Structures
YAML uses three dashes (“---”) to separate
directives from
document
content. This also serves to signal the
start of a document if no
directives are present. Three dots
( “...”) indicate the end of a document without starting a new one, for use
in communication channels.
YAML使用三个破折号（“ --- ”）将指令与文档分隔开 内容如果没有指令，这也可以用来表示文档的开始。三个点（“ ...
”）表示文档的结尾，没有开始新的文档，用于通信渠道。
Example 2.7 Two Documents in a Stream (each with a leading comment)
示例2.7流中的两个文档（每个文档都有一个前导注释）
# Ranking of 1998 home runs
---
- Mark McGwire
- Sammy Sosa
- Ken Griffey
# Team ranking
---
- Chicago Cubs
- St Louis Cardinals
Example 2.8 Play by Play Feed from a Game
示例2.8来自游戏的逐场播放源
---
time: 20:03:20
player: Sammy Sosa
action: strike (miss)
...
---
time: 20:03:47
player: Sammy Sosa
action: grand slam
...
Repeated nodes (objects) are first
identified by an
anchor (marked with the
ampersand - “&”) and are then [aliased](https://yaml.org/spec/1.2.2
/#anchors-and-aliases) (referenced with an asterisk - “*”) thereafter.
重复的节点（对象）首先由锚（用&标记-“ & ”）标识，然后在其后被别名化（用星号-“ * ”引用）。
Example 2.9 Single Document with Two Comments
示例2.9带有两个注释的单个文档
---
hr: # 1998 hr ranking
- Mark McGwire
- Sammy Sosa
# 1998 rbi ranking
rbi:
- Sammy Sosa
- Ken Griffey
Example 2.10 Node for “Sammy Sosa” appears twice in this document
例2.10“ Sammy Sosa ”节点在本文档中出现两次
---
hr:
- Mark McGwire
# Following node labeled SS
- &SS Sammy Sosa
rbi:
- *SS # Subsequent occurrence
- Ken Griffey
A question mark and space (“? ”) indicate a complex
mapping
key. Within a block
collection, key/value
pairs can start immediately following
the dash,
colon or question
mark.
问号和空格（“ ? ”）表示复杂的映射 钥匙。在块集合中，键/值对可以紧接在破折号、冒号或问号之后开始。
Example 2.11 Mapping between Sequences
示例2.11序列之间的映射
? - Detroit Tigers
- Chicago cubs
: - 2001-07-23
? [ New York Yankees,
Atlanta Braves ]
: [ 2001-07-02, 2001-08-12,
2001-08-14 ]
Example 2.12 Compact Nested Mapping
示例2.12紧凑嵌套映射
---
# Products purchased
- item : Super Hoop
quantity: 1
- item : Basketball
quantity: 4
- item : Big Shoes
quantity: 1
2.3. Scalars
Scalar content can be written in
block notation, using a literal
style (indicated by “|”) where
all line breaks are
significant. Alternatively, they can be written with the folded
style (denoted by “>”) where
each line break is
folded to a
space unless it ends an
empty or a more-
indented line.
标量内容可以用块表示法编写，使用文字样式（由“ | ”表示），其中所有换行符都是重要的。或者，它们可以用折叠样式（用“ >
”表示）书写，其中每个换行符被折叠成空格，除非它结束于一个空行或更多缩进的行。
Example 2.13 In literals, newlines are preserved
例2.13在文字中，换行符被保留
# ASCII Art
--- |
\//||\/||
// || ||__
Example 2.14 In the folded scalars, newlines become spaces
例2.14在折叠标量中，换行符变成空格
--- >
Mark McGwire's
year was crippled
by a knee injury.
Example 2.15 Folded newlines are preserved for “more indented” and blank
lines
例2.15折叠的换行符被保留用于“更多缩进”和空白行
--- >
Sammy Sosa completed another
fine season with great stats.
63 Home Runs
0.288 Batting Average
What a year!
Example 2.16 Indentation determines scope
例2.16缩进确定范围
name: Mark McGwire
accomplishment: >
Mark set a major league
home run record in 1998.
stats: |
65 Home Runs
0.278 Batting Average
YAML’s flow scalars include
the plain style (most examples
thus far) and two quoted styles. The double-quoted
style provides escape
sequences. The single-
quoted style is useful when
escaping is not needed. All
flow scalars can span
multiple lines; [line breaks](https://yaml.org/spec/1.2.2/#line-break-
characters) are always folded.
YAML的流标量包括普通样式（到目前为止的大多数示例）和两个引用样式。双引号样式提供转义序列。单引号样式在不需要转义时很有用。所有的流量标量都可以跨越多条线;换行符始终是折叠的。
Example 2.17 Quoted Scalars 例2.17引用标量
unicode: "Sosa did fine.\u263A"
control: "\b1998\t1999\t2000\n"
hex esc: "\x0d\x0a is \r\n"
single: '"Howdy!" he cried.'
quoted: ' # Not a ''comment''.'
tie-fighter: '|\-*-/|'
Example 2.18 Multi-line Flow Scalars
例2.18多线流量标量
plain:
This unquoted scalar
spans many lines.
quoted: "So does this
quoted scalar.\n"
2.4. Tags
In YAML, untagged nodes are
given a type depending on the [application](https://yaml.org/spec/1.2.2
/#processes-and-models). The examples in this specification generally use the
seq, map and str types from the fail safe
schema. A few examples also use
the int, float and null types from the JSON
schema.
在YAML中，根据应用程序，未标记的节点被赋予一个类型。本说明书中的示例通常使用来自故障安全模式的 seq 、 map 和 str
类型。一些示例还使用了JSON模式中的 int 、 float 和 null 类型。
Example 2.19 Integers 例2.19整数
canonical: 12345
decimal: +12345
octal: 0o14
hexadecimal: 0xC
Example 2.20 Floating Point 示例2.20浮点数
canonical: 1.23015e+3
exponential: 12.3015e+02
fixed: 1230.15
negative infinity: -.inf
not a number: .nan
Example 2.21 Miscellaneous 实施例2.21其他
null:
booleans: [ true, false ]
string: '012345'
Example 2.22 Timestamps 示例2.22时间戳
canonical: 2001-12-15T02:59:43.1Z
iso8601: 2001-12-14t21:59:43.10-05:00
spaced: 2001-12-14 21:59:43.10 -5
date: 2002-12-14
Explicit typing is denoted with a tag
using the exclamation point (“!”) symbol. Global
tags are URIs and may be specified in a
tag shorthand notation using a
handle.
Application-specific
local tags may also be used.
显式类型化用一个使用感叹号（“ ! ”）符号的标记来表示。 全局标记是URI，并且可以使用句柄以标记简写表示法来指定。 还可以使用应用特定的本地标签。
Example 2.23 Various Explicit Tags
例2.23各种显式标签
---
not-date: !!str 2002-04-28
picture: !!binary |
R0lGODlhDAAMAIQAAP//9/X
17unp5WZmZgAAAOfn515eXv
Pz7Y6OjuDg4J+fn5OTk6enp
56enmleECcgggoBADs=
application specific tag: !something |
The semantics of the tag
above may be different for
different documents.
Example 2.24 Global Tags 示例2.24全局标签
%TAG ! tag:clarkevans.com,2002:
--- !shape
# Use the ! handle for presenting
# tag:clarkevans.com,2002:circle
- !circle
center: &ORIGIN {x: 73, y: 129}
radius: 7
- !line
start: *ORIGIN
finish: { x: 89, y: 102 }
- !label
start: *ORIGIN
color: 0xFFEEBB
text: Pretty vector drawing.
Example 2.25 Unordered Sets 例2.25无序集合
# Sets are represented as a
# Mapping where each key is
# associated with a null value
--- !!set
? Mark McGwire
? Sammy Sosa
? Ken Griffey
Example 2.26 Ordered Mappings 例2.26有序映射
# Ordered maps are represented as
# A sequence of mappings, with
# each mapping having one key
--- !!omap
- Mark McGwire: 65
- Sammy Sosa: 63
- Ken Griffey: 58
2.5. Full Length Example 2.5.全长示例
Below are two full-length examples of YAML. The first is a sample invoice; the
second is a sample log file.
下面是YAML的两个完整示例。一是发票样本;第二个是示例日志文件。
Example 2.27 Invoice 例2.27发票
--- !<tag:clarkevans.com,2002:invoice>
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
address:
lines: |
458 Walkman Dr.
Suite #292
city : Royal Oak
state : MI
postal : 48046
ship-to: *id001
product:
- sku : BL394D
quantity : 4
description : Basketball
price : 450.00
- sku : BL4438H
quantity : 1
description : Super Hoop
price : 2392.00
tax : 251.42
total: 4443.52
comments:
Late afternoon is best.
Backup contact is Nancy
Billsmer @ 338-4338.
Example 2.28 Log File 示例2.28日志文件
---
Time: 2001-11-23 15:01:42 -5
User: ed
Warning:
This is an error message
for the log file
---
Time: 2001-11-23 15:02:31 -5
User: ed
Warning:
A slightly different error
message.
---
Date: 2001-11-23 15:03:17 -5
User: ed
Fatal:
Unknown variable "bar"
Stack:
- file: TopClass.py
line: 23
code: |
x = MoreObject("345\n")
- file: MoreClass.py
line: 58
code: |-
foo = bar
Chapter 3. Processes and Models 第3章.流程和模型
YAML is both a text format and a method for
presenting
any [native data structure](https://yaml.org/spec/1.2.2/#representing-native-
data-structures) in this format. Therefore, this specification defines two
concepts: a class of data objects called YAML
representations and a
syntax for [presenting](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) YAML [representations](https://yaml.org/spec/1.2.2
/#representation-graph) as a series of characters, called a YAML
stream.
YAML既是一种文本格式，也是一种以这种格式表示任何原生数据结构的方法。因此，本规范定义了两个概念：一个称为YAML表示的数据对象类和一个用于将YAML表示表示表示为一系列字符的语法，称为YAML流。
A YAML processor is a tool for converting information between these
complementary views. It is assumed that a YAML processor does its work on
behalf of another module, called an application. This chapter describes the
information structures a YAML processor must provide to or obtain from the
application.
YAML处理器是用于在这些互补视图之间转换信息的工具。假设YAML处理器代表另一个模块（称为应用程序）执行其工作。本章介绍YAML处理器必须向应用程序提供或从应用程序获取的信息结构。
YAML information is used in two ways: for machine processing and for human
consumption. The challenge of reconciling these two perspectives is best done
in three distinct translation stages:
representation,
serialization and
presentation.
Representation addresses
how YAML views [native data structures](https://yaml.org/spec/1.2.2
/#representing-native-data-structures) to achieve portability between
programming environments. [Serialization](https://yaml.org/spec/1.2.2
/#serialization-tree) concerns itself with turning a YAML
representation into a
serial form, that is, a form with sequential access constraints.
Presentation deals with
the formatting of a YAML [serialization](https://yaml.org/spec/1.2.2
/#serialization-tree) as a series of characters in a human-friendly manner.
YAML信息以两种方式使用：用于机器加工和人类消费。调和这两种观点的挑战最好在三个不同的翻译阶段完成：表示、序列化和呈现。
表示解决了YAML如何查看本机数据结构以实现编程环境之间的可移植性。 序列化本身涉及将YAML表示转换为串行形式，即具有顺序访问约束的形式。
Presentation以人性化的方式将YAML序列化的格式处理为一系列字符。
3.1. Processes
Translating between [native data structures](https://yaml.org/spec/1.2.2
/#representing-native-data-structures) and a character
stream is done in several logically
distinct stages, each with a well defined input and output data model, as
shown in the following diagram:
原生数据结构和字符流之间的转换是在几个逻辑上不同的阶段中完成的，每个阶段都有一个定义良好的输入和输出数据模型，如下图所示：
Figure 3.1. Processing Overview 图3.1.处理概述
A YAML processor need not expose the
serialization or
representation stages. It
may translate directly between native data
structures
and a character stream
(dump and
load in the diagram above). However, such
a direct translation should take place so that the native data
structures
are [constructed](https://yaml.org/spec/1.2.2/#constructing-native-data-
structures) only from information available in the
representation. In
particular, mapping key order,
comments and tag
handles should not be referenced
during [construction](https://yaml.org/spec/1.2.2/#constructing-native-data-
structures).
YAML处理器不需要公开序列化或表示阶段。它可以直接在本机数据结构和字符流之间转换（上图中的转储和加载）。然而，这样的直接转换应当发生，使得仅从表示中可用的信息构造原生数据结构。特别是，在构造过程中不应引用映射键顺序、注释和标记句柄。
3.1.1. Dump
Dumping native data structures to a character
stream is done using the following
three stages:
将本机数据结构转储到字符流使用以下三个阶段完成：
Representing Native Data Structures
表示原生数据结构
YAML represents any native data structure using three node
kinds :
sequence - an ordered series of
entries; mapping - an unordered
association of unique
keys to
values; and
scalar - any datum with opaque
structure presentable as a series of Unicode characters.
YAML表示使用三种节点类型的任何原生数据结构：sequence -有序的一系列条目;映射-一个无序关联的唯一 键到值;标量-
任何具有不透明结构的数据，可以表示为一系列Unicode字符。
Combined, these primitives generate directed graph structures. These
primitives were chosen because they are both powerful and familiar: the
sequence corresponds to a Perl array
and a Python list, the mapping
corresponds to a Perl hash table and a Python dictionary. The
scalar represents strings, integers,
dates and other atomic data types.
结合起来，这些原语生成有向图结构。之所以选择这些原语，是因为它们既强大又熟悉：序列对应于Perl数组和Python列表，映射对应于Perl哈希表和Python字典。标量表示字符串、整数、日期和其他原子数据类型。
Each YAML node requires, in addition to
its kind and
content, a
tag specifying its data type. Type
specifiers are either global URIs or are
local in scope to a single
application. For example,
an integer is represented in YAML with a
scalar plus the global
tag “tag:yaml.org,2002:int”. Similarly,
an invoice object, particular to a given organization, could be represented as
a mapping together with the local
tag “!invoice”. This simple model can
represent any data structure independent of programming language.
每个YAML节点除了其类型和内容外，还需要一个指定其数据类型的标记。类型说明符可以是全局URI，也可以是单个应用程序的局部范围。例如，整数在YAML中用标量加上全局标记“
tag:yaml.org,2002:int ”表示。类似地，特定于给定组织的发票对象可以与本地标签“ !invoice
”一起被表示为映射。这个简单的模型可以表示任何独立于编程语言的数据结构。
Serializing the Representation Graph
序列化表示图
For sequential access mediums, such as an event callback API, a YAML
representation must be
serialized to an ordered tree. Since in a YAML
representation , mapping
keys are unordered and
nodes may be referenced more than once
(have more than one incoming “arrow”), the serialization process is required
to impose an ordering on the
mapping keys and to replace the second
and subsequent references to a given
node with place holders called
aliases. YAML does not
specify how these serialization details are chosen. It is up to the YAML
processor to come up with
human-friendly key order and
anchor names, possibly
with the help of the [application](https://yaml.org/spec/1.2.2/#processes-and-
models). The result of this process, a YAML serialization
tree , can then be traversed
to produce a series of event calls for one-pass processing of YAML data.
对于顺序访问介质，例如事件回调API，YAML表示必须序列化为有序树。由于在YAML表示中，映射键是无序的，并且节点可以被引用不止一次（具有不止一个传入的“箭头”），因此需要序列化过程来对映射键施加排序，并且用称为别名的占位符替换对给定节点的第二次和后续引用。YAML没有指定如何选择这些序列化细节。这取决于YAML处理器来提出人性化的键顺序和锚名称，可能需要应用程序的帮助。然后可以遍历此过程的结果（YAML序列化树），以生成一系列事件调用，用于YAML数据的一次处理。
Presenting the Serialization Tree
显示序列化树
The final output process is presenting the YAML
serializations as a
character stream in a human-friendly
manner. To maximize human readability, YAML offers a rich set of stylistic
options which go far beyond the minimal functional needs of simple data
storage. Therefore the YAML [processor](https://yaml.org/spec/1.2.2
/#processes-and-models) is required to introduce various presentation
details when creating the stream ,
such as the choice of node styles,
how to format scalar content,
the amount of indentation,
which tag handles to use, the
node tags to leave
unspecified, the set of
directives to provide and possibly
even what comments to add. While some
of this can be done with the help of the
application, in general
this process should be guided by the preferences of the user.
最后的输出过程是以人性化的方式将YAML序列化表示为字符流。为了最大限度地提高人类可读性，YAML提供了一组丰富的风格选项，远远超出了简单数据存储的最低功能需求。因此，YAML处理器需要在创建流时引入各种表示细节，例如节点样式的选择，如何格式化标量内容，缩进量，使用哪个标签句柄，未指定的节点标签，要提供的指令集，甚至可能要添加的注释。虽然其中一些可以在应用程序的帮助下完成，但通常该过程应该由用户的偏好来指导。
3.1.2. Load
Loading [native data structures](https://yaml.org/spec/1.2.2/#representing-
native-data-structures) from a character
stream is done using the following
three stages:
从字符流加载本机数据结构通过以下三个阶段完成：
Parsing the Presentation Stream 解析演示流
Parsing is the inverse process of [presentation](https://yaml.org/spec/1.2.2
/#presentation-stream) , it takes a
stream of characters and produces a
serialization tree. Parsing
discards all the [details](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) introduced in the
presentation process,
reporting only the [serialization tree](https://yaml.org/spec/1.2.2
/#serialization-tree). Parsing can fail due to [ill-
formed](https://yaml.org/spec/1.2.2/#well-formed-streams-and-identified-
aliases) input.
解析是表示的逆过程，它获取字符流并生成序列化树。解析将丢弃表示过程中引入的所有详细信息，仅报告序列化树。由于输入格式不正确，解析可能会失败。
Composing the Representation Graph
组成表示图
Composing takes a [serialization tree](https://yaml.org/spec/1.2.2
/#serialization-tree) and produces a representation
graph. Composing discards
all the [details](https://yaml.org/spec/1.2.2/#presenting-the-serialization-
tree) introduced in the [serialization](https://yaml.org/spec/1.2.2
/#serialization-tree) process, producing only the representation
graph. Composing can fail
due to any of several reasons, detailed [below](https://yaml.org/spec/1.2.2
/#loading-failure-points).
合成采用序列化树并生成表示图。合成将丢弃序列化过程中引入的所有细节，只生成表示图。合成可能会由于以下几种原因中的任何一种而失败。
Constructing Native Data Structures
构建原生数据结构
The final input process is constructing native data
structures
from the YAML [representation](https://yaml.org/spec/1.2.2/#representation-
graph). Construction must be based only on the information available in the
representation and not on
additional serialization or
[presentation details](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) such as comments
, directives, mapping key
order, node
styles, scalar content
format,
indentation levels etc.
Construction can fail due to the [unavailability](https://yaml.org/spec/1.2.2
/#available-tags) of the required native data
types.
最后一个输入过程是从YAML表示构建原生数据结构。构造必须仅基于表示中可用的信息，而不是基于附加的序列化或表示细节，例如注释、指令、映射键顺序、节点样式、标量内容格式、缩进级别等。构造可能会由于所需的本机数据类型不可用而失败。
3.2. Information Models 3.2.信息模型
This section specifies the formal details of the results of the above
processes. To maximize data portability between programming languages and
implementations, users of YAML should be mindful of the distinction between
serialization or
presentation properties
and those which are part of the YAML
representation. Thus,
while imposing a order on
mapping keys is necessary for flattening
YAML representations to a
sequential access medium, this serialization
detail
must not be used to convey [application](https://yaml.org/spec/1.2.2
/#processes-and-models) level information. In a similar manner, while
indentation technique and a
choice of a node style are needed
for the human readability, these presentation
details are
neither part of the YAML [serialization](https://yaml.org/spec/1.2.2
/#serialization-tree) nor the YAML
representation. By
carefully separating properties needed for
serialization and
presentation, YAML
representations of
application information
will be consistent and portable between various programming environments.
本节规定了上述过程结果的正式细节。为了最大限度地提高编程语言和实现之间的数据可移植性，YAML的用户应该注意序列化或表示属性与YAML表示的一部分之间的区别。因此，虽然在映射键上施加顺序对于将YAML表示扁平化到顺序访问介质是必要的，但是该序列化细节不得用于传达应用级信息。以类似的方式，虽然人类可读性需要缩进技术和节点样式的选择，但这些表示细节既不是YAML序列化也不是YAML表示的一部分。通过仔细分离序列化和表示所需的属性，应用程序信息的YAML表示将在各种编程环境之间保持一致和可移植。
The following diagram summarizes the three information models. Full arrows
denote composition, hollow arrows denote inheritance, “1 ” and “*” denote
“one” and “many” relationships. A single “+” denotes
serialization details, a
double “++” denotes [presentation](https://yaml.org/spec/1.2.2
/#presentation-stream) details.
下图总结了这三种信息模型。实心箭头表示组合，空心箭头表示继承，“ 1 ”和“ * ”表示“一”和“多”关系。单个“ + ”表示序列化细节，双“
++ ”表示呈现细节。
Figure 3.2. Information Models 图3.2.信息模型
3.2.1. Representation Graph 3.2.1.表示图
YAML’s representation of [native data structure](https://yaml.org/spec/1.2.2
/#representing-native-data-structures) is a rooted, connected, directed graph
of tagged
nodes. By “directed graph” we mean a set
of nodes and directed edges (“arrows”),
where each edge connects one node to
another (see a formal directed graph
definition13 ). All the
nodes must be reachable from the root
node via such edges. Note that the YAML graph may include cycles and a
node may have more than one incoming
edge.
YAML对原生数据结构的表示是一个有根的、连接的、有向的标记图。
节点“有向图”是指一组节点和有向边（“箭头”），其中每条边将一个节点连接到另一个节点（参见正式的有向图定义
13
）。所有节点必须是经由这样的边从根节点可到达的。注意，YAML图可以包括循环，并且节点可以具有多于一个传入边缘。
Nodes that are defined in terms of other
nodes are
collections;
nodes that are independent of any other
nodes are
scalars. YAML supports two
kinds of collection
nodes:
sequences and
mappings. Mapping
nodes are somewhat tricky because their
keys are unordered and must be
unique.
根据其他节点定义的节点是集合;独立于任何其他节点的节点是标量。YAML支持两种集合节点：序列和映射。
映射节点有些棘手，因为它们的键是无序的，并且必须是唯一的。
Figure 3.3. Representation Model 图3.3.表示模型
3.2.1.1. Nodes
A YAML node represents
a single [native data structure](https://yaml.org/spec/1.2.2/#representing-
native-data-structures). Such nodes have content of one of three kinds :
scalar, sequence or mapping. In addition, each node has a
tag which serves to restrict the set of
possible values the content can have.
YAML节点表示单个本机数据结构。这样的节点具有三种类型之一的内容：标量、序列或映射。此外，每个节点都有一个标签，用于限制内容可以具有的可能值的集合。
Scalar
The content of a scalar node is an opaque datum that can be
presented as
a series of zero or more Unicode characters.
标量节点的内容是一个不透明的数据，可以表示为一系列零个或多个Unicode字符。
Sequence
The content of a sequence node is an ordered series of zero or more nodes.
In particular, a sequence may contain the same node more than once. It could
even contain itself.
序列节点的内容是零个或多个节点的有序序列。特别地，序列可以不止一次地包含相同的节点。它甚至可以控制自己。
Mapping
The content of a mapping node is an unordered set of key/value node
pairs , with the restriction that each of the keys is
unique. YAML places no further
restrictions on the nodes. In particular, keys may be arbitrary nodes, the
same node may be used as the value of several key/value pairs and a mapping
could even contain itself as a key or a value.
映射节点的内容是键/值节点对的无序集合，其中每个键都是唯一的限制。YAML对节点没有进一步的限制。特别地，键可以是任意节点，相同的节点可以用作若干键/值对的值，并且映射甚至可以将其自身包含为键或值。
3.2.1.2. Tags
YAML represents type
information of [native data structures](https://yaml.org/spec/1.2.2
/#representing-native-data-structures) with a simple identifier, called a
tag. Global tags are URIs and hence globally unique across all
applications. The “tag:
” URI scheme14 is recommended for
all global YAML tags. In contrast, local tags are specific to a single
application. Local tags
start with “! ”, are not URIs and are not expected to be globally unique.
YAML provides a “TAG” directive to make tag notation less verbose; it also
offers easy migration from local to global tags. To ensure this, local tags
are restricted to the URI character set and use URI character
escaping.
YAML用一个简单的标识符（称为标记）表示本机数据结构的类型信息。全局标记是URI，因此在所有应用程序中全局唯一。对于所有全局YAML标签，建议使用“
tag: ”URI方案 14
。相比之下，本地标记特定于单个应用程序。本地标签以“ ! ”开头，不是URI，也不应该是全局唯一的。YAML提供了一个“ TAG
”指令来减少标记符号的冗长;它还提供了从本地标签到全局标签的简单迁移。为了确保这一点，本地标记被限制为URI字符集，并使用URI字符转义。
YAML does not mandate any special relationship between different tags that
begin with the same substring. Tags ending with URI fragments (containing
“#”) are no exception; tags that share the same base URI but differ in their
fragment part are considered to be different, independent tags. By convention,
fragments are used to identify different “variants” of a tag, while “/” is
used to define nested tag “namespace” hierarchies. However, this is merely a
convention and each tag may employ its own rules. For example, Perl tags may
use “::” to express namespace hierarchies, Java tags may use “.”, etc.
YAML不要求以相同子字符串开始的不同标记之间存在任何特殊关系。以URI片段（包含“ #
”）结尾的标签也不例外;共享相同基本URI但其片段部分不同的标签被认为是不同的独立标签。按照惯例，片段用于标识标记的不同“变体”，而“ /
”用于定义嵌套的标记“命名空间”层次结构。然而，这仅仅是一种约定，并且每个标签可以采用其自己的规则。例如，Perl标签可以使用“ ::
”来表达命名空间层次结构，Java标签可以使用“ . ”等。
YAML tags are used to associate meta information with each
node. In particular, each tag must
specify the expected node kind
(scalar,
sequence or
mapping).
Scalar tags must also provide a
mechanism for converting [formatted content](https://yaml.org/spec/1.2.2
/#scalar-formats) to a [canonical form](https://yaml.org/spec/1.2.2
/#canonical-form) for supporting
equality testing. Furthermore, a tag
may provide additional information such as the set of allowed
content values for validation, a
mechanism for tag resolution or
any other data that is applicable to all of the tag’s
nodes.
YAML标记用于将梅塔信息与每个节点相关联。特别是，每个标签必须指定预期的节点类型（标量、序列或映射）。
标量标记还必须提供一种机制，用于将格式化的内容转换为规范形式，以支持相等性测试。此外，标签可以提供附加信息，诸如用于验证的允许内容值的集合、用于标签解析的机制或适用于所有标签的节点的任何其他数据。
3.2.1.3. Node Comparison 3.2.1.3.节点比较
Since YAML mappings require
key uniqueness,
representations must
include a mechanism for testing the equality of
nodes. This is non-trivial since YAML
allows various ways to [format scalar content](https://yaml.org/spec/1.2.2
/#scalar-formats). For example, the integer eleven can be written as “0o13”
(octal) or “0xB” (hexadecimal). If both notations are used as
keys in the same
mapping, only a YAML
processor which
recognizes integer formats
would correctly flag the duplicate key
as an error.
由于YAML映射需要键的唯一性，因此表示必须包含一个用于测试节点相等性的机制。这是不平凡的，因为YAML允许各种方式来格式化标量内容。例如，整数11可以写成“
0o13 ”（八进制）或“ 0xB
”（十六进制）。如果两种符号都用作同一映射中的键，则只有识别整数格式的YAML处理器才能正确地将重复键标记为错误。
Canonical Form
YAML supports the need for scalar
equality by requiring that every scalar
tag must specify a mechanism for
producing the canonical form of any formatted
content. This form is a Unicode
character string which also [presents](https://yaml.org/spec/1.2.2
/#presenting-the-serialization-tree) the same
content and can be used for equality
testing.
YAML通过要求每个标量 标签必须指定一种机制，用于生成任何格式化内容的规范形式。此表单是一个Unicode字符串，它也表示相同的内容，可用于相等性测试。
Equality
Two nodes must have the same
tag and
content to be equal. Since each
tag applies to exactly one
kind , this implies that the two
nodes must have the same
kind to be equal.
两个节点必须具有相同的标记和内容才能相等。由于每个标记只适用于一种类型，这意味着两个节点必须具有相同的类型才能相等。
Two scalars are equal only when their
tags and canonical forms are equal
character-by-character. Equality of
collections is defined
recursively.
两个标量只有在它们的标记和规范形式逐个字符相等时才相等。集合的相等性是递归定义的。
Two sequences are equal only when
they have the same tag and length and
each node in one
sequence is equal to the
corresponding node in the other
sequence.
只有当两个序列具有相同的标签和长度并且一个序列中的每个节点等于另一个序列中的对应节点时，它们才是相等的。
Two mappings are equal only when they
have the same tag and an equal set of
keys and each
key in this set is associated with equal
values in both
mappings.
只有当两个映射具有相同的标记和相等的键集合，并且该集合中的每个键与两个映射中的相等值相关联时，它们才相等。
Different URI schemes may define different rules for testing the equality of
URIs. Since a YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) cannot be reasonably expected to be aware of them all, it must resort
to a simple character-by-character comparison of
tags to ensure consistency. This also
happens to be the comparison method defined by the “tag:” URI scheme.
Tags in a YAML stream must therefore be
presented in
a canonical way so that such comparison would yield the correct results.
不同的URI方案可以定义用于测试URI的相等性的不同规则。由于YAML处理器不能合理地期望知道所有这些，因此它必须求助于简单的逐个字符的标记比较来确保一致性。这也恰好是由“
tag: ”URI方案定义的比较方法。 因此，YAML流中的标记必须以规范的方式呈现，以便这种比较会产生正确的结果。
If a node has itself as a descendant (via an alias), then determining the
equality of that node is implementation-defined.
如果一个节点有自己的后代（通过别名），那么确定该节点的相等性是实现定义的。
A YAML processor may
treat equal scalars as if they were
identical.
YAML处理器可以将相等标量视为等同。
Uniqueness
A mapping’s
keys are unique if no two keys are
equal to each other. Obviously, identical nodes are always considered equal.
A映射的 如果没有两个密钥彼此相等，则密钥是唯一的。显然，相同的节点总是被认为是相等的。
3.2.2. Serialization Tree 3.2.2.序列化树
To express a YAML [representation](https://yaml.org/spec/1.2.2
/#representation-graph) using a serial API, it is necessary to impose an
order on mapping
keys and employ alias
nodes to indicate a subsequent
occurrence of a previously encountered
node. The result of this process is a
serialization tree , where each node
has an ordered set of children. This tree can be traversed for a serial event-
based API. [Construction](https://yaml.org/spec/1.2.2/#constructing-native-
data-structures) of [native data structures](https://yaml.org/spec/1.2.2
/#representing-native-data-structures) from the serial interface should not
use key order or anchor
names for the preservation
of application data.
为了使用串行API表达YAML表示，有必要对映射键施加顺序，并使用别名节点来指示先前遇到的节点的后续出现。此过程的结果是一个序列化树，其中每个节点都有一组有序的子节点。对于基于串行事件的API，可以遍历此树。
从串行接口构造本机数据结构时，不应使用键顺序或锚名称来保存应用程序数据。
Figure 3.4. Serialization Model 图3.4.序列化模型
3.2.2.1. Mapping Key Order 3.2.2.1.映射键顺序
In the representation
model, mapping keys do not have an
order. To [serialize](https://yaml.org/spec/1.2.2/#serializing-the-
representation-graph) a mapping, it is
necessary to impose an ordering on its
keys. This order is a serialization
detail and
should not be used when [composing](https://yaml.org/spec/1.2.2/#composing-
the-representation-graph) the representation
graph (and hence for the
preservation of [application](https://yaml.org/spec/1.2.2/#processes-and-
models) data). In every case where node
order is significant, a sequence must
be used. For example, an ordered
mapping can be
represented as a
sequence of
mappings , where each
mapping is a single key/value
pair. YAML provides convenient compact
notation
for this case.
在表示模型中，映射键没有顺序。要序列化映射，有必要对其键进行排序。此顺序是一个序列化细节，在组成表示图时不应使用（因此也不应用于保存应用程序数据）。在节点顺序很重要的每种情况下，必须使用序列。例如，有序映射可以表示为映射序列，其中每个映射是单个键/值对。YAML为这种情况提供了方便的紧凑表示法。
3.2.2.2. Anchors and Aliases 3.2.2.2.锚点和别名
In the [representation graph](https://yaml.org/spec/1.2.2/#representation-
graph), a node may appear in more than
one collection. When
[serializing](https://yaml.org/spec/1.2.2/#serializing-the-representation-
graph) such data, the first occurrence of the
node is identified by an anchor.
Each subsequent occurrence is [serialized](https://yaml.org/spec/1.2.2
/#serializing-the-representation-graph) as an alias
node which refers back to this
anchor. Otherwise, anchor names are a serialization
detail and
are discarded once [composing](https://yaml.org/spec/1.2.2/#composing-the-
representation-graph) is completed. When
composing a
representation graph from
[serialized](https://yaml.org/spec/1.2.2/#serializing-the-representation-
graph) events, an alias event refers to the most recent event in the
serialization having the
specified anchor. Therefore, anchors need not be unique within a
serialization. In addition,
an anchor need not have an alias node referring to it.
在表示图中，节点可以出现在多于一个集合中。当序列化这样的数据时，节点的第一次出现由锚来标识。每个后续的出现都被序列化为一个别名节点，该节点引用回该锚。否则，锚名称是序列化详细信息，在合成完成后将被丢弃。当从序列化事件组成表示图时，别名事件是指序列化中具有指定锚的最近事件。因此，锚在序列化中不需要是唯一的。此外，锚不需要具有引用它的别名节点。
3.2.3. Presentation Stream 3.2.3.演示流
A YAML presentation is a stream of
Unicode characters making use of [styles](https://yaml.org/spec/1.2.2/#node-
styles) , [scalar content formats](https://yaml.org/spec/1.2.2/#scalar-
formats), comments,
directives and other presentation
details to
present a
YAML serialization in a
human readable way. YAML allows several serialization
trees to be contained in the
same YAML presentation stream, as a series of
documents separated by
markers.
YAML表示是一个Unicode字符流，使用样式，标量内容格式，注释，指令和其他表示细节以人类可读的方式呈现YAML序列化。YAML允许多个序列化树包含在同一个YAML表示流中，作为一系列由标记分隔的文档。
Figure 3.5. Presentation Model 图3.5.演示模型
3.2.3.1. Node Styles 3.2.3.1.节点样式
Each node is presented in some style ,
depending on its kind. The node style is
a [presentation detail](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) and is not reflected in the serialization
tree or representation
graph. There are two
groups of styles. [Block styles](https://yaml.org/spec/1.2.2/#block-style-
productions) use [indentation](https://yaml.org/spec/1.2.2/#indentation-
spaces) to denote structure. In contrast, flow
styles rely on explicit
indicators.
每个节点都以某种样式显示，具体取决于其类型。节点样式是表示详细信息，不会反映在序列化树或表示图中。有两组样式。
块样式使用缩进来表示结构。相反，流样式依赖于明确的指示器。
YAML provides a rich set of scalar styles. Block
scalar styles include the
literal style and the folded
style. Flow
scalar styles include the
plain style and two quoted styles,
the single-quoted style
and the [double-quoted style](https://yaml.org/spec/1.2.2/#double-quoted-
style). These styles offer a range of trade-offs between expressive power and
readability.
YAML提供了一组丰富的标量样式。 块标量样式包括原义样式和折叠样式。
流标量样式包括普通样式和两种引用样式，即单引号样式和双引号样式。这些样式在表达能力和可读性之间提供了一系列折衷。
Normally, block sequences and
mappings begin on the next line. In
some cases, YAML also allows nested
block
collections to start in-line for a
more [compact notation](https://yaml.org/spec/1.2.2/#example-flow-mapping-
adjacent-values). In addition, YAML provides a compact
notation
for flow mappings with a single
key/value pair, nested inside a flow
sequence. These allow for a
natural “ordered mapping” notation.
通常，块序列和映射从下一行开始。在某些情况下，YAML还允许嵌套块
集合以内联方式开始，以获得更紧凑的表示法。此外，YAML为流映射提供了一种紧凑的表示法，其中包含一个嵌套在流序列中的键/值对。这些允许自然的“有序映射”符号。
Figure 3.6. Kind/Style Combinations
图3.6.种类/风格组合
3.2.3.2. Scalar Formats 3.2.3.2.标量格式
YAML allows scalars to be
presented in
several formats. For example, the integer “11 ” might also be written as
“0xB”. Tags must specify a mechanism
for converting the formatted content to a canonical
form for use in
equality testing. Like node
style, the format is a
[presentation detail](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) and is not reflected in the serialization
tree and representation
graph.
YAML允许标量以多种格式表示。例如，整数“ 11 ”也可以写成“ 0xB ”。
标记必须指定一种机制，用于将格式化内容转换为规范形式，以便在相等性测试中使用。与节点样式一样，格式是一种表示细节，不会反映在序列化树和表示图中。
3.2.3.3. Comments
Comments are a presentation
detail and
must not have any effect on the serialization
tree or representation
graph. In particular,
comments are not associated with a particular
node. The usual purpose of a comment is
to communicate between the human maintainers of a file. A typical example is
comments in a configuration file. Comments must not appear inside
scalars, but may be interleaved with
such scalars inside
collections.
注释是一种表示详细信息，不得对序列化树或表示图产生任何影响。特别地，注释不与特定节点相关联。注释的通常用途是在文件的维护人员之间进行通信。一个典型的例子是配置文件中的注释。注释不能出现在标量中，但可以与集合中的标量交错。
3.2.3.4. Directives 3.2.3.4.指令
Each document may be associated with
a set of directives. A directive
has a name and an optional sequence of parameters. Directives are instructions
to the YAML processor and
like all other [presentation details](https://yaml.org/spec/1.2.2/#presenting-
the-serialization-tree) are not reflected in the YAML serialization
tree or representation
graph. This version of
YAML defines two directives, “YAML” and “TAG”. All other directives are
reserved for future versions of
YAML.
每个文档可以与一组指令相关联。指令有一个名称和一个可选的参数序列。指令是对YAML处理器的指令，并且像所有其他表示细节一样，不会反映在YAML序列化树或表示图中。此版本的YAML定义了两个指令，“
YAML ”和“ TAG ”。所有其他指令都保留用于YAML的未来版本。
3.3. Loading Failure Points 3.3.加载失效点
The process of loading native data
structures
from a YAML stream has several
potential failure points. The character
stream may be [ill-
formed](https://yaml.org/spec/1.2.2/#well-formed-streams-and-identified-
aliases) , aliases may be
[unidentified](https://yaml.org/spec/1.2.2/#well-formed-streams-and-
identified-aliases), [unspecified tags](https://yaml.org/spec/1.2.2/#resolved-
tags) may be unresolvable,
tags may be
unrecognized, the
content may be
invalid,
mapping
keys may not be
unique and a native type may
be unavailable. Each of these
failures results with an incomplete loading.
装载过程
来自YAML流的原生数据结构具有几个潜在的故障点。字符流可能格式不正确，别名可能无法识别，未指定的标记可能无法解析，标记可能无法识别，内容可能无效，映射
键可能不是唯一的，并且原生类型可能不可用。这些失效中的每一个都导致不完全加载。
A partial representation need not [resolve](https://yaml.org/spec/1.2.2
/#resolved-tags) the tag of each
node and the canonical
form of formatted scalar
content need not be available.
This weaker representation is useful for cases of incomplete knowledge of the
types used in the document.
部分表示不需要解析每个节点的标签，并且格式化标量内容的规范形式不需要可用。这种较弱的表示对于不完全了解文档中使用的类型的情况很有用。
In contrast, a complete representation specifies the
tag of each
node and provides the canonical
form of formatted scalar
content , allowing for
equality testing. A complete
representation is required in order to [construct](https://yaml.org/spec/1.2.2
/#constructing-native-data-structures) native data
structures.
相比之下，完整表示指定每个节点的标记，并提供格式化标量内容的规范形式，允许相等测试。需要完整的表示才能构造 原生数据结构
Figure 3.7. Loading Failure Points
图3.7.加载失效点
3.3.1. Well-Formed Streams and Identified Aliases
3.3.1.格式良好的流和已识别的别名
A well-formed character
stream must match the BNF productions
specified in the following chapters. Successful loading also requires that
each alias shall refer to
a previous node
identified by the
anchor. A YAML
processor should reject
ill-formed streams and unidentified aliases. A YAML
processor may recover
from syntax errors, possibly by ignoring certain parts of the input, but it
must provide a mechanism for reporting such errors.
一个格式良好的字符流必须与下面几章中指定的BNF产生式匹配。成功加载还要求每个别名都引用前一个节点
由锚识别。YAML处理器应该拒绝格式错误的流和未识别的别名。YAML处理器可以从语法错误中恢复，可能是通过忽略输入的某些部分，但它必须提供报告此类错误的机制。
3.3.2. Resolved Tags 3.3.2.已解决的标签
Typically, most tags are not explicitly
specified in the character stream.
During [parsing](https://yaml.org/spec/1.2.2/#parsing-the-presentation-
stream), nodes lacking an explicit
tag are given a non-specific tag :
“!” for non-plain scalars and
“?” for all other nodes.
Composing a
complete representation
requires each such non-specific tag to be resolved to a specific tag , be
it a global tag or a local
tag.
通常，大多数标记都没有在字符流中显式指定。在解析期间，缺少显式标记的节点被赋予非特定标记：“ ! ”用于非纯标量，“ ? ”用于所有其他节点。
组成完整的表示需要将每个这样的非特定标签解析为特定标签，无论是全局标签还是局部标签。
Resolving the tag of a
node must only depend on the following
three parameters: (1) the non-specific tag of the
node, (2) the path leading from the
root to the
node and (3) the
content (and hence the
kind) of the
node. When a
node has more than one occurrence (using
aliases), tag resolution
must depend only on the path to the first
(anchored) occurrence of
the node.
解析节点的标记必须仅取决于以下三个参数：（1）节点的非特定标签，（2）从根到节点的路径，以及（3）节点的内容（以及因此的种类）。当一个节点有多个引用（使用别名）时，标记解析必须仅取决于该节点的第一个（锚定）引用的路径。
Note that resolution must not consider presentation
details such
as comments,
indentation and node
style. Also, resolution must not
consider the content of any other
node, except for the
content of the key
nodes directly along the path leading
from the root to the
resolved node. Finally, resolution must
not consider the content of a sibling
node in a
collection or the
content of the value
node associated with a key
node being resolved.
请注意，分辨率不能考虑表示细节，如注释、缩进和节点样式。此外，解析必须不考虑任何其他节点的内容，除了直接沿着从根到解析节点的路径的关键节点的内容。最后，解析不能考虑集合中兄弟节点的内容，也不能考虑与被解析的键节点关联的值节点的内容。
These rules ensure that tag resolution can be performed as soon as a
node is first encountered in the
stream, typically before its
content is
parsed. Also,
tag resolution only requires referring to a relatively small number of
previously parsed nodes. Thus, in most
cases, tag resolution in one-pass [processors](https://yaml.org/spec/1.2.2
/#processes-and-models) is both possible and practical.
这些规则确保在流中第一次遇到节点时（通常在解析其内容之前）就可以执行标记解析。此外，标签解析仅需要参考相对少量的先前解析的节点。因此，在大多数情况下，在单程处理器中的标签分辨率是可能的和实用的。
YAML processors should
resolve nodes having the “!” non-
specific tag as “tag:yaml.org,2002:seq”, “tag:yaml.org,2002:map” or
“tag:yaml.org,2002:str” depending on their
kind. This tag resolution convention
allows the author of a YAML character
stream to effectively “disable” the
tag resolution process. By explicitly specifying a “! ” non-specific tag
property, the
node would then be resolved to a
“vanilla” sequence,
mapping or string, according to its
kind.
YAML处理器应根据其种类将具有“ ! ”非特定标记的节点解析为“ tag:yaml.org,2002:seq ”、“
tag:yaml.org,2002:map ”或“ tag:yaml.org,2002:str
”。此标记解析约定允许YAML字符流的作者有效地“禁用”标记解析过程。通过显式地指定“ !
”非特定标签属性，节点然后将根据其种类被解析为“vanilla”序列、映射或字符串。
Application specific tag
resolution rules should be restricted to resolving the “?” non-specific tag,
most commonly to resolving [plain scalars](https://yaml.org/spec/1.2.2/#plain-
style). These may be matched against a set of regular expressions to provide
automatic resolution of integers, floats, timestamps and similar types. An
application may also
match the content of mapping
nodes against sets of expected
keys to automatically resolve points,
complex numbers and similar types. Resolved sequence
node types such as the “ordered
mapping” are also possible.
应用程序特定的标记解析规则应限于解析“ ?
”非特定标记，最常见的是解析纯标量。这些可以与一组正则表达式匹配，以提供整数、浮点数、时间戳和类似类型的自动解析。应用程序还可以将映射节点的内容与预期键的集合进行匹配，以自动解析点、复数和类似类型。解析的序列节点类型如“有序映射”也是可能的。
That said, tag resolution is specific to the
application. YAML
processors should
therefore provide a mechanism allowing the
application to override
and expand these default tag resolution rules.
也就是说，标记分辨率特定于应用程序。因此，YAML处理器应该提供一种机制，允许应用程序覆盖和扩展这些默认标记解析规则。
If a document contains unresolved
tags , the YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) is unable to [compose](https://yaml.org/spec/1.2.2/#composing-the-
representation-graph) a [complete representation](https://yaml.org/spec/1.2.2
/#loading-failure-points) graph. In such a case, the YAML
processor may
compose a
partial representation,
based on each node’s kind and allowing
for non-specific tags.
如果文档包含未解析的标记，则YAML处理器无法组成完整的表示图。在这种情况下，YAML处理器可以基于每个节点的种类并允许非特定标签来组成部分表示。
3.3.3. Recognized and Valid Tags 3.3.3.已识别和有效的标签
To be valid , a node must have a
tag which is recognized by the YAML
processor and its
content must satisfy the constraints
imposed by this tag. If a
document contains a scalar
node with an unrecognized tag or
invalid content , only a partial
representation may be
composed.
In contrast, a YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) can always [compose](https://yaml.org/spec/1.2.2/#composing-the-
representation-graph) a [complete representation](https://yaml.org/spec/1.2.2
/#loading-failure-points) for an unrecognized or an invalid
collection, since
collection
equality does not depend upon
knowledge of the collection’s data
type. However, such a [complete representation](https://yaml.org/spec/1.2.2
/#loading-failure-points) cannot be used to
construct
a [native data structure](https://yaml.org/spec/1.2.2/#representing-native-
data-structures).
要有效，节点必须具有YAML处理器可识别的标记，并且其内容必须满足此标记施加的约束。如果文档包含带有无法识别的标记或无效内容的标量节点，则只能组成部分表示。相比之下，YAML处理器始终可以为无法识别或无效的集合组成完整的表示形式，因为集合
相等性不依赖于集合的数据类型的知识。然而，这样的完整表示不能用于构造原生数据结构。
3.3.4. Available Tags 3.3.4.可用标签
In a given processing environment, there need not be an available native
type corresponding to a given tag. If a
node’s tag is unavailable , a YAML
processor will not be
able to [construct](https://yaml.org/spec/1.2.2/#constructing-native-data-
structures) a [native data structure](https://yaml.org/spec/1.2.2
/#representing-native-data-structures) for it. In this case, a complete
representation may still
be composed
and an application may
wish to use this [representation](https://yaml.org/spec/1.2.2/#representation-
graph) directly.
在给定的处理环境中，不需要存在对应于给定标签的可用本机类型。如果节点的标记不可用，则YAML处理器将无法为其构造本机数据结构。在这种情况下，仍然可以组成完整的表示，并且应用可能希望直接使用该表示。
Chapter 4. Syntax Conventions 第4章：语法约定
The following chapters formally define the syntax of YAML character
streams, using parameterized BNF
productions. Each BNF production is both named and numbered for easy
reference. Whenever possible, basic structures are specified before the more
complex structures using them in a “bottom up” fashion.
以下章节使用参数化BNF产生式正式定义YAML字符流的语法。每个生物固氮生产都有名称和编号，以便于参考。只要有可能，基本结构在更复杂的结构之前指定，以“自下而上”的方式使用它们。
The productions are accompanied by examples which are presented in a two-pane
side-by-side format. The left-hand side is the YAML example and the right-hand
side is an alternate YAML view of the example. The right-hand view uses JSON
when possible. Otherwise it uses a YAML form that is as close to JSON as
possible.
作品附有以双窗格并排格式呈现的示例。左侧是YAML示例，右侧是该示例的备用YAML视图。右侧视图尽可能使用JSON。否则，它使用尽可能接近JSON的YAML形式。
4.1. Production Syntax 4.1.生产语法
Productions are defined using the syntax production-name ::= term, where a
term is either:
生产是使用语法 production-name ::= term 定义的，其中一个术语是：
An atomic term 原子术语
-
A quoted string (
"abc"), which matches that concatenation of characters. A single character is usually written with single quotes ('a').
一个带引号的字符串（"abc"），它匹配字符的串联。单个字符通常用单引号（'a'）表示。 -
A hexadecimal number (
x0A), which matches the character at that Unicode code point.
十六进制数（x0A），与该Unicode代码点处的字符匹配。 -
A range of hexadecimal numbers (
[x20-x7E]), which matches any character whose Unicode code point is within that range.
十六进制数字范围（[x20-x7E]），它匹配Unicode码位在该范围内的任何字符。 -
The name of a production (
c-printable), which matches that production.
生产的名称（c-printable），与该生产匹配。
A lookaround
-
[ lookahead = term ], which matches the empty string iftermwould match.
[ lookahead = term ]，如果term匹配，则匹配空字符串。 -
[ lookahead ≠ term ], which matches the empty string iftermwould not match.
[ lookahead ≠ term ]，如果term不匹配，则匹配空字符串。 -
[ lookbehind = term ], which matches the empty string iftermwould match beginning at any prior point on the line and ending at the current position.
[ lookbehind = term ]，如果term将匹配该行上任何先前点的开始和当前位置的结束，则匹配空字符串。
A special production 特别制作
-
<start-of-line>, which matches the empty string at the beginning of a line.
<start-of-line>，匹配行首的空字符串。 -
<end-of-input>, matches the empty string at the end of the input.
<end-of-input>，匹配输入末尾的空字符串。 -
<empty>, which (always) matches the empty string.
<empty>，它（总是）匹配空字符串。
A parenthesized term 加括号的术语
Matches its contents. 与里面的东西相符。
A concatenation
Is term-one term-two, which matches term-one followed by term-two.
是 term-one term-two ，它匹配 term-one ，后面是 term-two 。
A alternation
Is term-one | term-two, which matches the term-one if possible, or term- two otherwise.
是 term-one | term-two ，如果可能，它匹配 term-one ，否则为 term-two 。
A quantified term: 量化术语：
-
term?, which matches(term | <empty>).
term?，与(term | <empty>)匹配。 -
term*, which matches(term term* | <empty>).
term*，与(term term* | <empty>)匹配。 -
term+, which matches(term term*).
term+，与(term term*)匹配。
Note: Quantified terms are always greedy.
注：量化项总是贪婪的。
The order of precedence is parenthesization, then quantification, then
concatenation, then alternation.
优先顺序是括号，然后是量化，然后是连接，然后是交替。
Some lines in a production definition might have a comment like:
生产定义中的某些行可能有如下注释：
production-a ::=
production-b # clarifying comment
These comments are meant to be informative only. For instance a comment that
says # not followed by non-ws char just means that you should be aware that
actual production rules will behave as described even though it might not be
obvious from the content of that particular production alone.
这些评论仅供参考。例如，一个注释说 # not followed by non-ws char
只是意味着你应该意识到实际的生产规则将按照所描述的那样运行，即使它可能不明显，从特定的生产内容本身。
4.2. Production Parameters 4.2.生产参数
Some productions have parameters in parentheses after the name, such as s -line-prefix(n,c). A
parameterized production is shorthand for a (infinite) series of productions,
each with a fixed value for each parameter.
有些产品在名称后面的括号中有参数，例如 s-line-prefix(n,c)
。参数化生产是一系列（无限）生产的简写，每个生产的每个参数都有一个固定的值。
For instance, this production: 例如，该生产：
production-a(n) ::= production-b(n)
Is shorthand for: 是以下内容的简写：
production-a(0) ::= production-b(0)
production-a(1) ::= production-b(1)
…
And this production: 这一生产：
production-a(n) ::=
( production-b(n+m) production-c(n+m) )+
Is shorthand for: 是以下内容的简写：
production-a(0) ::=
( production-b(0) production-c(0) )+
| ( production-b(1) production-c(1) )+
| …
production-a(1) ::=
( production-b(1) production-c(1) )+
| ( production-b(2) production-c(2) )+
| …
…
The parameters are as follows: 参数如下：
Indentation: n or m
压痕： n 或 m
May be any natural number, including zero. n may also be -1.
可以是任何自然数，包括零。 n 也可以是-1。
Context: c 上下文： c
This parameter allows productions to tweak their behavior according to their
surrounding. YAML supports two groups of contexts , distinguishing between
block styles and flow
styles.
此参数允许产品根据其周围环境调整其行为。YAML支持两组上下文，区分块样式和流样式。
May be any of the following values:
可以是以下任意值：
-
BLOCK-IN– inside block context
BLOCK-IN-块上下文内 -
BLOCK-OUT– outside block context
BLOCK-OUT-块上下文外 -
BLOCK-KEY– inside block key context
BLOCK-KEY-块密钥上下文内 -
FLOW-IN– inside flow context
FLOW-IN-内部流上下文 -
FLOW-OUT– outside flow context
FLOW-OUT-外部流上下文 -
FLOW-KEY– inside flow key context
FLOW-KEY-流密钥上下文内
(Block) Chomping: t （块）咀嚼： t
The line break chomping
behavior for flow scalars. May be any of the following values:
流标量的线断裂咬合行为。可以是以下任意值：
-
STRIP– remove all trailing newlines
STRIP-删除所有尾随换行符 -
CLIP– remove all trailing newlines except the first
CLIP-删除除第一行以外的所有尾随换行符 -
KEEP– retain all trailing newlines
KEEP-保留所有尾随换行符
4.3. Production Naming Conventions
4.3.产品命名约定
To make it easier to follow production combinations, production names use a
prefix-style naming convention. Each production is given a prefix based on the
type of characters it begins and ends with.
为了更容易遵循产品组合，产品名称使用前缀样式的命名约定。每个产品都根据其开始和结束的字符类型提供前缀。
e-
A production matching no characters.
一部没有角色的作品。
c-
A production starting and ending with a special character.
以特殊角色开始和结束的作品。
b-
A production matching a single [line break](https://yaml.org/spec/1.2.2/#line-
break-characters).
与单行中断匹配的生产。
nb-
A production starting and ending with a
non-break character.
以非中断字符开始和结束的产品。
s-
A production starting and ending with a white
space character.
以白色字符开始和结束的产品。
ns-
A production starting and ending with a
non-space character.
以非空格字符开始和结束的产品。
l-
A production matching complete line(s).
生产匹配的完整生产线。
X-Y-
A production starting with an X- character and ending with a Y- character,
where X- and Y- are any of the above prefixes.
以 X- 字符开始并以 Y- 字符结束的产生式，其中 X- 和 Y- 是上述任何前缀。
X+, X-Y+
A production as above, with the additional property that the matched content
indentation level is
greater than the specified n parameter.
如上所述的产品，具有匹配的内容缩进级别大于指定的 n 参数的附加属性。
Chapter 5. Character Productions 第5章：角色制作
5.1. Character Set 5.1.字符集
To ensure readability, YAML streams
use only the printable subset of the Unicode character set. The allowed
character range explicitly excludes the C0 control
block15 x00-x1F (except for TAB
x09 , LF x0A and CR x0D which are allowed), DEL x7F, the C1 control
block x80-x9F (except for NEL x85 which is allowed), the surrogate
block16 xD800-xDFFF, xFFFE
and xFFFF.
为了确保可读性，YAML流只使用Unicode字符集的可打印子集。允许的字符范围明确排除C0控制块
15 x00-x1F （允许的TAB x09 、LF
x0A 和CR x0D 除外）、DEL x7F 、C1控制块 x80-x9F （允许的NEL x85 除外）、代理块
16 xD800-xDFFF 、 xFFFE 和
xFFFF 。
On input, a YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) must accept all characters in this printable subset.
在输入时，YAML处理器必须接受此可打印子集中的所有字符。
On output, a YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) must only produce only characters in this printable subset. Characters
outside this set must be [presented](https://yaml.org/spec/1.2.2/#presenting-
the-serialization-tree) using [escape](https://yaml.org/spec/1.2.2/#escaped-
characters) sequences. In addition, any allowed characters known to be non-
printable should also be [escaped](https://yaml.org/spec/1.2.2/#escaped-
characters).
在输出时，YAML处理器必须仅生成此可打印子集中的字符。此集合以外的字符必须使用转义序列表示。此外，任何已知不可打印的允许字符也应该被转义。
Note: This isn’t mandatory since a full implementation would require
extensive character property tables.
注意：这不是强制性的，因为完整的实现需要大量的字符属性表。
[1] c-printable ::=
# 8 bit
x09 # Tab (\t)
| x0A # Line feed (LF \n)
| x0D # Carriage Return (CR \r)
| [x20-x7E] # Printable ASCII
# 16 bit
| x85 # Next Line (NEL)
| [xA0-xD7FF] # Basic Multilingual Plane (BMP)
| [xE000-xFFFD] # Additional Unicode Areas
| [x010000-x10FFFF] # 32 bit
To ensure JSON compatibility,
YAML processors must
allow all non-C0 characters inside quoted
scalars. To ensure
readability, non-printable characters should be
escaped on output, even
inside such scalars.
为了确保JSON兼容性，YAML处理器必须允许所有非C0字符包含在带引号的标量中。为了确保可读性，不可打印的字符应该在输出时转义，即使在这样的标量中也是如此。
Note: JSON [quoted scalars](https://yaml.org/spec/1.2.2/#double-quoted-
style) cannot span multiple lines or contain
tabs, but YAML quoted
scalars can.
注意：JSON引用的标量不能跨多行或包含制表符，但YAML引用的标量可以。
[2] nb-json ::=
x09 # Tab character
| [x20-x10FFFF] # Non-C0-control characters
Note: The production name
nb-jsonmeans “non-break JSON compatible” here.
注意：产品名称nb-json在这里表示“non-break JSON compatible”。
5.2. Character Encodings 5.2.字符编码
All characters mentioned in this specification are Unicode code points. Each
such code point is written as one or more bytes depending on the character
encoding used. Note that in UTF-16, characters above xFFFF are written as
four bytes, using a surrogate pair.
本规范中提到的所有字符都是Unicode码位。根据所使用的字符编码，每个这样的代码点被写成一个或多个字节。注意，在UTF-16中， xFFFF
以上的字符使用代理对写成四个字节。
The character encoding is a [presentation detail](https://yaml.org/spec/1.2.2
/#presenting-the-serialization-tree) and must not be used to convey
content information.
字符编码是表示细节，不得用于传达内容信息。
On input, a YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) must support the UTF-8 and UTF-16 character encodings. For JSON
compatibility, the UTF-32
encodings must also be supported.
在输入时，YAML处理器必须支持UTF-8和UTF-16字符编码。为了与JSON兼容，还必须支持UTF-32编码。
If a character stream begins with a
byte order mark , the character encoding will be taken to be as indicated by
the byte order mark. Otherwise, the
stream must begin with an ASCII
character. This allows the encoding to be deduced by the pattern of null
(x00) characters.
如果字符流以字节顺序标记开始，则字符编码将被视为字节顺序标记所指示的。否则，流必须以ASCII字符开始。这允许通过空（ x00 ）字符的模式推断编码。
Byte order marks may appear at the start of any
document, however all
documents in the same
stream must use the same character
encoding.
字节顺序标记可以出现在任何文档的开头，但是同一流中的所有文档必须使用相同的字符编码。
To allow for [JSON compatibility](https://yaml.org/spec/1.2.2/#yaml-
directives), byte order marks are also allowed inside quoted
scalars. For readability,
such content byte order marks should be
escaped on output.
为了允许JSON兼容性，也允许在带引号的标量中使用字节顺序标记。为了便于阅读，在输出时应该对这些内容字节顺序标记进行转义。
The encoding can therefore be deduced by matching the first few bytes of the
stream with the following table rows
(in order):
因此，可以通过将流的前几个字节与以下表行（按顺序）进行匹配来推断编码：
| Byte0 | Byte1 | Byte2 | Byte3 | Encoding
—|—|—|—|—|—
Explicit BOM | x00 | x00 | xFE | xFF | UTF-32BE
ASCII first character ASCII首字符 | x00 | x00 | x00 | any | UTF-32BE
Explicit BOM | xFF | xFE | x00 | x00 | UTF-32LE
ASCII first character ASCII首字符 | any | x00 | x00 | x00 | UTF-32LE
Explicit BOM | xFE | xFF | | | UTF-16BE
ASCII first character ASCII首字符 | x00 | any | | | UTF-16BE
Explicit BOM | xFF | xFE | | | UTF-16LE
ASCII first character ASCII首字符 | any | x00 | | | UTF-16LE
Explicit BOM | xEF | xBB | xBF | | UTF-8
Default | | | | | UTF-8
The recommended output encoding is UTF-8. If another encoding is used, it is
recommended that an explicit byte order mark be used, even if the first
stream character is ASCII.
推荐的输出编码是UTF-8。如果使用其他编码，建议使用显式字节顺序标记，即使第一个流字符是ASCII。
For more information about the byte order mark and the Unicode character
encoding schemes see the Unicode FAQ[17](https://yaml.org/spec/1.2.2/#fn:uni-
faq).
有关字节顺序标记和Unicode字符编码方案的详细信息，请参阅Unicode常见问题解答
17 。
[3] c-byte-order-mark ::= xFEFF
In the examples, byte order mark characters are displayed as “⇔”.
在示例中，字节顺序标记字符被显示为“ ⇔ ”。
Example 5.1 Byte Order Mark 例5.1字节顺序标记
⇔# Comment only.
|
# This stream contains no
# documents, only comments.
—|—
Legend:
[c-byte-order-mark](https://yaml.org/spec/1.2.2/#rule-c-byte-order-mark)
Example 5.2 Invalid Byte Order Mark
例5.2无效的字节顺序标记
- Invalid use of BOM
⇔
- Inside a document.
|
ERROR:
A BOM must not appear
inside a document.
—|—
5.3. Indicator Characters 5.3.指示符字符
Indicators are characters that have special semantics.
指示符是具有特殊语义的字符。
”-” (x2D, hyphen) denotes a [block sequence](https://yaml.org/spec/1.2.2
/#block-sequences) entry.
“ - ”（ x2D ，连字符）表示块序列条目。
[4] c-sequence-entry ::= '-'
”?” (x3F, question mark) denotes a mapping
key.
“ ? ”（ x3F ，问号）表示映射键。
[5] c-mapping-key ::= '?'
”:” (x3A, colon) denotes a mapping
value.
“ : ”（ x3A ，冒号）表示映射值。
[6] c-mapping-value ::= ':'
Example 5.3 Block Structure Indicators
示例5.3块结构指示符
sequence:
- one
- two
mapping:
? sky
: blue
sea : green
|
{ "sequence": [
"one",
"two" ],
"mapping": {
"sky": "blue",
"sea": "green" } }
—|—
Legend:
[c-sequence-entry](https://yaml.org/spec/1.2.2/#rule-c-sequence-entry)[c-mapping-key](https://yaml.org/spec/1.2.2/#rule-c-mapping-key)[c-mapping-value](https://yaml.org/spec/1.2.2/#rule-c-mapping-value)
”,” (x2C, comma) ends a [flow collection](https://yaml.org/spec/1.2.2
/#flow-collection-styles) entry.
“ , ”（ x2C ，逗号）结束流集合条目。
[7] c-collect-entry ::= ','
”[” (x5B, left bracket) starts a flow
sequence.
“ [ ”（ x5B ，左括号）启动流程序列。
[8] c-sequence-start ::= '['
”]” (x5D, right bracket) ends a flow
sequence.
“ ] ”（ x5D ，右括号）结束流程序列。
[9] c-sequence-end ::= ']'
”{” (x7B, left brace) starts a [flow mapping](https://yaml.org/spec/1.2.2
/#flow-mappings).
“ { ”（ x7B ，左大括号）启动流映射。
[10] c-mapping-start ::= '{'
”}” (x7D, right brace) ends a [flow mapping](https://yaml.org/spec/1.2.2
/#flow-mappings).
“ } ”（ x7D ，右大括号）结束流映射。
[11] c-mapping-end ::= '}'
Example 5.4 Flow Collection Indicators
示例5.4流量收集指示器
sequence: [ one, two, ]
mapping: { sky: blue, sea: green }
|
{ "sequence": [ "one", "two" ],
"mapping":
{ "sky": "blue", "sea": "green" } }
—|—
Legend:
[c-sequence-start](https://yaml.org/spec/1.2.2/#rule-c-sequence-start) [c-sequence-end](https://yaml.org/spec/1.2.2/#rule-c-sequence-end)[c-mapping-start](https://yaml.org/spec/1.2.2/#rule-c-mapping-start) [c-mapping-end](https://yaml.org/spec/1.2.2/#rule-c-mapping-end)[c-collect-entry](https://yaml.org/spec/1.2.2/#rule-c-collect-entry)
”#” (x23, octothorpe, hash, sharp, pound, number sign) denotes a
comment.
“ # ”（ x23 ，octothorpe，hash，sharp，磅，number sign）表示注释。
[12] c-comment ::= '#'
Example 5.5 Comment Indicator 示例5.5注释指示符
# Comment only.
|
# This stream contains no
# documents, only comments.
—|—
Legend:
[c-comment](https://yaml.org/spec/1.2.2/#rule-c-comment)
”&” (x26, ampersand) denotes a node’s anchor
property.
“ & ”（ x26 ，&）表示节点的锚属性。
[13] c-anchor ::= '&'
”*” (x2A, asterisk) denotes an [alias node](https://yaml.org/spec/1.2.2
/#alias-nodes).
“ * ”（ x2A ，星号）表示别名节点。
[14] c-alias ::= '*'
The “!” (x21, exclamation) is used for specifying node
tags. It is used to denote tag
handles used in tag
directives and tag
properties; to denote local
tags; and as the non-specific
tag for non-plain
scalars.
“ ! ”（ x21 ，感叹号）用于指定节点标记。它用于表示标记指令和标记属性中使用的标记句柄;以表示本地标签;并作为非普通标量的非特异性标记。
[15] c-tag ::= '!'
Example 5.6 Node Property Indicators
示例5.6节点属性指示符
anchored: !local &anchor value
alias: *anchor
|
{ "anchored": !local &A1 "value",
"alias": *A1 }
—|—
Legend:
[c-tag](https://yaml.org/spec/1.2.2/#rule-c-tag)[c-anchor](https://yaml.org/spec/1.2.2/#rule-c-anchor)[c-alias](https://yaml.org/spec/1.2.2/#rule-c-alias)
”|” (7C, vertical bar) denotes a literal block
scalar.
“ | ”（ 7C ，竖线）表示文字块标量。
[16] c-literal ::= '|'
”>” (x3E, greater than) denotes a folded block
scalar.
“ > ”（ x3E ，大于）表示折叠块标量。
[17] c-folded ::= '>'
Example 5.7 Block Scalar Indicators
示例5.7块标量指示符
literal: |
some
text
folded: >
some
text
|
{ "literal": "some\ntext\n",
"folded": "some text\n" }
—|—
Legend:
[c-literal](https://yaml.org/spec/1.2.2/#rule-c-literal)[c-folded](https://yaml.org/spec/1.2.2/#rule-c-folded)
”'” (x27, apostrophe, single quote) surrounds a single-quoted flow
scalar.
“ ' ”（ x27 ，撇号，单引号）包围单引号流量标量。
[18] c-single-quote ::= "'"
”"” (x22, double quote) surrounds a double-quoted flow
scalar.
“ " ”（ x22 ，双引号）包围双引号流量标量。
[19] c-double-quote ::= '"'
Example 5.8 Quoted Scalar Indicators
例5.8引用的标量指标
single: 'text'
double: "text"
|
{ "single": "text",
"double": "text" }
—|—
Legend:
[c-single-quote](https://yaml.org/spec/1.2.2/#rule-c-single-quote)[c-double-quote](https://yaml.org/spec/1.2.2/#rule-c-double-quote)
”%” (x25, percent) denotes a
directive line.
“ % ”（ x25 ，percent）表示指令行。
[20] c-directive ::= '%'
Example 5.9 Directive Indicator 示例5.9指令指示符
%YAML 1.2
--- text
|
"text"
—|—
Legend:
[c-directive](https://yaml.org/spec/1.2.2/#rule-c-directive)
The “@” (x40, at) and “” (`x60`, grave accent) are _reserved_ for future use. “ `@` ”（ `x40` ，at）和“ ”（ x60 ，grave accent）保留供将来使用。
[21] c-reserved ::=
'@' | '`'
Example 5.10 Invalid use of Reserved Indicators
例5.10保留指示符的无效使用
commercial-at: @text
grave-accent: `text
|
ERROR:
Reserved indicators can't
start a plain scalar.
—|—
Any indicator character: 任何指示符字符：
[22] c-indicator ::=
[c-sequence-entry](https://yaml.org/spec/1.2.2/#rule-c-sequence-entry) # '-'
| [c-mapping-key](https://yaml.org/spec/1.2.2/#rule-c-mapping-key) # '?'
| [c-mapping-value](https://yaml.org/spec/1.2.2/#rule-c-mapping-value) # ':'
| [c-collect-entry](https://yaml.org/spec/1.2.2/#rule-c-collect-entry) # ','
| [c-sequence-start](https://yaml.org/spec/1.2.2/#rule-c-sequence-start) # '['
| [c-sequence-end](https://yaml.org/spec/1.2.2/#rule-c-sequence-end) # ']'
| [c-mapping-start](https://yaml.org/spec/1.2.2/#rule-c-mapping-start) # '{'
| [c-mapping-end](https://yaml.org/spec/1.2.2/#rule-c-mapping-end) # '}'
| [c-comment](https://yaml.org/spec/1.2.2/#rule-c-comment) # '#'
| [c-anchor](https://yaml.org/spec/1.2.2/#rule-c-anchor) # '&'
| [c-alias](https://yaml.org/spec/1.2.2/#rule-c-alias) # '*'
| [c-tag](https://yaml.org/spec/1.2.2/#rule-c-tag) # '!'
| [c-literal](https://yaml.org/spec/1.2.2/#rule-c-literal) # '|'
| [c-folded](https://yaml.org/spec/1.2.2/#rule-c-folded) # '>'
| [c-single-quote](https://yaml.org/spec/1.2.2/#rule-c-single-quote) # "'"
| [c-double-quote](https://yaml.org/spec/1.2.2/#rule-c-double-quote) # '"'
| [c-directive](https://yaml.org/spec/1.2.2/#rule-c-directive) # '%'
| [c-reserved](https://yaml.org/spec/1.2.2/#rule-c-reserved) # '@' '`'
The “[”, “]”, “{”, “}” and “,” indicators denote structure in flow
collections. They are
therefore forbidden in some cases, to avoid ambiguity in several constructs.
This is handled on a case-by-case basis by the relevant productions.
“ [ ”、“ ] ”、“ { ”、“ } ”和“ ,
”指示符表示流集合中的结构。因此，在某些情况下，它们被禁止，以避免在几个结构中的歧义。这由相关制作部门根据具体情况处理。
[23] c-flow-indicator ::=
[c-collect-entry](https://yaml.org/spec/1.2.2/#rule-c-collect-entry) # ','
| [c-sequence-start](https://yaml.org/spec/1.2.2/#rule-c-sequence-start) # '['
| [c-sequence-end](https://yaml.org/spec/1.2.2/#rule-c-sequence-end) # ']'
| [c-mapping-start](https://yaml.org/spec/1.2.2/#rule-c-mapping-start) # '{'
| [c-mapping-end](https://yaml.org/spec/1.2.2/#rule-c-mapping-end) # '}'
5.4. Line Break Characters 5.4.换行符
YAML recognizes the following ASCII line break characters.
YAML识别以下ASCII换行符。
[24] b-line-feed ::= x0A
[25] b-carriage-return ::= x0D
[26] b-char ::=
[b-line-feed](https://yaml.org/spec/1.2.2/#rule-b-line-feed) # x0A
| [b-carriage-return](https://yaml.org/spec/1.2.2/#rule-b-carriage-return) # X0D
All other characters, including the form feed (x0C), are considered to be
non-break characters. Note that these include the non-ASCII line breaks :
next line (x85), line separator (x2028) and paragraph separator (x2029).
所有其他字符，包括换页符（ x0C ），都被视为非分隔字符。请注意，这些包括非ASCII换行符：下一行（ x85 ）、行分隔符（ x2028
）和段落分隔符（ x2029 ）。
YAML version 1.1 did support
the above non-ASCII line break characters; however, JSON does not. Hence, to
ensure JSON compatibility,
YAML treats them as non-break characters as of version 1.2. YAML 1.2
processors
parsing a
version 1.1
document should therefore treat
these line breaks as non-break characters, with an appropriate warning.
YAML版本1.1支持上述非ASCII换行符;但是，JSON却没有。因此，为了确保JSON兼容性，YAML从1.2版开始将它们视为非中断字符。YAML
1.2处理器 解析1.1版 因此，文档应该将这些换行符视为非换行符，并给出适当的警告。
[27] nb-char ::=
[c-printable](https://yaml.org/spec/1.2.2/#rule-c-printable) - [b-char](https://yaml.org/spec/1.2.2/#rule-b-char) - [c-byte-order-mark](https://yaml.org/spec/1.2.2/#rule-c-byte-order-mark)
Line breaks are interpreted differently by different systems and have multiple
widely used formats.
换行符在不同的系统中有不同的解释，并且有多种广泛使用的格式。
[28] b-break ::=
(
[b-carriage-return](https://yaml.org/spec/1.2.2/#rule-b-carriage-return) # x0A
[b-line-feed](https://yaml.org/spec/1.2.2/#rule-b-line-feed)
) # x0D
| [b-carriage-return](https://yaml.org/spec/1.2.2/#rule-b-carriage-return)
| [b-line-feed](https://yaml.org/spec/1.2.2/#rule-b-line-feed)
Line breaks inside scalar content must
be normalized by the YAML [processor](https://yaml.org/spec/1.2.2
/#processes-and-models). Each such line break must be
parsed into a
single line feed character. The original line break format is a presentation
detail and
must not be used to convey content
information.
标量内容中的换行符必须由YAML处理器规范化。每个这样的换行符必须被解析为单个换行符。原始的换行符格式是一种表示细节，不得用于传达内容信息。
[29] b-as-line-feed ::=
[b-break](https://yaml.org/spec/1.2.2/#rule-b-break)
Outside scalar content, YAML allows any
line break to be used to terminate lines.
在标量内容之外，YAML允许使用任何换行符来终止行。
[30] b-non-content ::=
[b-break](https://yaml.org/spec/1.2.2/#rule-b-break)
On output, a YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) is free to emit line breaks using whatever convention is most
appropriate.
在输出时，YAML处理器可以自由地使用任何最合适的约定发出换行符。
In the examples, line breaks are sometimes displayed using the “↓” glyph for
clarity.
在示例中，为了清楚起见，有时使用“ ↓ ”字形来显示换行符。
Example 5.11 Line Break Characters
例5.11换行符
|
Line break (no glyph)
Line break (glyphed)↓
|
"Line break (no glyph)\nLine break (glyphed)\n"
—|—
Legend:
[b-break](https://yaml.org/spec/1.2.2/#rule-b-break)
5.5. White Space Characters 5.5.白色字符
YAML recognizes two white space characters: space and tab.
YAML识别两个白色字符：空格和制表符。
[31] s-space ::= x20
[32] s-tab ::= x09
[33] s-white ::=
[s-space](https://yaml.org/spec/1.2.2/#rule-s-space) | [s-tab](https://yaml.org/spec/1.2.2/#rule-s-tab)
The rest of the (printable)
non-break characters are
considered to be non-space characters.
其余的（可打印的）非分隔字符被认为是非空格字符。
[34] ns-char ::=
[nb-char](https://yaml.org/spec/1.2.2/#rule-nb-char) - [s-white](https://yaml.org/spec/1.2.2/#rule-s-white)
In the examples, tab characters are displayed as the glyph “→”. Space
characters are sometimes displayed as the glyph “·” for clarity.
在示例中，制表符被显示为字形“ → ”。为了清楚起见，空格字符有时显示为字形“ · ”。
Example 5.12 Tabs and Spaces 示例5.12制表符和空格
# Tabs and spaces
quoted:·"Quoted →"
block:→|
··void main() {
··→printf("Hello, world!\n");
··}
|
{ "quoted": "Quoted \t",
"block": "void main()
{\n\tprintf(\"Hello, world!\\n\");\n}\n" }
—|—
Legend:
[s-space](https://yaml.org/spec/1.2.2/#rule-s-space)[s-tab](https://yaml.org/spec/1.2.2/#rule-s-tab)
5.6. Miscellaneous Characters 5.6.其他字符
The YAML syntax productions make use of the following additional character
classes:
YAML语法产品使用以下附加字符类：
A decimal digit for numbers: 数字的十进制数字：
[35] ns-dec-digit ::=
[x30-x39] # 0-9
A hexadecimal digit for [escape sequences](https://yaml.org/spec/1.2.2
/#escaped-characters):
转义序列的十六进制数字：
[36] ns-hex-digit ::=
[ns-dec-digit](https://yaml.org/spec/1.2.2/#rule-ns-dec-digit) # 0-9
| [x41-x46] # A-F
| [x61-x66] # a-f
ASCII letter (alphabetic) characters:
ASCII字母（字母）字符：
[37] ns-ascii-letter ::=
[x41-x5A] # A-Z
| [x61-x7A] # a-z
Word (alphanumeric) characters for identifiers:
用于标识符的单词（字母数字）字符：
[38] ns-word-char ::=
[ns-dec-digit](https://yaml.org/spec/1.2.2/#rule-ns-dec-digit) # 0-9
| [ns-ascii-letter](https://yaml.org/spec/1.2.2/#rule-ns-ascii-letter) # A-Z a-z
| '-' # '-'
URI characters for tags, as defined in
the URI specification18.
标记的URI字符，如URI规范 18 中定义的。
By convention, any URI characters other than the allowed printable ASCII
characters are first encoded in UTF-8 and then each byte is escaped using
the “% ” character. The YAML [processor](https://yaml.org/spec/1.2.2
/#processes-and-models) must not expand such escaped characters.
Tag characters must be preserved and
compared exactly as [presented](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) in the YAML
stream, without any processing.
按照惯例，除了允许打印的ASCII字符之外的任何URI字符都首先以UTF-8编码，然后使用“ %
”字符对每个字节进行转义。YAML处理器不得扩展此类转义字符。 标记字符必须按照YAML流中所呈现的完全保留和比较，而不需要进行任何处理。
[39] ns-uri-char ::=
(
'%'
[ns-hex-digit](https://yaml.org/spec/1.2.2/#rule-ns-hex-digit){2}
)
| [ns-word-char](https://yaml.org/spec/1.2.2/#rule-ns-word-char)
| '#'
| ';'
| '/'
| '?'
| ':'
| '@'
| '&'
| '='
| '+'
| '$'
| ','
| '_'
| '.'
| '!'
| '~'
| '*'
| "'"
| '('
| ')'
| '['
| ']'
The “!” character is used to indicate the end of a named tag
handle; hence its use in tag
shorthands is restricted. In
addition, such shorthands must
not contain the “[”, “]”, “{”, “}” and “,” characters. These
characters would cause ambiguity with flow
collection structures.
“ ! ”字符用于指示命名标记句柄的结束;因此限制了其在标记短编中使用。此外，此类短号不得包含“ [ ”、“ ] ”、“ { ”、“ }
”和“ , ”字符。这些字符将导致流集合结构的歧义。
[40] ns-tag-char ::=
[ns-uri-char](https://yaml.org/spec/1.2.2/#rule-ns-uri-char)
- [c-tag](https://yaml.org/spec/1.2.2/#rule-c-tag) # '!'
- [c-flow-indicator](https://yaml.org/spec/1.2.2/#rule-c-flow-indicator)
5.7. Escaped Characters 5.7.逃脱的角色
All non-printable characters
must be escaped. YAML escape sequences use the “\ ” notation common to
most modern computer languages. Each escape sequence must be
parsed into
the appropriate Unicode character. The original escape sequence is a
[presentation detail](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) and must not be used to convey
content information.
所有不可打印的字符必须转义。YAML转义序列使用大多数现代计算机语言常见的“ \
”符号。每个转义序列都必须解析为相应的Unicode字符。原始转义序列是表示细节，不得用于传达内容信息。
Note that escape sequences are only interpreted in double-quoted
scalars. In all other
scalar styles, the “\” character
has no special meaning and non-[printable](https://yaml.org/spec/1.2.2
/#character-set) characters are not available.
请注意，转义序列仅在双引号标量中解释。在所有其他标量样式中，“ \ ”字符没有特殊含义，不可打印的字符不可用。
[41] c-escape ::= '\'
YAML escape sequences are a superset of C’s escape sequences:
YAML转义序列是C转义序列的超集：
Escaped ASCII null (x00) character.
转义ASCII空（ x00 ）字符。
[42] ns-esc-null ::= '0'
Escaped ASCII bell (x07) character.
转义ASCII响铃（ x07 ）字符。
[43] ns-esc-bell ::= 'a'
Escaped ASCII backspace (x08) character.
转义ASCII退格（ x08 ）字符。
[44] ns-esc-backspace ::= 'b'
Escaped ASCII horizontal tab (x09) character. This is useful at the start or
the end of a line to force a leading or trailing tab to become part of the
content.
转义ASCII水平制表符（ x09 ）字符。这在行的开头或结尾处非常有用，可以强制前导或尾随选项卡成为内容的一部分。
[45] ns-esc-horizontal-tab ::=
't' | x09
Escaped ASCII line feed (x0A) character.
转义ASCII换行符（ x0A ）字符。
[46] ns-esc-line-feed ::= 'n'
Escaped ASCII vertical tab (x0B) character.
转义ASCII垂直制表符（ x0B ）字符。
[47] ns-esc-vertical-tab ::= 'v'
Escaped ASCII form feed (x0C) character.
转义ASCII换页（ x0C ）字符。
[48] ns-esc-form-feed ::= 'f'
Escaped ASCII carriage return (x0D) character.
转义ASCII回车（ x0D ）字符。
[49] ns-esc-carriage-return ::= 'r'
Escaped ASCII escape (x1B) character.
转义的ASCII转义（ x1B ）字符。
[50] ns-esc-escape ::= 'e'
Escaped ASCII space (x20) character. This is useful at the start or the end
of a line to force a leading or trailing space to become part of the
content.
转义ASCII空格（ x20 ）字符。这在行首或行尾很有用，可以强制前导或尾随空格成为内容的一部分。
[51] ns-esc-space ::= x20
Escaped ASCII double quote (x22).
转义ASCII双引号（ x22 ）。
[52] ns-esc-double-quote ::= '"'
Escaped ASCII slash (x2F), for JSON
compatibility.
转义ASCII斜杠（ x2F ），用于JSON兼容性。
[53] ns-esc-slash ::= '/'
Escaped ASCII back slash (x5C).
转义ASCII反斜杠（ x5C ）。
[54] ns-esc-backslash ::= '\'
Escaped Unicode next line (x85) character.
转义Unicode下一行（ x85 ）字符。
[55] ns-esc-next-line ::= 'N'
Escaped Unicode non-breaking space (xA0) character.
转义的Unicode非中断空格（ xA0 ）字符。
[56] ns-esc-non-breaking-space ::= '_'
Escaped Unicode line separator (x2028) character.
转义的Unicode行分隔符（ x2028 ）字符。
[57] ns-esc-line-separator ::= 'L'
Escaped Unicode paragraph separator (x2029) character.
转义的Unicode段落分隔符（ x2029 ）字符。
[58] ns-esc-paragraph-separator ::= 'P'
Escaped 8-bit Unicode character. 转义的8位Unicode字符。
[59] ns-esc-8-bit ::=
'x'
[ns-hex-digit](https://yaml.org/spec/1.2.2/#rule-ns-hex-digit){2}
Escaped 16-bit Unicode character.
转义的16位Unicode字符。
[60] ns-esc-16-bit ::=
'u'
[ns-hex-digit](https://yaml.org/spec/1.2.2/#rule-ns-hex-digit){4}
Escaped 32-bit Unicode character.
转义的32位Unicode字符。
[61] ns-esc-32-bit ::=
'U'
[ns-hex-digit](https://yaml.org/spec/1.2.2/#rule-ns-hex-digit){8}
Any escaped character: 任何转义字符：
[62] c-ns-esc-char ::=
[c-escape](https://yaml.org/spec/1.2.2/#rule-c-escape) # '\'
(
[ns-esc-null](https://yaml.org/spec/1.2.2/#rule-ns-esc-null)
| [ns-esc-bell](https://yaml.org/spec/1.2.2/#rule-ns-esc-bell)
| [ns-esc-backspace](https://yaml.org/spec/1.2.2/#rule-ns-esc-backspace)
| [ns-esc-horizontal-tab](https://yaml.org/spec/1.2.2/#rule-ns-esc-horizontal-tab)
| [ns-esc-line-feed](https://yaml.org/spec/1.2.2/#rule-ns-esc-line-feed)
| [ns-esc-vertical-tab](https://yaml.org/spec/1.2.2/#rule-ns-esc-vertical-tab)
| [ns-esc-form-feed](https://yaml.org/spec/1.2.2/#rule-ns-esc-form-feed)
| [ns-esc-carriage-return](https://yaml.org/spec/1.2.2/#rule-ns-esc-carriage-return)
| [ns-esc-escape](https://yaml.org/spec/1.2.2/#rule-ns-esc-escape)
| [ns-esc-space](https://yaml.org/spec/1.2.2/#rule-ns-esc-space)
| [ns-esc-double-quote](https://yaml.org/spec/1.2.2/#rule-ns-esc-double-quote)
| [ns-esc-slash](https://yaml.org/spec/1.2.2/#rule-ns-esc-slash)
| [ns-esc-backslash](https://yaml.org/spec/1.2.2/#rule-ns-esc-backslash)
| [ns-esc-next-line](https://yaml.org/spec/1.2.2/#rule-ns-esc-next-line)
| [ns-esc-non-breaking-space](https://yaml.org/spec/1.2.2/#rule-ns-esc-non-breaking-space)
| [ns-esc-line-separator](https://yaml.org/spec/1.2.2/#rule-ns-esc-line-separator)
| [ns-esc-paragraph-separator](https://yaml.org/spec/1.2.2/#rule-ns-esc-paragraph-separator)
| [ns-esc-8-bit](https://yaml.org/spec/1.2.2/#rule-ns-esc-8-bit)
| [ns-esc-16-bit](https://yaml.org/spec/1.2.2/#rule-ns-esc-16-bit)
| [ns-esc-32-bit](https://yaml.org/spec/1.2.2/#rule-ns-esc-32-bit)
)
Example 5.13 Escaped Characters 示例5.13转义字符
- "Fun with \\"
- "\" \a \b \e \f"
- "\n \r \t \v \0"
- "\ \_ \N \L \P \
\x41 \u0041 \U00000041"
|
[ "Fun with \\",
"\" \u0007 \b \u001b \f",
"\n \r \t \u000b \u0000",
"\u0020 \u00a0 \u0085 \u2028 \u2029 A A A" ]
—|—
Legend:
[c-ns-esc-char](https://yaml.org/spec/1.2.2/#rule-c-ns-esc-char)
Example 5.14 Invalid Escaped Characters
例5.14无效的转义字符
Bad escapes:
"\c
\xq-"
|
ERROR:
- c is an invalid escaped character.
- q and - are invalid hex digits.
—|—
Chapter 6. Structural Productions
第6章：结构制作
6.1. Indentation Spaces 6.1.缩进空间
In YAML block styles,
structure is determined by indentation. In general, indentation is defined
as a zero or more space
characters at the start of a line.
在YAML块样式中，结构由缩进确定。一般来说，缩进定义为在一行的开始处有零个或多个空格字符。
To maintain portability, [tab](https://yaml.org/spec/1.2.2/#white-space-
characters) characters must not be used in indentation, since different
systems treat tabs
differently. Note that most modern editors may be configured so that pressing
the tab key results in
the insertion of an appropriate number of [spaces](https://yaml.org/spec/1.2.2
/#white-space-characters).
为了保持可移植性，不能在缩进中使用制表符，因为不同的系统对制表符的处理是不同的。请注意，大多数现代编辑器都可以配置为按Tab键插入适当数量的空格。
The amount of indentation is a presentation
detail and
must not be used to convey content
information.
缩进量是表示细节，不得用于传达内容信息。
[63]
s-indent(0) ::=
<empty>
# When n≥0
s-indent(n+1) ::=
[s-space](https://yaml.org/spec/1.2.2/#rule-s-space) [s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n)
A block style
construct is terminated when encountering a line which is less indented than
the construct. The productions use the notation “s-indent-less-than(n)” and
“s-indent-less-or-equal(n)” to express this.
块样式构造在遇到缩进小于构造的行时终止。产生式使用符号“ s-indent-less-than(n) ”和“ s-indent-less-or- equal(n) ”来表达这一点。
[64]
s-indent-less-than(1) ::=
<empty>
# When n≥1
s-indent-less-than(n+1) ::=
[s-space](https://yaml.org/spec/1.2.2/#rule-s-space) [s-indent-less-than](https://yaml.org/spec/1.2.2/#rule-s-indent-less-than)(n)
| <empty>
[65]
s-indent-less-or-equal(0) ::=
<empty>
# When n≥0
s-indent-less-or-equal(n+1) ::=
[s-space](https://yaml.org/spec/1.2.2/#rule-s-space) [s-indent-less-or-equal](https://yaml.org/spec/1.2.2/#rule-s-indent-less-or-equal)(n)
| <empty>
Each node must be indented further than
its parent node. All sibling
nodes must use the exact same
indentation level. However the content
of each sibling node may be further
indented independently.
每个节点必须比其父节点缩进得更深。所有同级节点必须使用完全相同的缩进级别。然而，每个兄弟节点的内容可以被进一步独立地缩进。
Example 6.1 Indentation Spaces 示例6.1缩进空间
··# Leading comment line spaces are
···# neither content nor indentation.
····
Not indented:
·By one space: |
····By four
······spaces
·Flow style: [ # Leading spaces
···By two, # in flow style
··Also by two, # are neither
··→Still by two # content nor
····] # indentation.
|
{ "Not indented": {
"By one space": "By four\n spaces\n",
"Flow style": [
"By two",
"Also by two",
"Still by two" ] } }
—|—
Legend:
[s-indent(n)](https://yaml.org/spec/1.2.2/#rule-s-indent)ContentNeither content nor indentation
The “-”, “?” and “:” characters used to denote block
collection entries are
perceived by people to be part of the indentation. This is handled on a case-
by-case basis by the relevant productions.
用于表示块集合条目的“ - ”、“ ? ”和“ : ”字符被人们认为是缩进的一部分。这由相关制作部门根据具体情况处理。
Example 6.2 Indentation Indicators
实施例6.2压痕指示器
?·a
:·-→b
··-··-→c
·····-·d
|
{ "a":
[ "b",
[ "c",
"d" ] ] }
—|—
Legend:
Total Indentation[s-indent(n)](https://yaml.org/spec/1.2.2/#rule-s-indent)Indicator as indentation
6.2. Separation Spaces 6.2.分隔空间
Outside indentation and
scalar content, YAML uses white
space characters for
separation between tokens within a line. Note that such white
space may safely include
tab characters.
在缩进和标量内容之外，YAML使用白色字符来分隔行内的标记。注意，这样白色可以安全地包括制表符。
Separation spaces are a [presentation detail](https://yaml.org/spec/1.2.2
/#presenting-the-serialization-tree) and must not be used to convey
content information.
分隔空间是表示细节，不得用于传达内容信息。
[66] s-separate-in-line ::=
[s-white](https://yaml.org/spec/1.2.2/#rule-s-white)+
| <start-of-line>
Example 6.3 Separation Spaces 例6.3分离空间
-·foo:→·bar
- -·baz
-→baz
|
[ { "foo": "bar" },
[ "baz",
"baz" ] ]
—|—
Legend:
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
6.3. Line Prefixes 6.3.行前缀
Inside scalar content, each line begins
with a non-content line prefix. This
prefix always includes the [indentation](https://yaml.org/spec/1.2.2
/#indentation-spaces). For [flow scalar styles](https://yaml.org/spec/1.2.2
/#flow-scalar-styles) it additionally includes all leading white
space , which may
contain tab characters.
在标量内容中，每一行都以非内容行前缀开头.此前缀始终包括缩进。对于流标量样式，它还包括所有前导白色，这些空白可能包含制表符。
Line prefixes are a [presentation detail](https://yaml.org/spec/1.2.2
/#presenting-the-serialization-tree) and must not be used to convey
content information.
行前缀是表示细节，不得用于传达内容信息。
[67]
s-line-prefix(n,BLOCK-OUT) ::= [s-block-line-prefix](https://yaml.org/spec/1.2.2/#rule-s-block-line-prefix)(n)
s-line-prefix(n,BLOCK-IN) ::= [s-block-line-prefix](https://yaml.org/spec/1.2.2/#rule-s-block-line-prefix)(n)
s-line-prefix(n,FLOW-OUT) ::= [s-flow-line-prefix](https://yaml.org/spec/1.2.2/#rule-s-flow-line-prefix)(n)
s-line-prefix(n,FLOW-IN) ::= [s-flow-line-prefix](https://yaml.org/spec/1.2.2/#rule-s-flow-line-prefix)(n)
[68] s-block-line-prefix(n) ::=
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n)
[69] s-flow-line-prefix(n) ::=
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n)
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)?
Example 6.4 Line Prefixes 示例6.4行前缀
plain: text
··lines
quoted: "text
··→lines"
block: |
··text
···→lines
|
{ "plain": "text lines",
"quoted": "text lines",
"block": "text\n \tlines\n" }
—|—
Legend:
[s-flow-line-prefix(n)](https://yaml.org/spec/1.2.2/#rule-s-flow-line-prefix)[s-block-line-prefix(n)](https://yaml.org/spec/1.2.2/#rule-s-block-line-prefix)[s-indent(n)](https://yaml.org/spec/1.2.2/#rule-s-indent)
6.4. Empty Lines 6.4.空行
An empty line line consists of the
non-content
prefix followed by a line
break.
空行由非内容组成 前缀后跟换行符。
[70] l-empty(n,c) ::=
(
[s-line-prefix](https://yaml.org/spec/1.2.2/#rule-s-line-prefix)(n,c)
| [s-indent-less-than](https://yaml.org/spec/1.2.2/#rule-s-indent-less-than)(n)
)
[b-as-line-feed](https://yaml.org/spec/1.2.2/#rule-b-as-line-feed)
The semantics of empty lines depend on the scalar
style they appear in. This is
handled on a case-by-case basis by the relevant productions.
空行的语义取决于它们出现的标量样式。这由相关制作部门根据具体情况处理。
Example 6.5 Empty Lines 例6.5空行
Folding:
"Empty line
···→
as a line feed"
Chomping: |
Clipped empty lines
·
|
{ "Folding": "Empty line\nas a line feed",
"Chomping": "Clipped empty lines\n" }
—|—
Legend:
[l-empty(n,c)](https://yaml.org/spec/1.2.2/#rule-l-empty)
6.5. Line Folding 6.5.线折叠
Line folding allows long lines to be broken for readability, while retaining
the semantics of the original long line. If a line
break is followed by an
empty line , it is trimmed ; the
first line break is
discarded and the rest are retained as
content.
行折叠允许为了可读性而断开长行，同时保留原始长行的语义。如果换行符后面是空行，则会被修剪;第一个换行符被丢弃，其余的作为内容被保留。
[71] b-l-trimmed(n,c) ::=
[b-non-content](https://yaml.org/spec/1.2.2/#rule-b-non-content)
[l-empty](https://yaml.org/spec/1.2.2/#rule-l-empty)(n,c)+
Otherwise (the following line is not [empty](https://yaml.org/spec/1.2.2
/#empty-lines)), the [line break](https://yaml.org/spec/1.2.2/#line-break-
characters) is converted to a single [space](https://yaml.org/spec/1.2.2
/#white-space-characters) (x20).
否则（下面的行不为空），换行符将转换为单个空格（ x20 ）。
[72] b-as-space ::=
[b-break](https://yaml.org/spec/1.2.2/#rule-b-break)
A folded non-empty line may end
with either of the above [line breaks](https://yaml.org/spec/1.2.2/#line-
break-characters).
折叠的非空行可以以上述两种换行符之一结束.
[73] b-l-folded(n,c) ::=
[b-l-trimmed](https://yaml.org/spec/1.2.2/#rule-b-l-trimmed)(n,c) | [b-as-space](https://yaml.org/spec/1.2.2/#rule-b-as-space)
Example 6.6 Line Folding 示例6.6线折叠
>-
trimmed↓
··↓
·↓
↓
as↓
space
|
"trimmed\n\n\nas space"
—|—
Legend:
[b-l-trimmed(n,c)](https://yaml.org/spec/1.2.2/#rule-b-l-trimmed)[b-as-space](https://yaml.org/spec/1.2.2/#rule-b-as-space)
The above rules are common to both the folded block
style and the scalar flow
styles. Folding does
distinguish between these cases in the following way:
上述规则对于折叠块样式和标量流样式都是通用的。折叠确实以以下方式区分这些情况：
Block Folding
In the folded block style, the
final line break and
trailing empty lines are subject
to chomping and are
never folded. In addition, folding does not apply to line
breaks surrounding text
lines that contain leading [white space](https://yaml.org/spec/1.2.2/#white-
space-characters). Note that such a more-
indented line may
consist only of such leading [white space](https://yaml.org/spec/1.2.2/#white-
space-characters).
在折叠的块样式中，最后一个换行符和尾随的空行会被咬合，并且永远不会被折叠。此外，折叠不适用于包含前导白色的文本行周围的换行符。请注意，这种缩进较多的行可能仅由这种前导白色组成。
The combined effect of the block line folding rules is that each “paragraph”
is interpreted as a line, [empty lines](https://yaml.org/spec/1.2.2/#empty-
lines) are interpreted as a line feed and the formatting of more-
indented lines is
preserved.
块行折叠规则的组合效果是每个“段落”被解释为一行，空行被解释为换行符，并且保留了更多缩进行的格式。
Example 6.7 Block Folding 实施例6.7块折叠
>
··foo·↓
·↓
··→·bar↓
↓
··baz↓
|
"foo \n\n\t bar\n\nbaz\n"
—|—
Legend:
[b-l-folded(n,c)](https://yaml.org/spec/1.2.2/#rule-b-l-folded)Non-content spacesContent spaces
Flow Folding
Folding in flow styles
provides more relaxed semantics. [Flow styles](https://yaml.org/spec/1.2.2
/#flow-style-productions) typically depend on explicit
indicators rather than
indentation to convey
structure. Hence spaces preceding or following the text in a line are a
[presentation detail](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) and must not be used to convey
content information. Once all such
spaces have been discarded, all [line breaks](https://yaml.org/spec/1.2.2
/#line-break-characters) are folded without exception.
流样式中的折叠提供了更宽松的语义。
流样式通常依赖于显式指示符而不是缩进来传达结构。因此，行中文本前后的空格是表示细节，不得用于传达内容信息。一旦所有这样的空格都被丢弃，所有的换行符都会毫无例外地被折叠。
The combined effect of the flow line folding rules is that each “paragraph”
is interpreted as a line, [empty lines](https://yaml.org/spec/1.2.2/#empty-
lines) are interpreted as line feeds and text can be freely more-
indented without
affecting the content information.
流线折叠规则的组合效果是每个“段落”被解释为一行，空行被解释为换行符，并且文本可以自由地缩进而不影响内容信息。
[74] s-flow-folded(n) ::=
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)?
[b-l-folded](https://yaml.org/spec/1.2.2/#rule-b-l-folded)(n,FLOW-IN)
[s-flow-line-prefix](https://yaml.org/spec/1.2.2/#rule-s-flow-line-prefix)(n)
Example 6.8 Flow Folding 示例6.8流动折叠
"↓
··foo·↓
·↓
··→·bar↓
↓
··baz↓ "
|
" foo\nbar\nbaz "
—|—
Legend:
[s-flow-folded(n)](https://yaml.org/spec/1.2.2/#rule-s-flow-folded)Non-content spaces
6.6. Comments
An explicit comment is marked by a “# ” indicator. Comments are a
[presentation detail](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) and must not be used to convey
content information.
显式注释由“ # ”指示符标记。注释是表示细节，不得用于传达内容信息。
Comments must be separated
from other tokens by [white space](https://yaml.org/spec/1.2.2/#white-space-
characters) characters.
注释必须用白色字符与其他标记分隔开。
Note: To ensure [JSON compatibility](https://yaml.org/spec/1.2.2/#yaml-
directives), YAML [processors](https://yaml.org/spec/1.2.2/#processes-and-
models) must allow for the omission of the final comment line
break of the input
stream. However, as this confuses many
tools, YAML processors
should terminate the stream with an
explicit line break on
output.
注意：为了确保JSON兼容性，YAML处理器必须允许省略输入流的最后一个注释换行符。但是，由于这会混淆许多工具，YAML处理器应该在输出时使用显式换行符终止流。
[75] c-nb-comment-text ::=
[c-comment](https://yaml.org/spec/1.2.2/#rule-c-comment) # '#'
[nb-char](https://yaml.org/spec/1.2.2/#rule-nb-char)*
[76] b-comment ::=
[b-non-content](https://yaml.org/spec/1.2.2/#rule-b-non-content)
| <end-of-input>
[77] s-b-comment ::=
(
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
[c-nb-comment-text](https://yaml.org/spec/1.2.2/#rule-c-nb-comment-text)?
)?
[b-comment](https://yaml.org/spec/1.2.2/#rule-b-comment)
Example 6.9 Separated Comment 示例6.9分隔注释
key:····# Comment↓
value _eof_
|
{ "key": "value" }
—|—
Legend:
[c-nb-comment-text](https://yaml.org/spec/1.2.2/#rule-c-nb-comment-text)[b-comment](https://yaml.org/spec/1.2.2/#rule-b-comment)[s-b-comment](https://yaml.org/spec/1.2.2/#rule-s-b-comment)
Outside scalar content, comments may
appear on a line of their own, independent of the
indentation level. Note
that outside scalar content, a line
containing only [white space](https://yaml.org/spec/1.2.2/#white-space-
characters) characters is taken to be a comment line.
在标量内容之外，注释可以单独出现在一行中，与缩进级别无关。请注意，在标量内容之外，仅包含白色字符的行被视为注释行。
[78] l-comment ::=
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
[c-nb-comment-text](https://yaml.org/spec/1.2.2/#rule-c-nb-comment-text)?
[b-comment](https://yaml.org/spec/1.2.2/#rule-b-comment)
Example 6.10 Comment Lines 示例6.10注释行
··# Comment↓
···↓
↓
|
# This stream contains no
# documents, only comments.
—|—
Legend:
[s-b-comment](https://yaml.org/spec/1.2.2/#rule-s-b-comment)[l-comment](https://yaml.org/spec/1.2.2/#rule-l-comment)
In most cases, when a line may end with a comment, YAML allows it to be
followed by additional comment lines. The only exception is a comment ending a
block scalar header.
在大多数情况下，当一行可能以注释结束时，YAML允许它后面跟随其他注释行。唯一的例外是结束块标量标头的注释。
[79] s-l-comments ::=
(
[s-b-comment](https://yaml.org/spec/1.2.2/#rule-s-b-comment)
| <start-of-line>
)
[l-comment](https://yaml.org/spec/1.2.2/#rule-l-comment)*
Example 6.11 Multi-Line Comments 例6.11多行注释
key:····# Comment↓
········# lines↓
value↓
↓
|
{ "key": "value" }
—|—
Legend:
[s-b-comment](https://yaml.org/spec/1.2.2/#rule-s-b-comment)[l-comment](https://yaml.org/spec/1.2.2/#rule-l-comment)[s-l-comments](https://yaml.org/spec/1.2.2/#rule-s-l-comments)
6.7. Separation Lines 6.7.分隔线
[Implicit keys](https://yaml.org/spec/1.2.2/#example-single-pair-explicit-
entry) are restricted to a single line. In all other cases, YAML allows tokens
to be separated by multi-line (possibly empty)
comments.
隐式键被限制在一行中。在所有其他情况下，YAML允许标记由多行（可能为空）注释分隔。
Note that structures following multi-line comment separation must be properly
indented, even though there
is no such restriction on the separation
comment lines themselves.
注意，多行注释分隔之后的结构必须正确缩进，即使分隔注释行本身没有这样的限制。
[80]
s-separate(n,BLOCK-OUT) ::= [s-separate-lines](https://yaml.org/spec/1.2.2/#rule-s-separate-lines)(n)
s-separate(n,BLOCK-IN) ::= [s-separate-lines](https://yaml.org/spec/1.2.2/#rule-s-separate-lines)(n)
s-separate(n,FLOW-OUT) ::= [s-separate-lines](https://yaml.org/spec/1.2.2/#rule-s-separate-lines)(n)
s-separate(n,FLOW-IN) ::= [s-separate-lines](https://yaml.org/spec/1.2.2/#rule-s-separate-lines)(n)
s-separate(n,BLOCK-KEY) ::= [s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
s-separate(n,FLOW-KEY) ::= [s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
[81] s-separate-lines(n) ::=
(
[s-l-comments](https://yaml.org/spec/1.2.2/#rule-s-l-comments)
[s-flow-line-prefix](https://yaml.org/spec/1.2.2/#rule-s-flow-line-prefix)(n)
)
| [s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
Example 6.12 Separation Spaces 例6.12分离空间
{·first:·Sammy,·last:·Sosa·}:↓
# Statistics:
··hr:··# Home runs
·····65
··avg:·# Average
···0.278
|
{ { "first": "Sammy",
"last": "Sosa" }: {
"hr": 65,
"avg": 0.278 } }
—|—
Legend:
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)[s-separate-lines(n)](https://yaml.org/spec/1.2.2/#rule-s-separate-lines)[s-indent(n)](https://yaml.org/spec/1.2.2/#rule-s-indent)
6.8. Directives
Directives are instructions to the YAML
processor. This
specification defines two directives, “YAML ” and “TAG”, and reserves
all other directives for future use. There is no way to define private
directives. This is intentional.
指令是对YAML处理器的指令。本规范定义了两个指令，“ YAML ”和“ TAG
”，并保留所有其他指令供将来使用。没有办法定义私有指令。这是故意的。
Directives are a [presentation detail](https://yaml.org/spec/1.2.2
/#presenting-the-serialization-tree) and must not be used to convey
content information.
指令是一种表示细节，不得用于传达内容信息。
[82] l-directive ::=
[c-directive](https://yaml.org/spec/1.2.2/#rule-c-directive) # '%'
(
[ns-yaml-directive](https://yaml.org/spec/1.2.2/#rule-ns-yaml-directive)
| [ns-tag-directive](https://yaml.org/spec/1.2.2/#rule-ns-tag-directive)
| [ns-reserved-directive](https://yaml.org/spec/1.2.2/#rule-ns-reserved-directive)
)
[s-l-comments](https://yaml.org/spec/1.2.2/#rule-s-l-comments)
Each directive is specified on a separate
non-indented line starting
with the “%” indicator, followed by the directive name and a list of
parameters. The semantics of these parameters depends on the specific
directive. A YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) should ignore unknown directives with an appropriate warning.
每个指令都在单独的非缩进行中指定，以“ %
”指示符开始，后跟指令名称和参数列表。这些参数的语义取决于特定的指令。YAML处理器应忽略未知指令并发出适当的警告。
[83] ns-reserved-directive ::=
[ns-directive-name](https://yaml.org/spec/1.2.2/#rule-ns-directive-name)
(
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
[ns-directive-parameter](https://yaml.org/spec/1.2.2/#rule-ns-directive-parameter)
)*
[84] ns-directive-name ::=
[ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char)+
[85] ns-directive-parameter ::=
[ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char)+
Example 6.13 Reserved Directives 例6.13保留指令
%FOO bar baz # Should be ignored
# with a warning.
--- "foo"
|
"foo"
—|—
Legend:
[ns-reserved-directive](https://yaml.org/spec/1.2.2/#rule-ns-reserved-directive)[ns-directive-name](https://yaml.org/spec/1.2.2/#rule-ns-directive-name)[ns-directive-parameter](https://yaml.org/spec/1.2.2/#rule-ns-directive-parameter)
6.8.1. “YAML” Directives 6.8.1.“ YAML ”指令
The “YAML” directive specifies the version of YAML the
document conforms to. This
specification defines version “1.2”, including recommendations for YAML 1.1
processing.
“ YAML ”指令指定文档符合的YAML版本。本规范定义了版本“ 1.2 ”，包括YAML 1.1处理的建议。
A version 1.2 YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) must accept documents with
an explicit “%YAML 1.2” directive, as well as
documents lacking a “YAML”
directive. Such documents are
assumed to conform to the 1.2 version specification.
Documents with a “YAML” directive
specifying a higher minor version (e.g. “%YAML 1.3”) should be processed
with an appropriate warning.
Documents with a “YAML” directive
specifying a higher major version (e.g. “%YAML 2.0”) should be rejected with
an appropriate error message.
版本1.2的YAML处理器必须接受带有显式“ %YAML 1.2 ”指令的文档，以及缺少“ YAML ”指令的文档。假定此类文件符合1.2版规范。
带有“ YAML ”指令的文档指定了更高的次要版本（例如“ %YAML 1.3 “）应使用适当的警告进行处理。 带有“ YAML
”指令的文档指定了更高的主要版本（例如“ %YAML 2.0 “）应被拒绝，并显示适当的错误消息。
A version 1.2 YAML [processor](https://yaml.org/spec/1.2.2/#processes-and-
models) must also accept documents
with an explicit “%YAML 1.1” directive. Note that version 1.2 is mostly a
superset of version 1.1, defined for the purpose of ensuring JSON
compatibility. Hence a version 1.2 [processor](https://yaml.org/spec/1.2.2
/#processes-and-models) should process version 1.1
documents as if they were version
1.2, giving a warning on points of incompatibility (handling of non-ASCII
line breaks , as
described above).
版本1.2的YAML处理器还必须接受带有显式“ %YAML 1.1
”指令的文档。请注意，版本1.2主要是版本1.1的超集，其定义是为了确保JSON兼容性。因此，版本1.2的处理器应该像版本1.2一样处理版本1.1的文档，给出不兼容点的警告（处理非ASCII换行符，如上所述）。
[86] ns-yaml-directive ::=
"YAML"
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
[ns-yaml-version](https://yaml.org/spec/1.2.2/#rule-ns-yaml-version)
[87] ns-yaml-version ::=
[ns-dec-digit](https://yaml.org/spec/1.2.2/#rule-ns-dec-digit)+
'.'
[ns-dec-digit](https://yaml.org/spec/1.2.2/#rule-ns-dec-digit)+
Example 6.14 “YAML” directive
例6.14“ YAML “指令
%YAML 1.3 # Attempt parsing
# with a warning
---
"foo"
|
"foo"
—|—
Legend:
[ns-yaml-directive](https://yaml.org/spec/1.2.2/#rule-ns-yaml-directive)[ns-yaml-version](https://yaml.org/spec/1.2.2/#rule-ns-yaml-version)
It is an error to specify more than one “YAML” directive for the same
document, even if both occurrences give the same version number.
为同一文档指定多个“ YAML ”指令是错误的，即使两个指令都给予了相同的版本号。
Example 6.15 Invalid Repeated YAML directive
示例6.15无效的重复YAML指令
%YAML 1.2
%YAML 1.1
foo
|
ERROR:
The YAML directive must only be
given at most once per document.
—|—
6.8.2. “TAG” Directives 6.8.2.“ TAG ”指令
The “TAG” directive establishes a tag
shorthand notation for
specifying node tags. Each “TAG”
directive associates a handle with
a prefix. This allows for compact
and readable tag notation.
“ TAG ”指令建立了用于指定节点标记的标记简写表示法。每个“ TAG ”指令将句柄与前缀相关联。这允许紧凑且可读的标记符号。
[88] ns-tag-directive ::=
"TAG"
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
[c-tag-handle](https://yaml.org/spec/1.2.2/#rule-c-tag-handle)
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)
[ns-tag-prefix](https://yaml.org/spec/1.2.2/#rule-ns-tag-prefix)
Example 6.16 “TAG” directive
例6.16“ TAG “指令
%TAG !yaml! tag:yaml.org,2002:
---
!yaml!str "foo"
|
"foo"
—|—
Legend:
[ns-tag-directive](https://yaml.org/spec/1.2.2/#rule-ns-tag-directive)[c-tag-handle](https://yaml.org/spec/1.2.2/#rule-c-tag-handle)[ns-tag-prefix](https://yaml.org/spec/1.2.2/#rule-ns-tag-prefix)
It is an error to specify more than one “TAG” directive for the same
handle in the same document, even
if both occurrences give the same [prefix](https://yaml.org/spec/1.2.2/#tag-
prefixes).
为同一文档中的同一句柄指定多个“ TAG ”指令是错误的，即使两个指令都给予了相同的前缀。
Example 6.17 Invalid Repeated TAG directive
例6.17无效的重复TAG指令
%TAG ! !foo
%TAG ! !foo
bar
|
ERROR:
The TAG directive must only
be given at most once per
handle in the same document.
—|—
6.8.2.1. Tag Handles 6.8.2.1.标记句柄
The tag handle exactly matches the prefix of the affected tag
shorthand. There are three tag
handle variants:
标记句柄与受影响的标记简写的前缀完全匹配。有三种标记句柄变体：
[89] c-tag-handle ::=
[c-named-tag-handle](https://yaml.org/spec/1.2.2/#rule-c-named-tag-handle)
| [c-secondary-tag-handle](https://yaml.org/spec/1.2.2/#rule-c-secondary-tag-handle)
| [c-primary-tag-handle](https://yaml.org/spec/1.2.2/#rule-c-primary-tag-handle)
Primary Handle
The primary tag handle is a single “! ” character. This allows using the
most compact possible notation for a single “primary” name space. By default,
the prefix associated with this handle is “!”. Thus, by default,
shorthands using this handle
are interpreted as local tags.
主标记句柄是单个“ ! ”字符。这允许对单个“主”名称空间使用尽可能紧凑的表示法。默认情况下，与此句柄关联的前缀是“ !
”。因此，默认情况下，使用此句柄的简写被解释为本地标记。
It is possible to override the default behavior by providing an explicit
“TAG” directive, associating a different prefix for this handle. This
provides smooth migration from using local
tags to using global
tags by the simple addition of a single
“TAG” directive.
可以通过提供显式的“ TAG ”指令来覆盖默认行为，为该句柄关联不同的前缀。这提供了从使用本地标记到使用全局标记的平滑迁移，只需添加一个“ TAG
”指令。
[90] c-primary-tag-handle ::= '!'
Example 6.18 Primary Tag Handle 示例6.18主标签手柄
# Private
!foo "bar"
...
# Global
%TAG ! tag:example.com,2000:app/
---
!foo "bar"
|
!<!foo> "bar"
---
!<tag:example.com,2000:app/foo> "bar"
—|—
Legend:
[c-primary-tag-handle](https://yaml.org/spec/1.2.2/#rule-c-primary-tag-handle)
Secondary Handle
The secondary tag handle is written as “!! ”. This allows using a compact
notation for a single “secondary” name space. By default, the prefix
associated with this handle is “tag:yaml.org,2002:”.
辅助标记句柄被写为“ !! ”。这允许对单个“辅助”名称空间使用紧凑表示法。默认情况下，与此句柄关联的前缀是“ tag:yaml.org,2002:
”。
It is possible to override this default behavior by providing an explicit
“TAG” directive associating a different prefix for this handle.
可以通过提供一个显式的“ TAG ”指令来覆盖此默认行为，该指令与此句柄的不同前缀相关联。
[91] c-secondary-tag-handle ::= "!!"
Example 6.19 Secondary Tag Handle
示例6.19辅助标签手柄
%TAG !! tag:example.com,2000:app/
---
!!int 1 - 3 # Interval, not integer
|
!<tag:example.com,2000:app/int> "1 - 3"
—|—
Legend:
[c-secondary-tag-handle](https://yaml.org/spec/1.2.2/#rule-c-secondary-tag-handle)
Named Handles
A named tag handle surrounds a non-empty name with “! ” characters. A
handle name must not be used in a [tag shorthand](https://yaml.org/spec/1.2.2
/#tag-shorthands) unless an explicit “TAG” directive has associated some
prefix with it.
命名标记句柄用“ ! ”字符将非空名称括起来。句柄名称不能用在标记简写中，除非显式的“ TAG ”指令已经将一些前缀与它关联。
The name of the handle is a [presentation detail](https://yaml.org/spec/1.2.2
/#presenting-the-serialization-tree) and must not be used to convey
content information. In particular, the
YAML processor need not
preserve the handle name once [parsing](https://yaml.org/spec/1.2.2/#parsing-
the-presentation-stream) is completed.
句柄的名称是一个表示细节，不得用于传递内容信息。特别地，一旦解析完成，YAML处理器不需要保留句柄名称。
[92] c-named-tag-handle ::=
[c-tag](https://yaml.org/spec/1.2.2/#rule-c-tag) # '!'
[ns-word-char](https://yaml.org/spec/1.2.2/#rule-ns-word-char)+
[c-tag](https://yaml.org/spec/1.2.2/#rule-c-tag) # '!'
Example 6.20 Tag Handles 示例6.20标记句柄
%TAG !e! tag:example.com,2000:app/
---
!e!foo "bar"
|
!<tag:example.com,2000:app/foo> "bar"
—|—
Legend:
[c-named-tag-handle](https://yaml.org/spec/1.2.2/#rule-c-named-tag-handle)
6.8.2.2. Tag Prefixes 6.8.2.2.标签前缀
There are two tag prefix variants:
有两种标记前缀变体：
[93] ns-tag-prefix ::=
[c-ns-local-tag-prefix](https://yaml.org/spec/1.2.2/#rule-c-ns-local-tag-prefix) | [ns-global-tag-prefix](https://yaml.org/spec/1.2.2/#rule-ns-global-tag-prefix)
Local Tag Prefix 本地标记前缀
If the prefix begins with a “!” character,
shorthands using the
handle are expanded to a local
tag. Note that such a
tag is intentionally not a valid URI and
its semantics are specific to the [application](https://yaml.org/spec/1.2.2
/#processes-and-models). In particular, two
documents in the same
stream may assign different semantics
to the same local tag.
如果前缀以“ !
”字符开头，则使用句柄的简写将扩展为本地标记。请注意，这样的标记故意不是有效的URI，其语义特定于应用程序。特别地，相同流中的两个文档可以将不同的语义分配给相同的本地标签。
[94] c-ns-local-tag-prefix ::=
[c-tag](https://yaml.org/spec/1.2.2/#rule-c-tag) # '!'
[ns-uri-char](https://yaml.org/spec/1.2.2/#rule-ns-uri-char)*
Example 6.21 Local Tag Prefix 示例6.21本地标记前缀
%TAG !m! !my-
--- # Bulb here
!m!light fluorescent
...
%TAG !m! !my-
--- # Color here
!m!light green
|
!<!my-light> "fluorescent"
---
!<!my-light> "green"
—|—
Legend:
[c-ns-local-tag-prefix](https://yaml.org/spec/1.2.2/#rule-c-ns-local-tag-prefix)
Global Tag Prefix 全局标记前缀
If the prefix begins with a character other than “!”, it must be a valid URI
prefix, and should contain at least the scheme.
Shorthands using the associated
handle are expanded to globally
unique URI tags and their semantics is consistent across
applications. In
particular, every document in every
stream must assign the same semantics
to the same global tag.
如果前缀以“ ! ”以外的字符开头，则它必须是有效的URI前缀，并且应至少包含方案。
使用关联句柄的简写扩展为全局唯一的URI标记，并且它们的语义在应用程序中是一致的。特别是，每个流中的每个文档必须为相同的全局标记分配相同的语义。
[95] ns-global-tag-prefix ::=
[ns-tag-char](https://yaml.org/spec/1.2.2/#rule-ns-tag-char)
[ns-uri-char](https://yaml.org/spec/1.2.2/#rule-ns-uri-char)*
Example 6.22 Global Tag Prefix 示例6.22全局标记前缀
%TAG !e! tag:example.com,2000:app/
---
- !e!foo "bar"
|
- !<tag:example.com,2000:app/foo> "bar"
—|—
Legend:
[ns-global-tag-prefix](https://yaml.org/spec/1.2.2/#rule-ns-global-tag-prefix)
6.9. Node Properties 6.9.节点属性
Each node may have two optional
properties , anchor and
tag, in addition to its
content. Node properties may be
specified in any order before the node’s
content. Either or both may be omitted.
每个节点除了其内容之外，还可以具有两个可选属性：锚和标记。节点属性可以在节点内容之前以任何顺序指定。可以省略任一个或两者。
[96] c-ns-properties(n,c) ::=
(
[c-ns-tag-property](https://yaml.org/spec/1.2.2/#rule-c-ns-tag-property)
(
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)
[c-ns-anchor-property](https://yaml.org/spec/1.2.2/#rule-c-ns-anchor-property)
)?
)
| (
[c-ns-anchor-property](https://yaml.org/spec/1.2.2/#rule-c-ns-anchor-property)
(
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)
[c-ns-tag-property](https://yaml.org/spec/1.2.2/#rule-c-ns-tag-property)
)?
)
Example 6.23 Node Properties 示例6.23节点属性
!!str &a1 "foo":
!!str bar
&a2 baz : *a1
|
{ &B1 "foo": "bar",
"baz": *B1 }
—|—
Legend:
[c-ns-properties(n,c)](https://yaml.org/spec/1.2.2/#rule-c-ns-properties)[c-ns-anchor-property](https://yaml.org/spec/1.2.2/#rule-c-ns-anchor-property)[c-ns-tag-property](https://yaml.org/spec/1.2.2/#rule-c-ns-tag-property)
6.9.1. Node Tags 6.9.1.节点标签
The tag property identifies the type of the native data
structure
presented by
the node. A tag is denoted by the “! ”
indicator.
tag属性标识本机数据结构的类型 由节点呈现。标签由“ ! ”指示符表示。
[97] c-ns-tag-property ::=
[c-verbatim-tag](https://yaml.org/spec/1.2.2/#rule-c-verbatim-tag)
| [c-ns-shorthand-tag](https://yaml.org/spec/1.2.2/#rule-c-ns-shorthand-tag)
| [c-non-specific-tag](https://yaml.org/spec/1.2.2/#rule-c-non-specific-tag)
Verbatim Tags
A tag may be written verbatim by surrounding it with the “< ” and “>”
characters. In this case, the YAML [processor](https://yaml.org/spec/1.2.2
/#processes-and-models) must deliver the verbatim tag as-is to the
application. In
particular, verbatim tags are not subject to tag
resolution. A verbatim tag must
either begin with a “!” (a local tag)
or be a valid URI (a global tag).
标签可以通过用“ < ”和“ >
”字符包围它来逐字写入。在这种情况下，YAML处理器必须将逐字标记按原样传递给应用程序。特别地，逐字标记不受标记解析的影响。逐字标记必须以“ !
”（本地标记）开始，或者是有效的URI（全局标记）。
[98] c-verbatim-tag ::=
"!<"
[ns-uri-char](https://yaml.org/spec/1.2.2/#rule-ns-uri-char)+
'>'
Example 6.24 Verbatim Tags 示例6.24逐字标记
!<tag:yaml.org,2002:str> foo :
!<!bar> baz
|
{ "foo": !<!bar> "baz" }
—|—
Legend:
[c-verbatim-tag](https://yaml.org/spec/1.2.2/#rule-c-verbatim-tag)
Example 6.25 Invalid Verbatim Tags
例6.25无效的逐字标记
- !<!> foo
- !<$:?> bar
|
ERROR:
- Verbatim tags aren't resolved,
so ! is invalid.
- The $:? tag is neither a global
URI tag nor a local tag starting
with '!'.
—|—
Tag Shorthands
A tag shorthand consists of a valid [tag handle](https://yaml.org/spec/1.2.2
/#tag-handles) followed by a non-empty suffix. The tag
handle must be associated with a
prefix , either by default or by
using a “TAG” directive. The resulting [parsed](https://yaml.org/spec/1.2.2
/#parsing-the-presentation-stream) tag is
the concatenation of the prefix
and the suffix and must either begin with “!” (a local
tag) or be a valid URI (a global
tag).
标记简写由一个有效的标记句柄和一个非空后缀组成。标记句柄必须与前缀相关联，默认情况下或使用“ TAG ”指令。分析的结果
tag是前缀和后缀的连接，必须以“ ! ”（本地标签）开始，或者是有效的URI（全局标签）。
The choice of tag handle is a
[presentation detail](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) and must not be used to convey
content information. In particular, the
tag handle may be discarded once
parsing is
completed.
标记句柄的选择是表示细节，不得用于传达内容信息。特别地，一旦解析完成，就可以丢弃标签句柄。
The suffix must not contain any “!” character. This would cause the tag
shorthand to be interpreted as having a named tag
handle. In addition, the suffix
must not contain the “[”, “]”, “{”, “}” and “,” characters. These
characters would cause ambiguity with flow
collection structures.
If the suffix needs to specify any of the above restricted characters, they
must be escaped using the
“%” character. This behavior is consistent with the URI character escaping
rules (specifically, section 2.3 of URI RFC).
后缀不能包含任何“ ! ”字符。这将导致标记简写被解释为具有命名标记句柄。此外，后缀不得包含“ [ ”、“ ] ”、“ { ”、“ }
”和“ , ”字符。这些字符将导致流集合结构的歧义。如果后缀需要指定上述任何限制字符，则必须使用“ %
”字符对其进行转义。此行为与URI字符转义规则（特别是URI RFC的第2.3节）一致。
[99] c-ns-shorthand-tag ::=
[c-tag-handle](https://yaml.org/spec/1.2.2/#rule-c-tag-handle)
[ns-tag-char](https://yaml.org/spec/1.2.2/#rule-ns-tag-char)+
Example 6.26 Tag Shorthands 示例6.26标记缩写
%TAG !e! tag:example.com,2000:app/
---
- !local foo
- !!str bar
- !e!tag%21 baz
|
[ !<!local> "foo",
!<tag:yaml.org,2002:str> "bar",
!<tag:example.com,2000:app/tag!> "baz" ]
—|—
Legend:
[c-ns-shorthand-tag](https://yaml.org/spec/1.2.2/#rule-c-ns-shorthand-tag)
Example 6.27 Invalid Tag Shorthands
例6.27无效的标记缩写
%TAG !e! tag:example,2000:app/
---
- !e! foo
- !h!bar baz
|
ERROR:
- The !e! handle has no suffix.
- The !h! handle wasn't declared.
—|—
Non-Specific Tags
If a node has no tag property, it is
assigned a non-specific tag that
needs to be resolved to a
specific one. This non-specific
tag is “!” for non-plain
scalars and “?” for all other
nodes. This is the only case where the
node style has any effect on the
content information.
如果节点没有标记属性，则会为其指定一个非特定标记，该标记需要解析为特定标记。该非特定标签对于非纯标量是“ ! ”，并且对于所有其他节点是“ ?
”。这是节点样式对内容信息有任何影响的唯一情况。
It is possible for the tag property to be explicitly set to the “!” non-
specific tag. By convention,
this “disables” tag resolution,
forcing the node to be interpreted as
“tag:yaml.org,2002:seq”, “tag:yaml.org,2002:map” or
“tag:yaml.org,2002:str”, according to its
kind.
标签属性可以显式设置为“ ! ”非特定标签。按照惯例，这“禁用”标记解析，强制节点根据其种类被解释为“ tag:yaml.org,2002:seq
”、“ tag:yaml.org,2002:map ”或“ tag:yaml.org,2002:str ”。
There is no way to explicitly specify the “?” non-specific tag. This is
intentional.
无法显式指定“ ? ”非特定标记。这是故意的。
[100] c-non-specific-tag ::= '!'
Example 6.28 Non-Specific Tags 例6.28非特定标签
# Assuming conventional resolution:
- "12"
- 12
- ! 12
|
[ "12",
12,
"12" ]
—|—
Legend:
[c-non-specific-tag](https://yaml.org/spec/1.2.2/#rule-c-non-specific-tag)
6.9.2. Node Anchors 6.9.2.节点锚点
An anchor is denoted by the “&” indicator. It marks a
node for future reference. An alias
node can then be used to indicate
additional inclusions of the anchored
node. An anchored
node need not be referenced by any
alias nodes; in particular, it is
valid for all nodes to be anchored.
锚由“ &
”指示符表示。它标记一个节点供将来参考。然后，可以使用别名节点来指示锚定节点的附加包含。锚定节点不需要被任何别名节点引用;具体地，锚定所有节点是有效的。
[101] c-ns-anchor-property ::=
[c-anchor](https://yaml.org/spec/1.2.2/#rule-c-anchor) # '&'
[ns-anchor-name](https://yaml.org/spec/1.2.2/#rule-ns-anchor-name)
Note that as a [serialization detail](https://yaml.org/spec/1.2.2
/#serializing-the-representation-graph), the anchor name is preserved in the
serialization tree.
However, it is not reflected in the
representation graph and
must not be used to convey content
information. In particular, the YAML [processor](https://yaml.org/spec/1.2.2
/#processes-and-models) need not preserve the anchor name once the
representation is
composed.
请注意，作为序列化详细信息，锚名称保留在序列化树中。然而，它不反映在表示图中，并且不得用于传达内容信息。特别地，一旦组成表示，YAML处理器就不需要保留锚名称。
Anchor names must not contain the “[”, “]”, “{”, “}” and “,”
characters. These characters would cause ambiguity with flow
collection structures.
锚名称不得包含“ [ ”、“ ] ”、“ { ”、“ } ”和“ , ”字符。这些字符将导致流集合结构的歧义。
[102] ns-anchor-char ::=
[ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char) - [c-flow-indicator](https://yaml.org/spec/1.2.2/#rule-c-flow-indicator)
[103] ns-anchor-name ::=
[ns-anchor-char](https://yaml.org/spec/1.2.2/#rule-ns-anchor-char)+
Example 6.29 Node Anchors 示例6.29节点锚点
First occurrence: &anchor Value
Second occurrence: *anchor
|
{ "First occurrence": &A "Value",
"Second occurrence": *A }
—|—
Legend:
[c-ns-anchor-property](https://yaml.org/spec/1.2.2/#rule-c-ns-anchor-property)[ns-anchor-name](https://yaml.org/spec/1.2.2/#rule-ns-anchor-name)
Chapter 7. Flow Style Productions
第7章Flow Style Productions
YAML’s flow styles can be thought of as the natural extension of JSON to
cover folding long content lines
for readability, tagging nodes to control
[construction](https://yaml.org/spec/1.2.2/#constructing-native-data-
structures) of [native data structures](https://yaml.org/spec/1.2.2
/#representing-native-data-structures) and using
anchors and
aliases to reuse
[constructed](https://yaml.org/spec/1.2.2/#constructing-native-data-
structures) object instances.
YAML的流样式可以被认为是JSON的自然扩展，以涵盖折叠长内容行以提高可读性，标记节点以控制本机数据结构的构造，以及使用锚点和别名来重用构造的对象实例。
7.1. Alias Nodes 7.1.别名节点
Subsequent occurrences of a previously
[serialized](https://yaml.org/spec/1.2.2/#serializing-the-representation-
graph) node are [presented](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) as alias nodes. The first occurrence of the
node must be marked by an
anchor to allow subsequent
occurrences to be [presented](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) as alias nodes.
先前序列化的节点的后续出现被呈现为别名节点。节点的第一次出现必须由锚标记，以允许后续出现作为别名节点呈现。
An alias node is denoted by the “*” indicator. The alias refers to the most
recent preceding node having the same
anchor. It is an error for
an alias node to use an [anchor](https://yaml.org/spec/1.2.2/#anchors-and-
aliases) that does not previously occur in the
document. It is not an error to
specify an anchor that is
not used by any alias node.
别名节点由“ * ”指示符表示。别名是指具有相同锚的最近的在前节点。别名节点使用以前未在文档中出现的锚是错误的。指定未被任何别名节点使用的锚点不是错误。
Note that an alias node must not specify any
properties or
content, as these were already specified
at the first occurrence of the node.
请注意，别名节点不能指定任何属性或内容，因为这些属性或内容已在节点第一次出现时指定。
[104] c-ns-alias-node ::=
[c-alias](https://yaml.org/spec/1.2.2/#rule-c-alias) # '*'
[ns-anchor-name](https://yaml.org/spec/1.2.2/#rule-ns-anchor-name)
Example 7.1 Alias Nodes 示例7.1别名节点
First occurrence: &anchor Foo
Second occurrence: *anchor
Override anchor: &anchor Bar
Reuse anchor: *anchor
|
{ "First occurrence": &A "Foo",
"Override anchor": &B "Bar",
"Second occurrence": *A,
"Reuse anchor": *B }
—|—
Legend:
[c-ns-alias-node](https://yaml.org/spec/1.2.2/#rule-c-ns-alias-node)[ns-anchor-name](https://yaml.org/spec/1.2.2/#rule-ns-anchor-name)
7.2. Empty Nodes 7.2.空节点
YAML allows the node content to be
omitted in many cases. Nodes with empty
content are interpreted as if they were
plain scalars with an empty value.
Such nodes are commonly resolved to a
“null” value.
YAML允许在许多情况下省略节点内容。 具有空内容的节点被解释为具有空值的普通标量。这样的节点通常被解析为“ null ”值。
[105] e-scalar ::= ""
In the examples, empty scalars are
sometimes displayed as the glyph “°” for clarity. Note that this glyph
corresponds to a position in the characters
stream rather than to an actual
character.
在示例中，为了清楚起见，空标量有时被显示为字形“ ° ”。请注意，此标志符号对应于字符流中的位置，而不是实际字符。
Example 7.2 Empty Content 示例7.2空内容
{
foo : !!str°,
!!str° : bar,
}
|
{ "foo": "",
"": "bar" }
—|—
Legend:
[e-scalar](https://yaml.org/spec/1.2.2/#rule-e-scalar)
Both the node’s properties and
node content are optional. This allows
for a completely empty node. Completely empty nodes are only valid when
following some explicit indication for their existence.
节点的属性和节点内容都是可选的。这允许一个完全空的节点。完全空的节点只有在遵循一些显式指示它们的存在时才有效。
[106] e-node ::=
[e-scalar](https://yaml.org/spec/1.2.2/#rule-e-scalar) # ""
Example 7.3 Completely Empty Flow Nodes
示例7.3完全空的流节点
{
? foo :°,
°: bar,
}
|
{ "foo": null,
null : "bar" }
—|—
Legend:
[e-node](https://yaml.org/spec/1.2.2/#rule-e-node)
7.3. Flow Scalar Styles 7.3.流标量样式
YAML provides three flow scalar styles : double-
quoted, single-
quoted and
plain (unquoted). Each provides a
different trade-off between readability and expressive power.
YAML提供三种流标量样式：双引号、单引号和普通（无引号）。每一种都在可读性和表达能力之间提供了不同的权衡。
The scalar style is a
[presentation detail](https://yaml.org/spec/1.2.2/#presenting-the-
serialization-tree) and must not be used to convey
content information, with the exception
that plain scalars are
distinguished for the purpose of [tag resolution](https://yaml.org/spec/1.2.2
/#tag-resolution).
标量样式是一种表示细节，不得用于传达内容信息，除非纯标量是为了标记解析而区分的。
7.3.1. Double-Quoted Style 7.3.1.双引号样式
The double-quoted style is specified by surrounding “" ” indicators. This
is the only style capable of
expressing arbitrary strings, by using “\” escape
sequences. This comes at the
cost of having to escape the “\” and “"” characters.
双引号样式由周围的“ " ”指示符指定。这是唯一能够通过使用“ \ ”转义序列来表示任意字符串的样式。这是以必须转义“ \ ”和“ "
”字符为代价的。
[107] nb-double-char ::=
[c-ns-esc-char](https://yaml.org/spec/1.2.2/#rule-c-ns-esc-char)
| (
[nb-json](https://yaml.org/spec/1.2.2/#rule-nb-json)
- [c-escape](https://yaml.org/spec/1.2.2/#rule-c-escape) # '\'
- [c-double-quote](https://yaml.org/spec/1.2.2/#rule-c-double-quote) # '"'
)
[108] ns-double-char ::=
[nb-double-char](https://yaml.org/spec/1.2.2/#rule-nb-double-char) - [s-white](https://yaml.org/spec/1.2.2/#rule-s-white)
Double-quoted scalars are restricted to a single line when contained inside an
[implicit key](https://yaml.org/spec/1.2.2/#example-single-pair-explicit-
entry).
当包含在隐式键中时，双引号标量被限制为一行。
[109] c-double-quoted(n,c) ::=
[c-double-quote](https://yaml.org/spec/1.2.2/#rule-c-double-quote) # '"'
[nb-double-text](https://yaml.org/spec/1.2.2/#rule-nb-double-text)(n,c)
[c-double-quote](https://yaml.org/spec/1.2.2/#rule-c-double-quote) # '"'
[110]
nb-double-text(n,FLOW-OUT) ::= [nb-double-multi-line](https://yaml.org/spec/1.2.2/#rule-nb-double-multi-line)(n)
nb-double-text(n,FLOW-IN) ::= [nb-double-multi-line](https://yaml.org/spec/1.2.2/#rule-nb-double-multi-line)(n)
nb-double-text(n,BLOCK-KEY) ::= [nb-double-one-line](https://yaml.org/spec/1.2.2/#rule-nb-double-one-line)
nb-double-text(n,FLOW-KEY) ::= [nb-double-one-line](https://yaml.org/spec/1.2.2/#rule-nb-double-one-line)
[111] nb-double-one-line ::=
[nb-double-char](https://yaml.org/spec/1.2.2/#rule-nb-double-char)*
Example 7.4 Double Quoted Implicit Keys
例7.4双引号隐式键
"implicit block key" : [
"implicit flow key" : value,
]
|
{ "implicit block key":
[ { "implicit flow key": "value" } ] }
—|—
Legend:
[nb-double-one-line](https://yaml.org/spec/1.2.2/#rule-nb-double-one-line)[c-double-quoted(n,c)](https://yaml.org/spec/1.2.2/#rule-c-double-quoted)
In a multi-line double-quoted scalar, line
breaks are subject to
flow line folding, which discards
any trailing [white space](https://yaml.org/spec/1.2.2/#white-space-
characters) characters. It is also possible to escape the line
break character. In this
case, the escaped [line break](https://yaml.org/spec/1.2.2/#line-break-
characters) is excluded from the content
and any trailing [white space](https://yaml.org/spec/1.2.2/#white-space-
characters) characters that precede the escaped line break are preserved.
Combined with the ability to [escape](https://yaml.org/spec/1.2.2/#escaped-
characters) white space
characters, this allows double-quoted lines to be broken at arbitrary
positions.
在多行双引号标量中，换行符受流线折叠的影响，这将丢弃任何尾随白色字符。也可以转义换行符。在这种情况下，将从内容中排除转义的换行符，并保留转义的换行符之前的任何尾随白色字符。再加上逃跑的能力
白色字符，这允许双引号行在任意位置断开。
[112] s-double-escaped(n) ::=
[s-white](https://yaml.org/spec/1.2.2/#rule-s-white)*
[c-escape](https://yaml.org/spec/1.2.2/#rule-c-escape) # '\'
[b-non-content](https://yaml.org/spec/1.2.2/#rule-b-non-content)
[l-empty](https://yaml.org/spec/1.2.2/#rule-l-empty)(n,FLOW-IN)*
[s-flow-line-prefix](https://yaml.org/spec/1.2.2/#rule-s-flow-line-prefix)(n)
[113] s-double-break(n) ::=
[s-double-escaped](https://yaml.org/spec/1.2.2/#rule-s-double-escaped)(n)
| [s-flow-folded](https://yaml.org/spec/1.2.2/#rule-s-flow-folded)(n)
Example 7.5 Double Quoted Line Breaks
示例7.5双引号换行符
"folded·↓
to a space,→↓
·↓
to a line feed, or·→\↓
·\·→non-content"
|
"folded to a space,\nto a line feed, or \t \tnon-content"
—|—
Legend:
[s-flow-folded(n)](https://yaml.org/spec/1.2.2/#rule-s-flow-folded)[s-double-escaped(n)](https://yaml.org/spec/1.2.2/#rule-s-double-escaped)
All leading and trailing [white space](https://yaml.org/spec/1.2.2/#white-
space-characters) characters on each line are excluded from the
content. Each continuation line must
therefore contain at least one non-[space](https://yaml.org/spec/1.2.2/#white-
space-characters) character. Empty lines, if any, are consumed as part of the
line folding.
每行上的所有前导和尾随白色字符都将从内容中排除。因此，每个延续行必须至少包含一个非空格字符。空行（如果有）将作为线折叠的一部分被使用。
[114] nb-ns-double-in-line ::=
(
[s-white](https://yaml.org/spec/1.2.2/#rule-s-white)*
[ns-double-char](https://yaml.org/spec/1.2.2/#rule-ns-double-char)
)*
[115] s-double-next-line(n) ::=
[s-double-break](https://yaml.org/spec/1.2.2/#rule-s-double-break)(n)
(
[ns-double-char](https://yaml.org/spec/1.2.2/#rule-ns-double-char) [nb-ns-double-in-line](https://yaml.org/spec/1.2.2/#rule-nb-ns-double-in-line)
(
[s-double-next-line](https://yaml.org/spec/1.2.2/#rule-s-double-next-line)(n)
| [s-white](https://yaml.org/spec/1.2.2/#rule-s-white)*
)
)?
[116] nb-double-multi-line(n) ::=
[nb-ns-double-in-line](https://yaml.org/spec/1.2.2/#rule-nb-ns-double-in-line)
(
[s-double-next-line](https://yaml.org/spec/1.2.2/#rule-s-double-next-line)(n)
| [s-white](https://yaml.org/spec/1.2.2/#rule-s-white)*
)
Example 7.6 Double Quoted Lines 例7.6双引号行
"·1st non-empty↓
↓
·2nd non-empty·
→3rd non-empty·"
|
" 1st non-empty\n2nd non-empty 3rd non-empty "
—|—
Legend:
[nb-ns-double-in-line](https://yaml.org/spec/1.2.2/#rule-nb-ns-double-in-line)[s-double-next-line(n)](https://yaml.org/spec/1.2.2/#rule-s-double-next-line)
7.3.2. Single-Quoted Style 7.3.2.单引号样式
The single-quoted style is specified by surrounding “' ” indicators.
Therefore, within a single-quoted scalar, such characters need to be repeated.
This is the only form of escaping performed in single-quoted scalars. In
particular, the “\ ” and “"” characters may be freely used. This restricts
single-quoted scalars to [printable](https://yaml.org/spec/1.2.2/#character-
set) characters. In addition, it is only possible to break a long single-
quoted line where a [space](https://yaml.org/spec/1.2.2/#white-space-
characters) character is surrounded by
non-spaces.
单引号样式由周围的“ ' ”指示符指定。因此，在单引号标量中，这些字符需要重复。这是在单引号标量中执行的唯一转义形式。特别地，可以自由地使用“ \
”和“ " ”字符。这将单引号标量限制为可打印字符。此外，只有在空格字符被非空格字符包围的情况下，才可能断开长的单引号行。
[117] c-quoted-quote ::= "''"
[118] nb-single-char ::=
[c-quoted-quote](https://yaml.org/spec/1.2.2/#rule-c-quoted-quote)
| (
[nb-json](https://yaml.org/spec/1.2.2/#rule-nb-json)
- [c-single-quote](https://yaml.org/spec/1.2.2/#rule-c-single-quote) # "'"
)
[119] ns-single-char ::=
[nb-single-char](https://yaml.org/spec/1.2.2/#rule-nb-single-char) - [s-white](https://yaml.org/spec/1.2.2/#rule-s-white)
Example 7.7 Single Quoted Characters
例7.7单引号字符
'here''s to "quotes"'
|
"here's to \"quotes\""
—|—
Legend:
[c-quoted-quote](https://yaml.org/spec/1.2.2/#rule-c-quoted-quote)
Single-quoted scalars are restricted to a single line when contained inside a
[implicit key](https://yaml.org/spec/1.2.2/#example-single-pair-explicit-
entry).
当包含在隐式键中时，单引号标量被限制为一行。
[120] c-single-quoted(n,c) ::=
[c-single-quote](https://yaml.org/spec/1.2.2/#rule-c-single-quote) # "'"
[nb-single-text](https://yaml.org/spec/1.2.2/#rule-nb-single-text)(n,c)
[c-single-quote](https://yaml.org/spec/1.2.2/#rule-c-single-quote) # "'"
[121]
nb-single-text(FLOW-OUT) ::= [nb-single-multi-line](https://yaml.org/spec/1.2.2/#rule-nb-single-multi-line)(n)
nb-single-text(FLOW-IN) ::= [nb-single-multi-line](https://yaml.org/spec/1.2.2/#rule-nb-single-multi-line)(n)
nb-single-text(BLOCK-KEY) ::= [nb-single-one-line](https://yaml.org/spec/1.2.2/#rule-nb-single-one-line)
nb-single-text(FLOW-KEY) ::= [nb-single-one-line](https://yaml.org/spec/1.2.2/#rule-nb-single-one-line)
[122] nb-single-one-line ::=
[nb-single-char](https://yaml.org/spec/1.2.2/#rule-nb-single-char)*
Example 7.8 Single Quoted Implicit Keys
例7 - 8单引号隐式键
'implicit block key' : [
'implicit flow key' : value,
]
|
{ "implicit block key":
[ { "implicit flow key": "value" } ] }
—|—
Legend:
[nb-single-one-line](https://yaml.org/spec/1.2.2/#rule-nb-single-one-line)[c-single-quoted(n,c)](https://yaml.org/spec/1.2.2/#rule-c-single-quoted)
All leading and trailing [white space](https://yaml.org/spec/1.2.2/#white-
space-characters) characters are excluded from the
content. Each continuation line must
therefore contain at least one non-[space](https://yaml.org/spec/1.2.2/#white-
space-characters) character. Empty lines, if any, are consumed as part of the
line folding.
内容中不包括所有前导和尾随白色字符。因此，每个延续行必须至少包含一个非空格字符。空行（如果有）将作为线折叠的一部分被使用。
[123] nb-ns-single-in-line ::=
(
[s-white](https://yaml.org/spec/1.2.2/#rule-s-white)*
[ns-single-char](https://yaml.org/spec/1.2.2/#rule-ns-single-char)
)*
[124] s-single-next-line(n) ::=
[s-flow-folded](https://yaml.org/spec/1.2.2/#rule-s-flow-folded)(n)
(
[ns-single-char](https://yaml.org/spec/1.2.2/#rule-ns-single-char)
[nb-ns-single-in-line](https://yaml.org/spec/1.2.2/#rule-nb-ns-single-in-line)
(
[s-single-next-line](https://yaml.org/spec/1.2.2/#rule-s-single-next-line)(n)
| [s-white](https://yaml.org/spec/1.2.2/#rule-s-white)*
)
)?
[125] nb-single-multi-line(n) ::=
[nb-ns-single-in-line](https://yaml.org/spec/1.2.2/#rule-nb-ns-single-in-line)
(
[s-single-next-line](https://yaml.org/spec/1.2.2/#rule-s-single-next-line)(n)
| [s-white](https://yaml.org/spec/1.2.2/#rule-s-white)*
)
Example 7.9 Single Quoted Lines 示例7.9单引号行
'·1st non-empty↓
↓
·2nd non-empty·
→3rd non-empty·'
|
" 1st non-empty\n2nd non-empty 3rd non-empty "
—|—
Legend:
[nb-ns-single-in-line(n)](https://yaml.org/spec/1.2.2/#rule-nb-ns-single-in-line)[s-single-next-line(n)](https://yaml.org/spec/1.2.2/#rule-s-single-next-line)
7.3.3. Plain Style 7.3.3.朴素风格
The plain (unquoted) style has no identifying
indicators and provides
no form of escaping. It is therefore the most readable, most limited and most
context sensitive
style. In addition to a restricted
character set, a plain scalar must not be empty or contain leading or trailing
white space characters.
It is only possible to break a long plain line where a
space character is
surrounded by non-[spaces](https://yaml.org/spec/1.2.2/#white-space-
characters).
普通（未加引号）样式没有识别指示符，也不提供转义形式。因此，它是最易读、最有限和最上下文敏感的风格。除了受限制的字符集外，纯标量不能为空，也不能包含前导或尾随白色字符。只有在空格字符被非空格包围的情况下，才可能断开长的纯行。
Plain scalars must not begin with most
indicators, as this would
cause ambiguity with other YAML constructs. However, the “:”, “?” and
“-” indicators may be
used as the first character if followed by a
non-space “safe”
character, as this causes no ambiguity.
普通标量不能以大多数指示符开始，因为这会导致与其他YAML结构的歧义。然而，“ : ”、“ ? ”和“ -
”指示符可以用作第一字符，如果后面跟着非空格“安全”字符，因为这不会引起歧义。
[126] ns-plain-first(c) ::=
(
[ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char)
- [c-indicator](https://yaml.org/spec/1.2.2/#rule-c-indicator)
)
| (
(
[c-mapping-key](https://yaml.org/spec/1.2.2/#rule-c-mapping-key) # '?'
| [c-mapping-value](https://yaml.org/spec/1.2.2/#rule-c-mapping-value) # ':'
| [c-sequence-entry](https://yaml.org/spec/1.2.2/#rule-c-sequence-entry) # '-'
)
[ lookahead = [ns-plain-safe](https://yaml.org/spec/1.2.2/#rule-ns-plain-safe)(c) ]
)
Plain scalars must never contain the “: ” and “ #” character combinations.
Such combinations would cause ambiguity with
mapping key/value
pairs and
comments. In addition, inside flow
collections, or when
used as [implicit keys](https://yaml.org/spec/1.2.2/#example-single-pair-
explicit-entry), plain scalars must not contain the “[”, “]”, “{”, “}”
and “,” characters. These characters would cause ambiguity with flow
collection structures.
纯标量不能包含“ : ”和“ # ”字符组合。这样的组合会导致映射的模糊性 键值对和注释。此外，在流集合内部或用作隐式键时，纯标量不能包含“
[ ”、“ ] ”、“ { ”、“ } ”和“ , ”字符。这些字符将导致流集合结构的歧义。
[127]
ns-plain-safe(FLOW-OUT) ::= [ns-plain-safe-out](https://yaml.org/spec/1.2.2/#rule-ns-plain-safe-out)
ns-plain-safe(FLOW-IN) ::= [ns-plain-safe-in](https://yaml.org/spec/1.2.2/#rule-ns-plain-safe-in)
ns-plain-safe(BLOCK-KEY) ::= [ns-plain-safe-out](https://yaml.org/spec/1.2.2/#rule-ns-plain-safe-out)
ns-plain-safe(FLOW-KEY) ::= [ns-plain-safe-in](https://yaml.org/spec/1.2.2/#rule-ns-plain-safe-in)
[128] ns-plain-safe-out ::=
[ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char)
[129] ns-plain-safe-in ::=
[ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char) - [c-flow-indicator](https://yaml.org/spec/1.2.2/#rule-c-flow-indicator)
[130] ns-plain-char(c) ::=
(
[ns-plain-safe](https://yaml.org/spec/1.2.2/#rule-ns-plain-safe)(c)
- [c-mapping-value](https://yaml.org/spec/1.2.2/#rule-c-mapping-value) # ':'
- [c-comment](https://yaml.org/spec/1.2.2/#rule-c-comment) # '#'
)
| (
[ lookbehind = [ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char) ]
[c-comment](https://yaml.org/spec/1.2.2/#rule-c-comment) # '#'
)
| (
[c-mapping-value](https://yaml.org/spec/1.2.2/#rule-c-mapping-value) # ':'
[ lookahead = [ns-plain-safe](https://yaml.org/spec/1.2.2/#rule-ns-plain-safe)(c) ]
)
Example 7.10 Plain Characters 例7.10普通字符
# Outside flow collection:
- ::vector
- ": - ()"
- Up, up, and away!
- -123
- https://example.com/foo#bar
# Inside flow collection:
- [ ::vector,
": - ()",
"Up, up and away!",
-123,
https://example.com/foo#bar ]
|
[ "::vector",
": - ()",
"Up, up, and away!",
-123,
"http://example.com/foo#bar",
[ "::vector",
": - ()",
"Up, up, and away!",
-123,
"http://example.com/foo#bar" ] ]
—|—
Legend:
[ns-plain-first(c)](https://yaml.org/spec/1.2.2/#rule-ns-plain-first)[ns-plain-char(c)](https://yaml.org/spec/1.2.2/#rule-ns-plain-char)Not ns-plain-first(c)Not ns-plain-char(c)
Plain scalars are further restricted to a single line when contained inside an
[implicit key](https://yaml.org/spec/1.2.2/#example-single-pair-explicit-
entry).
当包含在隐式键中时，普通标量被进一步限制为单行。
[131]
ns-plain(n,FLOW-OUT) ::= [ns-plain-multi-line](https://yaml.org/spec/1.2.2/#rule-ns-plain-multi-line)(n,FLOW-OUT)
ns-plain(n,FLOW-IN) ::= [ns-plain-multi-line](https://yaml.org/spec/1.2.2/#rule-ns-plain-multi-line)(n,FLOW-IN)
ns-plain(n,BLOCK-KEY) ::= [ns-plain-one-line](https://yaml.org/spec/1.2.2/#rule-ns-plain-one-line)(BLOCK-KEY)
ns-plain(n,FLOW-KEY) ::= [ns-plain-one-line](https://yaml.org/spec/1.2.2/#rule-ns-plain-one-line)(FLOW-KEY)
[132] nb-ns-plain-in-line(c) ::=
(
[s-white](https://yaml.org/spec/1.2.2/#rule-s-white)*
[ns-plain-char](https://yaml.org/spec/1.2.2/#rule-ns-plain-char)(c)
)*
[133] ns-plain-one-line(c) ::=
[ns-plain-first](https://yaml.org/spec/1.2.2/#rule-ns-plain-first)(c)
[nb-ns-plain-in-line](https://yaml.org/spec/1.2.2/#rule-nb-ns-plain-in-line)(c)
Example 7.11 Plain Implicit Keys 示例7.11纯隐式键
implicit block key : [
implicit flow key : value,
]
|
{ "implicit block key":
[ { "implicit flow key": "value" } ] }
—|—
Legend:
[ns-plain-one-line(c)](https://yaml.org/spec/1.2.2/#rule-ns-plain-one-line)
All leading and trailing [white space](https://yaml.org/spec/1.2.2/#white-
space-characters) characters are excluded from the
content. Each continuation line must
therefore contain at least one non-[space](https://yaml.org/spec/1.2.2/#white-
space-characters) character. Empty lines, if any, are consumed as part of the
line folding.
内容中不包括所有前导和尾随白色字符。因此，每个延续行必须至少包含一个非空格字符。空行（如果有）将作为线折叠的一部分被使用。
[134] s-ns-plain-next-line(n,c) ::=
[s-flow-folded](https://yaml.org/spec/1.2.2/#rule-s-flow-folded)(n)
[ns-plain-char](https://yaml.org/spec/1.2.2/#rule-ns-plain-char)(c)
[nb-ns-plain-in-line](https://yaml.org/spec/1.2.2/#rule-nb-ns-plain-in-line)(c)
[135] ns-plain-multi-line(n,c) ::=
[ns-plain-one-line](https://yaml.org/spec/1.2.2/#rule-ns-plain-one-line)(c)
[s-ns-plain-next-line](https://yaml.org/spec/1.2.2/#rule-s-ns-plain-next-line)(n,c)*
Example 7.12 Plain Lines 例7.12普通线
1st non-empty↓
↓
·2nd non-empty·
→3rd non-empty
|
"1st non-empty\n2nd non-empty 3rd non-empty"
—|—
Legend:
[nb-ns-plain-in-line(c)](https://yaml.org/spec/1.2.2/#rule-nb-ns-plain-in-line)[s-ns-plain-next-line(n,c)](https://yaml.org/spec/1.2.2/#rule-s-ns-plain-next-line)
7.4. Flow Collection Styles 7.4.流集合样式
A flow collection may be nested within a block
collection ([FLOW-OUT
context]), nested within another flow collection ([FLOW-IN context]) or be a
part of an [implicit key](https://yaml.org/spec/1.2.2/#example-single-pair-
explicit-entry) ([FLOW-KEY context] or [BLOCK-KEY context]). Flow
collection entries are terminated by the “, ” indicator. The final “,” may
be omitted. This does not cause ambiguity because flow collection entries can
never be [completely empty](https://yaml.org/spec/1.2.2/#example-empty-
content).
流集合可以嵌套在块集合（[ FLOW-OUT context]）内，嵌套在另一个流集合（[ FLOW-IN context]）内，或者是隐式键（[
FLOW-KEY context]或[ BLOCK-KEY context]）的一部分。流收集条目由“ , ”指示符终止。最后的“ ,
”可以省略。这不会引起歧义，因为流集合条目永远不会完全为空。
[136]
in-flow(n,FLOW-OUT) ::= [ns-s-flow-seq-entries](https://yaml.org/spec/1.2.2/#rule-ns-s-flow-seq-entries)(n,FLOW-IN)
in-flow(n,FLOW-IN) ::= [ns-s-flow-seq-entries](https://yaml.org/spec/1.2.2/#rule-ns-s-flow-seq-entries)(n,FLOW-IN)
in-flow(n,BLOCK-KEY) ::= [ns-s-flow-seq-entries](https://yaml.org/spec/1.2.2/#rule-ns-s-flow-seq-entries)(n,FLOW-KEY)
in-flow(n,FLOW-KEY) ::= [ns-s-flow-seq-entries](https://yaml.org/spec/1.2.2/#rule-ns-s-flow-seq-entries)(n,FLOW-KEY)
7.4.1. Flow Sequences 7.4.1.流程序列
Flow sequence content is denoted by surrounding “[ ” and “]” characters.
流程序列内容由周围的“ [ ”和“ ] ”字符表示。
[137] c-flow-sequence(n,c) ::=
[c-sequence-start](https://yaml.org/spec/1.2.2/#rule-c-sequence-start) # '['
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)?
[in-flow](https://yaml.org/spec/1.2.2/#rule-in-flow)(n,c)?
[c-sequence-end](https://yaml.org/spec/1.2.2/#rule-c-sequence-end) # ']'
Sequence entries are separated by a “,” character.
序列条目由“ , ”字符分隔。
[138] ns-s-flow-seq-entries(n,c) ::=
[ns-flow-seq-entry](https://yaml.org/spec/1.2.2/#rule-ns-flow-seq-entry)(n,c)
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)?
(
[c-collect-entry](https://yaml.org/spec/1.2.2/#rule-c-collect-entry) # ','
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)?
[ns-s-flow-seq-entries](https://yaml.org/spec/1.2.2/#rule-ns-s-flow-seq-entries)(n,c)?
)?
Example 7.13 Flow Sequence 示例7.13流程顺序
- [ one, two, ]
- [three ,four]
|
[ [ "one",
"two" ],
[ "three",
"four" ] ]
—|—
Legend:
[c-sequence-start](https://yaml.org/spec/1.2.2/#rule-c-sequence-start) [c-sequence-end](https://yaml.org/spec/1.2.2/#rule-c-sequence-end)[ns-flow-seq-entry(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-seq-entry)
Any flow node may be used as a flow
sequence entry. In addition, YAML provides a compact
notation
for the case where a flow sequence entry is a
mapping with a single key/value
pair.
任何流节点都可以用作流序列条目。此外，YAML为流序列条目是具有单个键/值对的映射的情况提供了紧凑表示法。
[139] ns-flow-seq-entry(n,c) ::=
[ns-flow-pair](https://yaml.org/spec/1.2.2/#rule-ns-flow-pair)(n,c) | [ns-flow-node](https://yaml.org/spec/1.2.2/#rule-ns-flow-node)(n,c)
Example 7.14 Flow Sequence Entries
示例7.14流程序列条目
[
"double
quoted", 'single
quoted',
plain
text, [ nested ],
single: pair,
]
|
[ "double quoted",
"single quoted",
"plain text",
[ "nested" ],
{ "single": "pair" } ]
—|—
Legend:
[ns-flow-node(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-node)[ns-flow-pair(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-pair)
7.4.2. Flow Mappings 7.4.2.流程图
Flow mappings are denoted by surrounding “{ ” and “}” characters.
流映射由周围的“ { ”和“ } ”字符表示。
[140] c-flow-mapping(n,c) ::=
[c-mapping-start](https://yaml.org/spec/1.2.2/#rule-c-mapping-start) # '{'
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)?
[ns-s-flow-map-entries](https://yaml.org/spec/1.2.2/#rule-ns-s-flow-map-entries)(n,in-flow(c))?
[c-mapping-end](https://yaml.org/spec/1.2.2/#rule-c-mapping-end) # '}'
Mapping entries are separated by a “,” character.
映射条目由“ , ”字符分隔。
[141] ns-s-flow-map-entries(n,c) ::=
[ns-flow-map-entry](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-entry)(n,c)
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)?
(
[c-collect-entry](https://yaml.org/spec/1.2.2/#rule-c-collect-entry) # ','
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)?
[ns-s-flow-map-entries](https://yaml.org/spec/1.2.2/#rule-ns-s-flow-map-entries)(n,c)?
)?
Example 7.15 Flow Mappings 示例7.15流程图
- { one : two , three: four , }
- {five: six,seven : eight}
|
[ { "one": "two",
"three": "four" },
{ "five": "six",
"seven": "eight" } ]
—|—
Legend:
[c-mapping-start](https://yaml.org/spec/1.2.2/#rule-c-mapping-start) [c-mapping-end](https://yaml.org/spec/1.2.2/#rule-c-mapping-end)[ns-flow-map-entry(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-entry)
If the optional “?” mapping key indicator is specified, the rest of the
entry may be [completely empty](https://yaml.org/spec/1.2.2/#example-empty-
content).
如果指定了可选的“ ? ”映射键指示符，则条目的其余部分可以完全为空。
[142] ns-flow-map-entry(n,c) ::=
(
[c-mapping-key](https://yaml.org/spec/1.2.2/#rule-c-mapping-key) # '?' (not followed by non-ws char)
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)
[ns-flow-map-explicit-entry](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-explicit-entry)(n,c)
)
| [ns-flow-map-implicit-entry](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-implicit-entry)(n,c)
[143] ns-flow-map-explicit-entry(n,c) ::=
[ns-flow-map-implicit-entry](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-implicit-entry)(n,c)
| (
[e-node](https://yaml.org/spec/1.2.2/#rule-e-node) # ""
[e-node](https://yaml.org/spec/1.2.2/#rule-e-node) # ""
)
Example 7.16 Flow Mapping Entries
示例7.16流映射条目
{
? explicit: entry,
implicit: entry,
?°°
}
|
{ "explicit": "entry",
"implicit": "entry",
null: null }
—|—
Legend:
[ns-flow-map-explicit-entry(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-explicit-entry)[ns-flow-map-implicit-entry(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-implicit-entry)[e-node](https://yaml.org/spec/1.2.2/#rule-e-node)
Normally, YAML insists the “:” mapping value indicator be
separated from the
value by white
space. A benefit of this
restriction is that the “:” character can be used inside plain
scalars, as long as it is not
followed by [white space](https://yaml.org/spec/1.2.2/#white-space-
characters). This allows for unquoted URLs and timestamps. It is also a
potential source for confusion as “a:1” is a plain
scalar and not a key/value
pair.
通常情况下，YAML坚持“ : ”映射值指示符与值白色分隔。这个限制的一个好处是，“ :
”字符可以在纯标量中使用，只要它后面没有白色。这允许不加引号的URL和时间戳。这也是一个潜在的混淆来源，因为“ a:1
”是一个普通的标量，而不是一个键/值对。
Note that the value may be completely
empty since its existence
is indicated by the “:”.
注意，该值可以完全为空，因为其存在由“ : ”指示。
[144] ns-flow-map-implicit-entry(n,c) ::=
[ns-flow-map-yaml-key-entry](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-yaml-key-entry)(n,c)
| [c-ns-flow-map-empty-key-entry](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-empty-key-entry)(n,c)
| [c-ns-flow-map-json-key-entry](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-json-key-entry)(n,c)
[145] ns-flow-map-yaml-key-entry(n,c) ::=
[ns-flow-yaml-node](https://yaml.org/spec/1.2.2/#rule-ns-flow-yaml-node)(n,c)
(
(
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)?
[c-ns-flow-map-separate-value](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-separate-value)(n,c)
)
| [e-node](https://yaml.org/spec/1.2.2/#rule-e-node) # ""
)
[146] c-ns-flow-map-empty-key-entry(n,c) ::=
[e-node](https://yaml.org/spec/1.2.2/#rule-e-node) # ""
[c-ns-flow-map-separate-value](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-separate-value)(n,c)
[147] c-ns-flow-map-separate-value(n,c) ::=
[c-mapping-value](https://yaml.org/spec/1.2.2/#rule-c-mapping-value) # ':'
[ lookahead ≠ [ns-plain-safe](https://yaml.org/spec/1.2.2/#rule-ns-plain-safe)(c) ]
(
(
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)
[ns-flow-node](https://yaml.org/spec/1.2.2/#rule-ns-flow-node)(n,c)
)
| [e-node](https://yaml.org/spec/1.2.2/#rule-e-node) # ""
)
Example 7.17 Flow Mapping Separate Values
示例7.17流映射单独的值
{
unquoted·:·"separate",
https://foo.com,
omitted value:°,
°:·omitted key,
}
|
{ "unquoted": "separate",
"http://foo.com": null,
"omitted value": null,
null: "omitted key" }
—|—
Legend:
[ns-flow-yaml-node(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-yaml-node)[e-node](https://yaml.org/spec/1.2.2/#rule-e-node)[c-ns-flow-map-separate-value(n,c)](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-separate-value)
To ensure JSON compatibility,
if a key inside a flow mapping is JSON-
like, YAML allows the following
value to be specified adjacent to the
“:”. This causes no ambiguity, as all JSON-
like
keys are surrounded by
indicators. However, as
this greatly reduces readability, YAML
processors should
separate the
value from the “:” on output, even in
this case.
为了确保JSON兼容性，如果流映射中的键类似于JSON，则YAML允许在“ : ”附近指定以下值。这不会引起歧义，因为所有类似JSON的
按键被指示器包围。然而，由于这大大降低了可读性，YAML处理器应该在输出时将值与“ : ”分离，即使在这种情况下也是如此。
[148] c-ns-flow-map-json-key-entry(n,c) ::=
[c-flow-json-node](https://yaml.org/spec/1.2.2/#rule-c-flow-json-node)(n,c)
(
(
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)?
[c-ns-flow-map-adjacent-value](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-adjacent-value)(n,c)
)
| [e-node](https://yaml.org/spec/1.2.2/#rule-e-node) # ""
)
[149] c-ns-flow-map-adjacent-value(n,c) ::=
[c-mapping-value](https://yaml.org/spec/1.2.2/#rule-c-mapping-value) # ':'
(
(
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)?
[ns-flow-node](https://yaml.org/spec/1.2.2/#rule-ns-flow-node)(n,c)
)
| [e-node](https://yaml.org/spec/1.2.2/#rule-e-node) # ""
)
Example 7.18 Flow Mapping Adjacent Values
示例7.18流映射相邻值
{
"adjacent":value,
"readable":·value,
"empty":°
}
|
{ "adjacent": "value",
"readable": "value",
"empty": null }
—|—
Legend:
[c-flow-json-node(n,c)](https://yaml.org/spec/1.2.2/#rule-c-flow-json-node)[e-node](https://yaml.org/spec/1.2.2/#rule-e-node)[c-ns-flow-map-adjacent-value(n,c)](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-adjacent-value)
A more compact notation is usable inside flow
sequences, if the
mapping contains a single key/value
pair. This notation does not require the surrounding “{ ” and “}”
characters. Note that it is not possible to specify any node
properties for the
mapping in this case.
如果映射包含单个键/值对，则可以在流序列中使用更紧凑的表示法。此符号不需要周围的“ { ”和“ }
”字符。请注意，在这种情况下，不可能为映射指定任何节点属性。
Example 7.19 Single Pair Flow Mappings
示例7.19单对流映射
[
foo: bar
]
|
[ { "foo": "bar" } ]
—|—
Legend:
[ns-flow-pair(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-pair)
If the “?” indicator is explicitly specified,
parsing is
unambiguous and the syntax is identical to the general case.
如果“ ? ”指示符被显式地指定，则解析是明确的，并且语法与一般情况相同。
[150] ns-flow-pair(n,c) ::=
(
[c-mapping-key](https://yaml.org/spec/1.2.2/#rule-c-mapping-key) # '?' (not followed by non-ws char)
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)
[ns-flow-map-explicit-entry](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-explicit-entry)(n,c)
)
| [ns-flow-pair-entry](https://yaml.org/spec/1.2.2/#rule-ns-flow-pair-entry)(n,c)
Example 7.20 Single Pair Explicit Entry
示例7.20单对显式条目
[
? foo
bar : baz
]
|
[ { "foo bar": "baz" } ]
—|—
Legend:
[ns-flow-map-explicit-entry(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-map-explicit-entry)
If the “?” indicator is omitted, [parsing](https://yaml.org/spec/1.2.2
/#parsing-the-presentation-stream) needs to see past the implicit key to
recognize it as such. To limit the amount of lookahead required, the “: ”
indicator must appear at most 1024 Unicode characters beyond the start of the
key. In addition, the
key is restricted to a single line.
如果“ ? ”指示符被省略，则解析需要查看隐式键以识别它。为了限制所需的先行量，“ :
”指示符必须出现在键的起始位置以外的最多1024个Unicode字符处。此外，密钥被限制为一行。
Note that YAML allows arbitrary nodes to
be used as keys. In particular, a
key may be a
sequence or a
mapping. Thus, without the above
restrictions, practical one-pass [parsing](https://yaml.org/spec/1.2.2
/#parsing-the-presentation-stream) would have been impossible to implement.
请注意，YAML允许任意节点用作键。特别地，密钥可以是序列或映射。因此，如果没有上述限制，实际的单程解析将不可能实现。
[151] ns-flow-pair-entry(n,c) ::=
[ns-flow-pair-yaml-key-entry](https://yaml.org/spec/1.2.2/#rule-ns-flow-pair-yaml-key-entry)(n,c)
| [c-ns-flow-map-empty-key-entry](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-empty-key-entry)(n,c)
| [c-ns-flow-pair-json-key-entry](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-pair-json-key-entry)(n,c)
[152] ns-flow-pair-yaml-key-entry(n,c) ::=
[ns-s-implicit-yaml-key](https://yaml.org/spec/1.2.2/#rule-ns-s-implicit-yaml-key)(FLOW-KEY)
[c-ns-flow-map-separate-value](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-separate-value)(n,c)
[153] c-ns-flow-pair-json-key-entry(n,c) ::=
[c-s-implicit-json-key](https://yaml.org/spec/1.2.2/#rule-c-s-implicit-json-key)(FLOW-KEY)
[c-ns-flow-map-adjacent-value](https://yaml.org/spec/1.2.2/#rule-c-ns-flow-map-adjacent-value)(n,c)
[154] ns-s-implicit-yaml-key(c) ::=
[ns-flow-yaml-node](https://yaml.org/spec/1.2.2/#rule-ns-flow-yaml-node)(0,c)
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)?
/* At most 1024 characters altogether */
[155] c-s-implicit-json-key(c) ::=
[c-flow-json-node](https://yaml.org/spec/1.2.2/#rule-c-flow-json-node)(0,c)
[s-separate-in-line](https://yaml.org/spec/1.2.2/#rule-s-separate-in-line)?
/* At most 1024 characters altogether */
Example 7.21 Single Pair Implicit Entries
例7.21单对隐式条目
- [ YAML·: separate ]
- [ °: empty key entry ]
- [ {JSON: like}:adjacent ]
|
[ [ { "YAML": "separate" } ],
[ { null: "empty key entry" } ],
[ { { "JSON": "like" }: "adjacent" } ] ]
—|—
Legend:
[ns-s-implicit-yaml-key](https://yaml.org/spec/1.2.2/#rule-ns-s-implicit-yaml-key)[e-node](https://yaml.org/spec/1.2.2/#rule-e-node)[c-s-implicit-json-key](https://yaml.org/spec/1.2.2/#rule-c-s-implicit-json-key)Value
Example 7.22 Invalid Implicit Keys
例7.22无效的隐式键
[ foo
bar: invalid,
"foo_...>1K characters..._bar": invalid ]
|
ERROR:
- The foo bar key spans multiple lines
- The foo...bar key is too long
—|—
7.5. Flow Nodes 7.5.流节点
JSON-like flow styles
all have explicit start and end [indicators](https://yaml.org/spec/1.2.2
/#indicator-characters). The only [flow style](https://yaml.org/spec/1.2.2
/#flow-style-productions) that does not have this property is the plain
scalar. Note that none of the
“JSON-like” styles is actually acceptable by JSON. Even the double-quoted
style is a superset of the
JSON string format.
类似JSON的流样式都有显式的开始和结束指示符。唯一没有此属性的流样式是纯标量。请注意，JSON实际上不接受任何“类JSON”样式。甚至双引号样式也是JSON字符串格式的超集。
[156] ns-flow-yaml-content(n,c) ::=
[ns-plain](https://yaml.org/spec/1.2.2/#rule-ns-plain)(n,c)
[157] c-flow-json-content(n,c) ::=
[c-flow-sequence](https://yaml.org/spec/1.2.2/#rule-c-flow-sequence)(n,c)
| [c-flow-mapping](https://yaml.org/spec/1.2.2/#rule-c-flow-mapping)(n,c)
| [c-single-quoted](https://yaml.org/spec/1.2.2/#rule-c-single-quoted)(n,c)
| [c-double-quoted](https://yaml.org/spec/1.2.2/#rule-c-double-quoted)(n,c)
[158] ns-flow-content(n,c) ::=
[ns-flow-yaml-content](https://yaml.org/spec/1.2.2/#rule-ns-flow-yaml-content)(n,c)
| [c-flow-json-content](https://yaml.org/spec/1.2.2/#rule-c-flow-json-content)(n,c)
Example 7.23 Flow Content 示例7.23流量
- [ a, b ]
- { a: b }
- "a"
- 'b'
- c
|
[ [ "a", "b" ],
{ "a": "b" },
"a",
"b",
"c" ]
—|—
Legend:
[c-flow-json-content(n,c)](https://yaml.org/spec/1.2.2/#rule-c-flow-json-content)[ns-flow-yaml-content(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-yaml-content)
A complete flow
node also has optional node
properties, except for alias
nodes which refer to the
anchored node
properties.
完整的流程 节点还具有可选的节点属性，但别名节点除外，别名节点引用锚定的 节点属性。
[159] ns-flow-yaml-node(n,c) ::=
[c-ns-alias-node](https://yaml.org/spec/1.2.2/#rule-c-ns-alias-node)
| [ns-flow-yaml-content](https://yaml.org/spec/1.2.2/#rule-ns-flow-yaml-content)(n,c)
| (
[c-ns-properties](https://yaml.org/spec/1.2.2/#rule-c-ns-properties)(n,c)
(
(
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)
[ns-flow-yaml-content](https://yaml.org/spec/1.2.2/#rule-ns-flow-yaml-content)(n,c)
)
| [e-scalar](https://yaml.org/spec/1.2.2/#rule-e-scalar)
)
)
[160] c-flow-json-node(n,c) ::=
(
[c-ns-properties](https://yaml.org/spec/1.2.2/#rule-c-ns-properties)(n,c)
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)
)?
[c-flow-json-content](https://yaml.org/spec/1.2.2/#rule-c-flow-json-content)(n,c)
[161] ns-flow-node(n,c) ::=
[c-ns-alias-node](https://yaml.org/spec/1.2.2/#rule-c-ns-alias-node)
| [ns-flow-content](https://yaml.org/spec/1.2.2/#rule-ns-flow-content)(n,c)
| (
[c-ns-properties](https://yaml.org/spec/1.2.2/#rule-c-ns-properties)(n,c)
(
(
[s-separate](https://yaml.org/spec/1.2.2/#rule-s-separate)(n,c)
[ns-flow-content](https://yaml.org/spec/1.2.2/#rule-ns-flow-content)(n,c)
)
| [e-scalar](https://yaml.org/spec/1.2.2/#rule-e-scalar)
)
)
Example 7.24 Flow Nodes 示例7.24流节点
- !!str "a"
- 'b'
- &anchor "c"
- *anchor
- !!str°
|
[ "a",
"b",
"c",
"c",
"" ]
—|—
Legend:
[c-flow-json-node(n,c)](https://yaml.org/spec/1.2.2/#rule-c-flow-json-node)[ns-flow-yaml-node(n,c)](https://yaml.org/spec/1.2.2/#rule-ns-flow-yaml-node)
Chapter 8. Block Style Productions
第8章Block Style Productions
YAML’s block styles employ [indentation](https://yaml.org/spec/1.2.2
/#indentation-spaces) rather than [indicators](https://yaml.org/spec/1.2.2
/#indicator-characters) to denote structure. This results in a more human
readable (though less compact) notation.
YAML的块样式使用缩进而不是指示符来表示结构。这导致了一个更易于人类阅读（尽管不那么紧凑）的符号。
8.1. Block Scalar Styles 8.1.块标量样式
YAML provides two block scalar styles ,
literal and
folded. Each provides a different
trade-off between readability and expressive power.
YAML提供了两种块标量样式：literal和folded。每一种都在可读性和表达能力之间提供了不同的权衡。
8.1.1. Block Scalar Headers 8.1.1.块标量标头
Block scalars are
controlled by a few [indicators](https://yaml.org/spec/1.2.2/#indicator-
characters) given in a header preceding the
content itself. This header is followed
by a non-content [line break](https://yaml.org/spec/1.2.2/#line-break-
characters) with an optional comment.
This is the only case where a comment
must not be followed by additional
comment lines.
块标量由内容本身之前的头部中给出的几个指示符控制。此标头后面是一个非内容换行符，带有可选注释。这是唯一一种注释后面不能有附加注释行的情况。
Note: See [Production Parameters](https://yaml.org/spec/1.2.2/#production-
parameters) for the definition of thetvariable.
注：有关t变量的定义，请参见生产参数。
[162] c-b-block-header(t) ::=
(
(
[c-indentation-indicator](https://yaml.org/spec/1.2.2/#rule-c-indentation-indicator)
[c-chomping-indicator](https://yaml.org/spec/1.2.2/#rule-c-chomping-indicator)(t)
)
| (
[c-chomping-indicator](https://yaml.org/spec/1.2.2/#rule-c-chomping-indicator)(t)
[c-indentation-indicator](https://yaml.org/spec/1.2.2/#rule-c-indentation-indicator)
)
)
[s-b-comment](https://yaml.org/spec/1.2.2/#rule-s-b-comment)
Example 8.1 Block Scalar Header 示例8.1块标量标头
- | # Empty header↓
literal
- >1 # Indentation indicator↓
·folded
- |+ # Chomping indicator↓
keep
- >1- # Both indicators↓
·strip
|
[ "literal\n",
" folded\n",
"keep\n\n",
" strip" ]
—|—
Legend:
[c-b-block-header(t)](https://yaml.org/spec/1.2.2/#rule-c-b-block-header)
8.1.1.1. Block Indentation Indicator
8.1.1.1.块缩进指示器
Every block scalar has a content indentation level. The content of the block
scalar excludes a number of leading [spaces](https://yaml.org/spec/1.2.2
/#white-space-characters) on each line up to the content indentation level.
每个块标量都有一个内容缩进级别。块标量的内容在每一行上排除了直到内容缩进级别的许多前导空格。
If a block scalar has an indentation indicator , then the content
indentation level of the block scalar is equal to the indentation level of the
block scalar plus the integer value of the indentation indicator character.
如果块标量具有缩进指示符，则块标量的内容缩进级别等于块标量的缩进级别加上缩进指示符字符的整数值。
If no indentation indicator is given, then the content indentation level is
equal to the number of leading [spaces](https://yaml.org/spec/1.2.2/#white-
space-characters) on the first non-[empty line](https://yaml.org/spec/1.2.2
/#empty-lines) of the contents. If there is no non-empty
line then the content indentation
level is equal to the number of spaces on the longest line.
如果没有给出缩进指示符，则内容缩进级别等于内容的第一个非空行上的前导空格数。如果没有非空行，则内容缩进级别等于最长行上的空格数。
It is an error if any non-[empty line](https://yaml.org/spec/1.2.2/#empty-
lines) does not begin with a number of spaces greater than or equal to the
content indentation level.
如果任何非空行开始的空格数不大于或等于内容缩进级别，则是错误的。
It is an error for any of the leading empty
lines to contain more
spaces than the first
non-empty line.
如果任何前导空行包含的空格比第一个非空行多，则会出错。
A YAML processor should
only emit an explicit indentation indicator for cases where detection will
fail.
YAML处理器应该只在检测失败的情况下发出显式的缩进指示符。
[163] c-indentation-indicator ::=
[x31-x39] # 1-9
Example 8.2 Block Indentation Indicator
示例8.2块压痕指示器
- |°
·detected
- >°
·
··
··# detected
- |1
··explicit
- >°
·→
·detected
|
[ "detected\n",
"\n\n# detected\n",
" explicit\n",
"\t\ndetected\n" ]
—|—
Legend:
[c-indentation-indicator](https://yaml.org/spec/1.2.2/#rule-c-indentation-indicator)[s-indent(n)](https://yaml.org/spec/1.2.2/#rule-s-indent)
Example 8.3 Invalid Block Scalar Indentation Indicators
示例8.3无效的块标量缩进指示符
- |
··
·text
- >
··text
·text
- |2
·text
|
ERROR:
- A leading all-space line must
not have too many spaces.
- A following text line must
not be less indented.
- The text is less indented
than the indicated level.
—|—
8.1.1.2. Block Chomping Indicator
8.1.1.2.块咬合指示器
Chomping controls how final [line breaks](https://yaml.org/spec/1.2.2/#line-
break-characters) and trailing [empty lines](https://yaml.org/spec/1.2.2
/#empty-lines) are interpreted. YAML provides three chomping methods:
Chomping控制如何解释最后的换行符和尾随空行。YAML提供了三种chomping方法：
Strip
Stripping is specified by the “- ” chomping indicator. In this case, the
final line break and any
trailing empty lines are excluded
from the scalar’s content.
剥离由“ - ”咬合指示器指定。在这种情况下，最后一个换行符和任何尾随空行都将从标量的内容中排除。
Clip
Clipping is the default behavior used if no explicit chomping indicator is
specified. In this case, the final [line break](https://yaml.org/spec/1.2.2
/#line-break-characters) character is preserved in the scalar’s
content. However, any trailing empty
lines are excluded from the
scalar’s content.
如果没有指定显式的咬合指示器，则剪切是默认行为。在这种情况下，最后一个换行符保留在标量的内容中。但是，任何尾随空行都将从标量的内容中排除。
Keep
Keeping is specified by the “+ ” chomping indicator. In this case, the
final line break and any
trailing empty lines are
considered to be part of the scalar’s
content. These additional lines are not
subject to folding.
保持由“ + ”咬合指示器指定。在这种情况下，最后一个换行符和任何尾随的空行都被认为是标量内容的一部分。这些附加线不受折叠的影响。
The chomping method used is a presentation
detail and
must not be used to convey content
information.
所使用的咀嚼方法是一种表示细节，不得用于传达内容信息。
[164]
c-chomping-indicator(STRIP) ::= '-'
c-chomping-indicator(KEEP) ::= '+'
c-chomping-indicator(CLIP) ::= ""
The interpretation of the final [line break](https://yaml.org/spec/1.2.2
/#line-break-characters) of a [block scalar](https://yaml.org/spec/1.2.2
/#block-scalar-styles) is controlled by the chomping indicator specified in
the block scalar header.
块标量的最后一个换行符的解释由块标量头中指定的chomping指示符控制。
[165]
b-chomped-last(STRIP) ::= [b-non-content](https://yaml.org/spec/1.2.2/#rule-b-non-content) | <end-of-input>
b-chomped-last(CLIP) ::= [b-as-line-feed](https://yaml.org/spec/1.2.2/#rule-b-as-line-feed) | <end-of-input>
b-chomped-last(KEEP) ::= [b-as-line-feed](https://yaml.org/spec/1.2.2/#rule-b-as-line-feed) | <end-of-input>
Example 8.4 Chomping Final Line Break
示例8.4咬合最终行中断
strip: |-
text↓
clip: |
text↓
keep: |+
text↓
|
{ "strip": "text",
"clip": "text\n",
"keep": "text\n" }
—|—
Legend:
[b-non-content](https://yaml.org/spec/1.2.2/#rule-b-non-content)[b-as-line-feed](https://yaml.org/spec/1.2.2/#rule-b-as-line-feed)
The interpretation of the trailing [empty lines](https://yaml.org/spec/1.2.2
/#empty-lines) following a [block scalar](https://yaml.org/spec/1.2.2/#block-
scalar-styles) is also controlled by the chomping indicator specified in the
block scalar header.
块标量后面的尾随空行的解释也由块标量标头中指定的chomping指示符控制。
[166]
l-chomped-empty(n,STRIP) ::= [l-strip-empty](https://yaml.org/spec/1.2.2/#rule-l-strip-empty)(n)
l-chomped-empty(n,CLIP) ::= [l-strip-empty](https://yaml.org/spec/1.2.2/#rule-l-strip-empty)(n)
l-chomped-empty(n,KEEP) ::= [l-keep-empty](https://yaml.org/spec/1.2.2/#rule-l-keep-empty)(n)
[167] l-strip-empty(n) ::=
(
[s-indent-less-or-equal](https://yaml.org/spec/1.2.2/#rule-s-indent-less-or-equal)(n)
[b-non-content](https://yaml.org/spec/1.2.2/#rule-b-non-content)
)*
[l-trail-comments](https://yaml.org/spec/1.2.2/#rule-l-trail-comments)(n)?
[168] l-keep-empty(n) ::=
[l-empty](https://yaml.org/spec/1.2.2/#rule-l-empty)(n,BLOCK-IN)*
[l-trail-comments](https://yaml.org/spec/1.2.2/#rule-l-trail-comments)(n)?
Explicit comment lines may follow the
trailing empty lines. To prevent
ambiguity, the first such comment
line must be less indented
than the [block scalar content](https://yaml.org/spec/1.2.2/#block-scalar-
styles). Additional comment lines, if
any, are not so restricted. This is the only case where the
indentation of
comment lines is constrained.
显式注释行可以跟在尾随空行之后。为了防止歧义，第一个注释行的缩进必须小于块标量内容。其他注释行（如果有的话）则不受此限制。这是注释行缩进受到约束的唯一情况。
[169] l-trail-comments(n) ::=
[s-indent-less-than](https://yaml.org/spec/1.2.2/#rule-s-indent-less-than)(n)
[c-nb-comment-text](https://yaml.org/spec/1.2.2/#rule-c-nb-comment-text)
[b-comment](https://yaml.org/spec/1.2.2/#rule-b-comment)
[l-comment](https://yaml.org/spec/1.2.2/#rule-l-comment)*
Example 8.5 Chomping Trailing Lines
例8.5截断尾随行
# Strip
# Comments:
strip: |-
# text↓
··⇓
·# Clip
··# comments:
↓
clip: |
# text↓
·↓
·# Keep
··# comments:
↓
keep: |+
# text↓
↓
·# Trail
··# comments.
|
{ "strip": "# text",
"clip": "# text\n",
"keep": "# text\n\n" }
—|—
Legend:
[l-strip-empty(n)](https://yaml.org/spec/1.2.2/#rule-l-strip-empty)[l-keep-empty(n)](https://yaml.org/spec/1.2.2/#rule-l-keep-empty)[l-trail-comments(n)](https://yaml.org/spec/1.2.2/#rule-l-trail-comments)
If a block scalar consists
only of empty lines, then these
lines are considered as trailing lines and hence are affected by chomping.
如果块标量仅由空行组成，则这些行被认为是尾随行，因此受到咬合的影响。
Example 8.6 Empty Scalar Chomping
例8.6空标量Chomping
strip: >-
↓
clip: >
↓
keep: |+
↓
|
{ "strip": "",
"clip": "",
"keep": "\n" }
—|—
Legend:
[l-strip-empty(n)](https://yaml.org/spec/1.2.2/#rule-l-strip-empty)[l-keep-empty(n)](https://yaml.org/spec/1.2.2/#rule-l-keep-empty)
8.1.2. Literal Style 8.1.2.文字风格
The literal style is denoted by the “| ” indicator. It is the simplest,
most restricted and most readable [scalar style](https://yaml.org/spec/1.2.2
/#node-styles).
文字样式由“ | ”指示符表示。它是最简单、限制最多、可读性最强的标量样式。
[170] c-l+literal(n) ::=
[c-literal](https://yaml.org/spec/1.2.2/#rule-c-literal) # '|'
[c-b-block-header](https://yaml.org/spec/1.2.2/#rule-c-b-block-header)(t)
[l-literal-content](https://yaml.org/spec/1.2.2/#rule-l-literal-content)(n+m,t)
Example 8.7 Literal Scalar 例8.7文字标量
|↓
·literal↓
·→text↓
↓
|
"literal\n\ttext\n"
—|—
Legend:
[c-l+literal(n)](https://yaml.org/spec/1.2.2/#rule-c-l+literal)
Inside literal scalars, all ([indented](https://yaml.org/spec/1.2.2
/#indentation-spaces)) characters are considered to be
content, including white
space characters. Note
that all line break
characters are [normalized](https://yaml.org/spec/1.2.2/#line-break-
characters). In addition, [empty lines](https://yaml.org/spec/1.2.2/#empty-
lines) are not folded, though
final line breaks and
trailing empty lines are
chomped.
在文字标量中，所有（缩进的）字符都被认为是内容，包括白色字符。请注意，所有的换行符都是规范化的。此外，空行不会被折叠，但最后的换行符和尾随的空行会被截断。
There is no way to escape characters inside literal scalars. This restricts
them to printable characters. In
addition, there is no way to break a long literal line.
没有办法对文字标量中的字符进行转义。这将它们限制为可打印的字符。此外，没有办法打破一个长的文字行。
[171] l-nb-literal-text(n) ::=
[l-empty](https://yaml.org/spec/1.2.2/#rule-l-empty)(n,BLOCK-IN)*
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n) [nb-char](https://yaml.org/spec/1.2.2/#rule-nb-char)+
[172] b-nb-literal-next(n) ::=
[b-as-line-feed](https://yaml.org/spec/1.2.2/#rule-b-as-line-feed)
[l-nb-literal-text](https://yaml.org/spec/1.2.2/#rule-l-nb-literal-text)(n)
[173] l-literal-content(n,t) ::=
(
[l-nb-literal-text](https://yaml.org/spec/1.2.2/#rule-l-nb-literal-text)(n)
[b-nb-literal-next](https://yaml.org/spec/1.2.2/#rule-b-nb-literal-next)(n)*
[b-chomped-last](https://yaml.org/spec/1.2.2/#rule-b-chomped-last)(t)
)?
[l-chomped-empty](https://yaml.org/spec/1.2.2/#rule-l-chomped-empty)(n,t)
Example 8.8 Literal Content 示例8.8文字内容
|
·
··
··literal↓
···↓
··
··text↓
↓
·# Comment
|
"\n\nliteral\n·\n\ntext\n"
—|—
Legend:
[l-nb-literal-text(n)](https://yaml.org/spec/1.2.2/#rule-l-nb-literal-text)[b-nb-literal-next(n)](https://yaml.org/spec/1.2.2/#rule-b-nb-literal-next)[b-chomped-last(t)](https://yaml.org/spec/1.2.2/#rule-b-chomped-last)[l-chomped-empty(n,t)](https://yaml.org/spec/1.2.2/#rule-l-chomped-empty)
8.1.3. Folded Style 8.1.3.折叠式
The folded style is denoted by the “> ” indicator. It is similar to the
literal style; however, folded
scalars are subject to [line folding](https://yaml.org/spec/1.2.2/#line-
folding).
折叠样式由“ > ”指示符表示。它类似于字面风格;然而，折叠标量经受线折叠。
[174] c-l+folded(n) ::=
[c-folded](https://yaml.org/spec/1.2.2/#rule-c-folded) # '>'
[c-b-block-header](https://yaml.org/spec/1.2.2/#rule-c-b-block-header)(t)
[l-folded-content](https://yaml.org/spec/1.2.2/#rule-l-folded-content)(n+m,t)
Example 8.9 Folded Scalar 例8.9折叠标量
>↓
·folded↓
·text↓
↓
|
"folded text\n"
—|—
Legend:
[c-l+folded(n)](https://yaml.org/spec/1.2.2/#rule-c-l+folded)
Folding allows long lines to be
broken anywhere a single [space](https://yaml.org/spec/1.2.2/#white-space-
characters) character separates two non-[space](https://yaml.org/spec/1.2.2
/#white-space-characters) characters.
折叠允许在单个空格字符分隔两个非空格字符的任何地方断开长行。
[175] s-nb-folded-text(n) ::=
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n)
[ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char)
[nb-char](https://yaml.org/spec/1.2.2/#rule-nb-char)*
[176] l-nb-folded-lines(n) ::=
[s-nb-folded-text](https://yaml.org/spec/1.2.2/#rule-s-nb-folded-text)(n)
(
[b-l-folded](https://yaml.org/spec/1.2.2/#rule-b-l-folded)(n,BLOCK-IN)
[s-nb-folded-text](https://yaml.org/spec/1.2.2/#rule-s-nb-folded-text)(n)
)*
Example 8.10 Folded Lines 例8.10折叠线
>
·folded↓
·line↓
↓
·next
·line↓
* bullet
* list
* lines
·last↓
·line↓
# Comment
|
"\nfolded line\nnext line\n \
* bullet\n \n * list\n \
* lines\n\nlast line\n"
—|—
Legend:
[l-nb-folded-lines(n)](https://yaml.org/spec/1.2.2/#rule-l-nb-folded-lines)[s-nb-folded-text(n)](https://yaml.org/spec/1.2.2/#rule-s-nb-folded-text)
(The following three examples duplicate this example, each highlighting
different productions.)
(The以下三个示例重复该示例，每个示例突出显示不同的产品。
Lines starting with [white space](https://yaml.org/spec/1.2.2/#white-space-
characters) characters ( more-indented lines) are not
folded.
白色字符开头的行（缩进较多的行）不会折叠。
[177] s-nb-spaced-text(n) ::=
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n)
[s-white](https://yaml.org/spec/1.2.2/#rule-s-white)
[nb-char](https://yaml.org/spec/1.2.2/#rule-nb-char)*
[178] b-l-spaced(n) ::=
[b-as-line-feed](https://yaml.org/spec/1.2.2/#rule-b-as-line-feed)
[l-empty](https://yaml.org/spec/1.2.2/#rule-l-empty)(n,BLOCK-IN)*
[179] l-nb-spaced-lines(n) ::=
[s-nb-spaced-text](https://yaml.org/spec/1.2.2/#rule-s-nb-spaced-text)(n)
(
[b-l-spaced](https://yaml.org/spec/1.2.2/#rule-b-l-spaced)(n)
[s-nb-spaced-text](https://yaml.org/spec/1.2.2/#rule-s-nb-spaced-text)(n)
)*
Example 8.11 More Indented Lines 例8.11更多缩进行
>
folded
p: |+
↓
|
{ "strip": "",
"clip": "",
"keep": "\n" }
—|—
Legend:
[l-strip-empty(n)](https://yaml.org/spec/1.2.2/#rule-l-strip-empty)[l-keep-empty(n)](https://yaml.org/spec/1.2.2/#rule-l-keep-empty)
8.1.2. Literal Style 8.1.2.文字风格
The literal style is denoted by the “| ” indicator. It is the simplest,
most restricted and most readable [scalar style](https://yaml.org/spec/1.2.2
/#node-styles).
文字样式由“ | ”指示符表示。它是最简单、限制最多、可读性最强的标量样式。
[170] c-l+literal(n) ::=
[c-literal](https://yaml.org/spec/1.2.2/#rule-c-literal) # '|'
[c-b-block-header](https://yaml.org/spec/1.2.2/#rule-c-b-block-header)(t)
[l-literal-content](https://yaml.org/spec/1.2.2/#rule-l-literal-content)(n+m,t)
Example 8.7 Literal Scalar 例8.7文字标量
|↓
·literal↓
·→text↓
↓
|
"literal\n\ttext\n"
—|—
Legend:
[c-l+literal(n)](https://yaml.org/spec/1.2.2/#rule-c-l+literal)
Inside literal scalars, all ([indented](https://yaml.org/spec/1.2.2
/#indentation-spaces)) characters are considered to be
content, including white
space characters. Note
that all line break
characters are [normalized](https://yaml.org/spec/1.2.2/#line-break-
characters). In addition, [empty lines](https://yaml.org/spec/1.2.2/#empty-
lines) are not folded, though
final line breaks and
trailing empty lines are
chomped.
在文字标量中，所有（缩进的）字符都被认为是内容，包括白色字符。请注意，所有的换行符都是规范化的。此外，空行不会被折叠，但最后的换行符和尾随的空行会被截断。
There is no way to escape characters inside literal scalars. This restricts
them to printable characters. In
addition, there is no way to break a long literal line.
没有办法对文字标量中的字符进行转义。这将它们限制为可打印的字符。此外，没有办法打破一个长的文字行。
[171] l-nb-literal-text(n) ::=
[l-empty](https://yaml.org/spec/1.2.2/#rule-l-empty)(n,BLOCK-IN)*
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n) [nb-char](https://yaml.org/spec/1.2.2/#rule-nb-char)+
[172] b-nb-literal-next(n) ::=
[b-as-line-feed](https://yaml.org/spec/1.2.2/#rule-b-as-line-feed)
[l-nb-literal-text](https://yaml.org/spec/1.2.2/#rule-l-nb-literal-text)(n)
[173] l-literal-content(n,t) ::=
(
[l-nb-literal-text](https://yaml.org/spec/1.2.2/#rule-l-nb-literal-text)(n)
[b-nb-literal-next](https://yaml.org/spec/1.2.2/#rule-b-nb-literal-next)(n)*
[b-chomped-last](https://yaml.org/spec/1.2.2/#rule-b-chomped-last)(t)
)?
[l-chomped-empty](https://yaml.org/spec/1.2.2/#rule-l-chomped-empty)(n,t)
Example 8.8 Literal Content 示例8.8文字内容
|
·
··
··literal↓
···↓
··
··text↓
↓
·# Comment
|
"\n\nliteral\n·\n\ntext\n"
—|—
Legend:
[l-nb-literal-text(n)](https://yaml.org/spec/1.2.2/#rule-l-nb-literal-text)[b-nb-literal-next(n)](https://yaml.org/spec/1.2.2/#rule-b-nb-literal-next)[b-chomped-last(t)](https://yaml.org/spec/1.2.2/#rule-b-chomped-last)[l-chomped-empty(n,t)](https://yaml.org/spec/1.2.2/#rule-l-chomped-empty)
8.1.3. Folded Style 8.1.3.折叠式
The folded style is denoted by the “> ” indicator. It is similar to the
literal style; however, folded
scalars are subject to [line folding](https://yaml.org/spec/1.2.2/#line-
folding).
折叠样式由“ > ”指示符表示。它类似于字面风格;然而，折叠标量经受线折叠。
[174] c-l+folded(n) ::=
[c-folded](https://yaml.org/spec/1.2.2/#rule-c-folded) # '>'
[c-b-block-header](https://yaml.org/spec/1.2.2/#rule-c-b-block-header)(t)
[l-folded-content](https://yaml.org/spec/1.2.2/#rule-l-folded-content)(n+m,t)
Example 8.9 Folded Scalar 例8.9折叠标量
>↓
·folded↓
·text↓
↓
|
"folded text\n"
—|—
Legend:
[c-l+folded(n)](https://yaml.org/spec/1.2.2/#rule-c-l+folded)
Folding allows long lines to be
broken anywhere a single [space](https://yaml.org/spec/1.2.2/#white-space-
characters) character separates two non-[space](https://yaml.org/spec/1.2.2
/#white-space-characters) characters.
折叠允许在单个空格字符分隔两个非空格字符的任何地方断开长行。
[175] s-nb-folded-text(n) ::=
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n)
[ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char)
[nb-char](https://yaml.org/spec/1.2.2/#rule-nb-char)*
[176] l-nb-folded-lines(n) ::=
[s-nb-folded-text](https://yaml.org/spec/1.2.2/#rule-s-nb-folded-text)(n)
(
[b-l-folded](https://yaml.org/spec/1.2.2/#rule-b-l-folded)(n,BLOCK-IN)
[s-nb-folded-text](https://yaml.org/spec/1.2.2/#rule-s-nb-folded-text)(n)
)*
Example 8.10 Folded Lines 例8.10折叠线
>
·folded↓
·line↓
↓
·next
·line↓
* bullet
* list
* lines
·last↓
·line↓
# Comment
|
"\nfolded line\nnext line\n \
* bullet\n \n * list\n \
* lines\n\nlast line\n"
—|—
Legend:
[l-nb-folded-lines(n)](https://yaml.org/spec/1.2.2/#rule-l-nb-folded-lines)[s-nb-folded-text(n)](https://yaml.org/spec/1.2.2/#rule-s-nb-folded-text)
(The following three examples duplicate this example, each highlighting
different productions.)
(The以下三个示例重复该示例，每个示例突出显示不同的产品。
Lines starting with [white space](https://yaml.org/spec/1.2.2/#white-space-
characters) characters ( more-indented lines) are not
folded.
白色字符开头的行（缩进较多的行）不会折叠。
[177] s-nb-spaced-text(n) ::=
s-indent(n)
s-white
nb-char*
[178] b-l-spaced(n) ::=
b-as-line-feed
l-empty(n,BLOCK-IN)*
[179] l-nb-spaced-lines(n) ::=
s-nb-spaced-text(n)
(
b-l-spaced(n)
s-nb-spaced-text(n)
)*
Example 8.11 More Indented Lines 例8.11更多缩进行
>
folded
line
next
line
···* bullet↓
↓
···* list↓
···* lines↓
last
line
# Comment
|
"\nfolded line\nnext line\n \
* bullet\n \n * list\n \
* lines\n\nlast line\n"
—|—
Legend:
[l-nb-spaced-lines(n)](https://yaml.org/spec/1.2.2/#rule-l-nb-spaced-lines)[s-nb-spaced-text(n)](https://yaml.org/spec/1.2.2/#rule-s-nb-spaced-text)
Line breaks and empty
lines separating folded and more-
indented lines are also not [folded](https://yaml.org/spec/1.2.2/#line-
folding).
分隔折叠行和缩进较多的行的换行符和空行也不会折叠。
[180] l-nb-same-lines(n) ::=
[l-empty](https://yaml.org/spec/1.2.2/#rule-l-empty)(n,BLOCK-IN)*
(
[l-nb-folded-lines](https://yaml.org/spec/1.2.2/#rule-l-nb-folded-lines)(n)
| [l-nb-spaced-lines](https://yaml.org/spec/1.2.2/#rule-l-nb-spaced-lines)(n)
)
[181] l-nb-diff-lines(n) ::=
[l-nb-same-lines](https://yaml.org/spec/1.2.2/#rule-l-nb-same-lines)(n)
(
[b-as-line-feed](https://yaml.org/spec/1.2.2/#rule-b-as-line-feed)
[l-nb-same-lines](https://yaml.org/spec/1.2.2/#rule-l-nb-same-lines)(n)
)*
Example 8.12 Empty Separation Lines
例8.12空分隔线
>
↓
folded
line↓
↓
next
line↓
* bullet
* list
* lines↓
↓
last
line
# Comment
|
"\nfolded line\nnext line\n \
* bullet\n \n * list\n \
* lines\n\nlast line\n"
—|—
Legend:
[b-as-line-feed](https://yaml.org/spec/1.2.2/#rule-b-as-line-feed)(separation) [l-empty(n,c)](https://yaml.org/spec/1.2.2/#rule-l-empty)
The final line break and
trailing empty lines if any, are
subject to chomping
and are never folded.
最后一个换行符和尾随的空行（如果有的话）会被咬掉，并且永远不会被折叠。
[182] l-folded-content(n,t) ::=
(
[l-nb-diff-lines](https://yaml.org/spec/1.2.2/#rule-l-nb-diff-lines)(n)
[b-chomped-last](https://yaml.org/spec/1.2.2/#rule-b-chomped-last)(t)
)?
[l-chomped-empty](https://yaml.org/spec/1.2.2/#rule-l-chomped-empty)(n,t)
Example 8.13 Final Empty Lines 例8.13最终空行
>
folded
line
next
line
* bullet
* list
* lines
last
line↓
↓
# Comment
|
"\nfolded line\nnext line\n \
* bullet\n \n * list\n \
* lines\n\nlast line\n"
—|—
Legend:
[b-chomped-last(t)](https://yaml.org/spec/1.2.2/#rule-b-chomped-last)[l-chomped-empty(n,t)](https://yaml.org/spec/1.2.2/#rule-l-chomped-empty)
8.2. Block Collection Styles 8.2.块集合样式
For readability, block collections styles are not denoted by any
indicator. Instead, YAML
uses a lookahead method, where a block collection is distinguished from a
plain scalar only when a
key/value pair or a sequence
entry is seen.
为了便于阅读，块集合样式不使用任何指示符来表示。相反，YAML使用了一种前瞻方法，只有当看到键/值对或序列条目时，才能将块集合与普通标量区分开来。
8.2.1. Block Sequences 8.2.1.块序列
A block sequence is simply a series of
nodes , each denoted by a leading “-”
indicator. The “-” indicator must be [separated](https://yaml.org/spec/1.2.2
/#separation-spaces) from the node by
white space. This
allows “-” to be used as the first character in a plain
scalar if followed by a non-space
character (e.g. “-42”).
块序列简单地是一系列节点，每个节点由前导“ - ”指示符表示。“ - ”指示符必须与节点白色分隔。这允许“ -
”被用作纯标量中的第一个字符，如果后面跟着非空格字符（例如“ -42 ”）。
[183] l+block-sequence(n) ::=
(
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n+1+m)
[c-l-block-seq-entry](https://yaml.org/spec/1.2.2/#rule-c-l-block-seq-entry)(n+1+m)
)+
[184] c-l-block-seq-entry(n) ::=
[c-sequence-entry](https://yaml.org/spec/1.2.2/#rule-c-sequence-entry) # '-'
[ lookahead ≠ [ns-char](https://yaml.org/spec/1.2.2/#rule-ns-char) ]
[s-l+block-indented](https://yaml.org/spec/1.2.2/#rule-s-l+block-indented)(n,BLOCK-IN)
Example 8.14 Block Sequence 示例8.14块序列
block sequence:
··- one↓
- two : three↓
|
{ "block sequence": [
"one",
{ "two": "three" } ] }
—|—
Legend:
[c-l-block-seq-entry(n)](https://yaml.org/spec/1.2.2/#rule-c-l-block-seq-entry)auto-detected [s-indent(n)](https://yaml.org/spec/1.2.2/#rule-s-indent)
The entry node may be either completely
empty, be a nested block
node or use a compact in-line
notation. The compact notation may be used when the entry is itself a nested
block collection. In
this case, both the “- ” indicator and the following
spaces are considered
to be part of the [indentation](https://yaml.org/spec/1.2.2/#indentation-
spaces) of the nested collection.
Note that it is not possible to specify node
properties for such a
collection.
入口节点可以是完全空的、嵌套的块节点或使用紧凑的行内表示法。当条目本身是嵌套块集合时，可以使用紧凑表示法。在这种情况下，“ -
”指示符和后面的空格都被认为是嵌套集合缩进的一部分。请注意，无法为此类集合指定节点属性。
[185] s-l+block-indented(n,c) ::=
(
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(m)
(
[ns-l-compact-sequence](https://yaml.org/spec/1.2.2/#rule-ns-l-compact-sequence)(n+1+m)
| [ns-l-compact-mapping](https://yaml.org/spec/1.2.2/#rule-ns-l-compact-mapping)(n+1+m)
)
)
| [s-l+block-node](https://yaml.org/spec/1.2.2/#rule-s-l+block-node)(n,c)
| (
[e-node](https://yaml.org/spec/1.2.2/#rule-e-node) # ""
[s-l-comments](https://yaml.org/spec/1.2.2/#rule-s-l-comments)
)
[186] ns-l-compact-sequence(n) ::=
[c-l-block-seq-entry](https://yaml.org/spec/1.2.2/#rule-c-l-block-seq-entry)(n)
(
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n)
[c-l-block-seq-entry](https://yaml.org/spec/1.2.2/#rule-c-l-block-seq-entry)(n)
)*
Example 8.15 Block Sequence Entry Types
示例8.15块序列条目类型
-° # Empty
- |
block node
-·- one # Compact
··- two # sequence
- one: two # Compact mapping
|
[ null,
"block node\n",
[ "one", "two" ],
{ "one": "two" } ]
—|—
Legend:
Empty[s-l+block-node(n,c)](https://yaml.org/spec/1.2.2/#rule-s-l+block-node)[ns-l-compact-sequence(n)](https://yaml.org/spec/1.2.2/#rule-ns-l-compact-sequence)[ns-l-compact-mapping(n)](https://yaml.org/spec/1.2.2/#rule-ns-l-compact-mapping)
8.2.2. Block Mappings 8.2.2.块映射
A Block mapping is a series of entries, each
presenting a
key/value pair.
块映射是一系列条目，每个条目表示一个键/值对。
[187] l+block-mapping(n) ::=
(
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n+1+m)
[ns-l-block-map-entry](https://yaml.org/spec/1.2.2/#rule-ns-l-block-map-entry)(n+1+m)
)+
Example 8.16 Block Mappings 示例8.16块映射
block mapping:
·key: value↓
|
{ "block mapping": {
"key": "value" } }
—|—
Legend:
[ns-l-block-map-entry(n)](https://yaml.org/spec/1.2.2/#rule-ns-l-block-map-entry)auto-detected [s-indent(n)](https://yaml.org/spec/1.2.2/#rule-s-indent)
If the “?” indicator is specified, the optional value node must be specified
on a separate line, denoted by the “:” indicator. Note that YAML allows here
the same [compact in-line notation](https://yaml.org/spec/1.2.2/#example-
block-sequence) described above for block
sequence entries.
如果指定了“ ? ”指示符，则必须在单独的行上指定可选值节点，由“ :
”指示符表示。注意，YAML在这里允许与上面针对块序列条目描述的相同的紧凑内联表示法。
[188] ns-l-block-map-entry(n) ::=
[c-l-block-map-explicit-entry](https://yaml.org/spec/1.2.2/#rule-c-l-block-map-explicit-entry)(n)
| [ns-l-block-map-implicit-entry](https://yaml.org/spec/1.2.2/#rule-ns-l-block-map-implicit-entry)(n)
[189] c-l-block-map-explicit-entry(n) ::=
[c-l-block-map-explicit-key](https://yaml.org/spec/1.2.2/#rule-c-l-block-map-explicit-key)(n)
(
[l-block-map-explicit-value](https://yaml.org/spec/1.2.2/#rule-l-block-map-explicit-value)(n)
| [e-node](https://yaml.org/spec/1.2.2/#rule-e-node) # ""
)
[190] c-l-block-map-explicit-key(n) ::=
[c-mapping-key](https://yaml.org/spec/1.2.2/#rule-c-mapping-key) # '?' (not followed by non-ws char)
[s-l+block-indented](https://yaml.org/spec/1.2.2/#rule-s-l+block-indented)(n,BLOCK-OUT)
[191] l-block-map-explicit-value(n) ::=
[s-indent](https://yaml.org/spec/1.2.2/#rule-s-indent)(n)
[c-mapping-value](https://yaml.org/spec/1.2.2/#rule-c-mapping-value) # ':' (not followed by non-ws char)
[s-l+block-indented](https://yaml.org/spec/1.2.2/#rule-s-l+block-indented)(n,BLOCK-OUT)
Example 8.17 Explicit Block Mapping Entries
示例8.17显式块映射条目
? explicit key # Empty value↓°
? |
block key↓
:·- one # Explicit compact
··- two # block value↓
|
{ "explicit key": null,
"block key\n": [
"one",
"two" ] }
—|—
Legend:
[c-l-block-map-explicit-key(n)](https://yaml.org/spec/1.2.2/#rule-c-l-block-map-explicit-key)[l-block-map-explicit-value(n)](https://yaml.org/spec/1.2.2/#rule-l-block-map-explicit-value)[e-node](https://yaml.org/spec/1.2.2/#rule-e-node)
If the “?” indicator is omitted, [parsing](https://yaml.org/spec/1.2.2
/#parsing-the-presentation-stream) needs to see past the implicit
key, in the
same way as in the single key/value
pair flow
mapping. Hence, such
keys are subject to the same
restrictions; they are limited to a single line and must not span more than
1024 Unicode characters.
如果省略了“ ? ”指示符，解析需要看到隐式键，与单个键/值对相同
流映射因此，这样的密钥受到相同的限制;它们被限制为一行，并且不能跨越超过1024个Unicode字符。
1483
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
