YAML 中单个“n"字符的特殊意义? [英] Special significance to single 'n' character in YAML?
问题描述
单个 n 字符在 YAML 中有什么特殊意义吗?我问是因为我的 Sublime 3 文本编辑器用与其他字符串值不同的颜色突出显示它，我真的不明白它的原因.
Does a single n character hold any special significance in YAML? I'm asking because my Sublime 3 Text Editor highlights it with a different color than other string values and I don't really understand the reason for it.
推荐答案
TL;DR; n 是 2009 年之前的 YAML 规范表示，用于布尔假"值.
TL;DR; That n is the, pre-2009, canonical representation in YAML for the boolean "False" value.
Sublime 不应该默认突出显示，因为 n 自 2009 年以来在 YAML 中没有这样的表示.如果有的话，它应该只突出显示 n 如果你明确指定要通过界面编辑 YAML 1.1 文件，或者如果文档是通过文档顶部的指令 %YAML 1.1 识别的.
Sublime should not highlight that by default as n hasn't had such a representation in YAML since 2009. If at all, it should only highlight that n if you explicitly specified to be editing a YAML 1.1 file via the interface, or if the document was recognised as such via the directive %YAML 1.1 at the top of the document.
在 YAML 中，标量可以有不同的格式(来自 YAML 1.2 规范):
In YAML a scalar can have different formats (from the YAML 1.2 specification):
YAML 允许以多种格式呈现标量.例如，整数11"也可以写成0xB".标签必须指定一种机制，用于将格式化内容转换为规范形式以用于等式测试.和节点样式一样，格式是一个表示细节，不会反映在序列化树和表示图中.
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 and is not reflected in the serialization tree and representation graph.
较旧的 1.1 规范在该段落中有一个不同的第二句，即 直接提到布尔值:
The older 1.1 specification has a different second sentence in that paragraph, that directly mentions booleans:
例如，布尔值true"也可以写成yes".
For example, the boolean "true" might also be written as "yes".
在您的编程语言中如何构建 YAML 标量取决于解析器使用的架构.最基本的模式将每个标量构造为一个字符串(即没有解释).
How a YAML scalar is constructed in your programming language depends on the schema the parser uses. The most basic schema constructs every scalar as a string (i.e. no interpretation).
在更实际的模式中，有规范形式(通常用于表示计算机编程类型，如整数、布尔值、日期时间戳等)和允许构造的匹配标量(通常通过正则表达式)作为这样的类型.例如 42 是规范表示，但在输入端 0x2a 和 0o52 也被允许用于相同的整数值.
In more practical schema, there is the canonical form (typically used when representing a computer programming type like an integer, boolean, date-time-stamp, etc.) and the matching scalars (often via regular expressions) that allow construction as such a type. E.g 42 is the canonical representation, but on the input side 0x2a and 0o52 are allowed as well for the same integer value.
在 YAML 1.2 中，布尔值的核心架构被清理为规范形式 true 和 false 同时匹配 true, True, TRUE, false、False 和 FALSE—仅允许 true 和 false 的更简单 JSON 模式的扩展.
In YAML 1.2 the core schemas for booleans were sanitized to the canonical forms true and false while matching true, True, TRUE, false, False and FALSE— an extension the simpler JSON schema that only allows true and false.
This was changed extensively from YAML 1.1 where canonical representation was y and n while matching all of y, Y, yes, Yes, YES, n, N, no, No, NO, true, True, TRUE, false, False, FALSE, on, On, ON, off, Off, OFF. This often led to confusion, as matching strings in a program had to be represented in YAML with explicit quotes, in order not to be interpreted as booleans on loading.
Sublime 似乎支持 YAML 1.1 规范，其中布尔值可以写为 n.由于 YAML 1.2 规范是从 2009 年开始的，我真的不认为 Sublime 这样做是正确的，并且不应将 n 解释为布尔值，除非 YAML 文档以显式指令 开头%YAML 1.1.(因为您没有在界面中说明这一点，而且文档中也没有，所以我认为您没有).
Sublime seems to support the YAML 1.1 specification where a boolean could be written as n. Since the YAML 1.2 specification is from 2009, I really don't thing Sublime is correct in doing so, and should not interpret n as a boolean, unless the YAML document starts with an explicit directive %YAML 1.1. (Since you gave no indication of that in the interface, and since it is not in the document, I don't think you have).
当然，Sublime 的原始版本早于 YAML 1.2 规范，但您希望 8 年后他们会通过更新来纠正这个问题.另一个此类更改是以 0 开头的标量，例如 0123，它们在 YAML 1.2 中是字符串，但在 YAML 1.1 中是(八进制)整数.也许您将其用作测试以查看 YAML 模式是否已正确更新:除非您明确指定 YAML 1.1，否则不应在编辑器中突出显示 0123.
Of course Sublime's original release preceded the YAML 1.2 specification, but you would hope that after 8 years they would have corrected this by an update. Another such change are scalars that start with 0, like 0123, which are strings in YAML 1.2 but were an (octal) integers in YAML 1.1. Maybe you use that as a test to see if the YAML mode has been correctly updated: 0123 should not be highlighted in your editor unless you explicitly specified YAML 1.1.
当然，有些过时的库只支持 YAML 1.1，您甚至可能正在使用，但这不能成为编辑器中默认的借口.
There are of course outdated libraries that only support YAML 1.1, and you might even be using one, but that is no excuse for that being the default in an editor.
这篇关于YAML 中单个“n"字符的特殊意义?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
