根据yaml.org,官方文件扩展名为.yaml
.
引用:
YAML 文件有官方扩展名吗?
请尽可能使用“.yaml”。
然而,互联网上似乎对使用哪个扩展存在分歧。如果您在网上查找示例,其中许多都使用未经批准的.yml
扩展名。
用 Google 搜索返回的结果是较短的结果的近 3 倍。
49,100
15,400
那么我应该使用哪个?创建者建议的正确的 4 个字母扩展名,还是在互联网的狂野西部发现的 3 个字母扩展名?
文件扩展名的性质甚至存在依赖于平台(一些晦涩的平台甚至没有,记住)——在其他系统中它们只是常规的(UNIX 及其同类),而在其他系统中它们具有明确的语义在某些情况下,对长度或字符内容(Windows 等)的特定限制。
由于维护人员要求您使用“.yaml”,这与您可以获得的“官方”裁决一样接近,但很难摆脱8.3的习惯(而且,令人震惊的是,在 2013 年仍然偶尔会出现相关性)。
编辑:
那么我应该使用哪个?创建者建议的正确的 4 个字母扩展名,还是在互联网的狂野西部发现的 3 个字母扩展名?
这个问题可能是:
咨询请求;或者
一种体验到的特定情绪的自然表达,同时人们观察到一些官方建议被忽视——显着地,甚至主要地。
人们对以下的偏好有所不同:
官方建议;或者
实践的优势。
当然,我不太可能影响你,这两条路你更喜欢走哪一条!
在接下来的内容中(并且,本着科学的精神),我只是做出一个假设,关于是什么(仅作为事实)导致大多数人使用 3 字母扩展名。而且,我专注于有效的原因。
借此,我无意进行道德劝告。您可能还记得,某事存在的事实并不意味着它应该存在。
无论您的个人倾向如何,无论是走一条路还是另一条路,我都不反对。
(编辑结束。)
建议,这种偏好(在现实生活中的使用)是由 8.3 个字符的 DOS 限制引起的,IMO 是一个红鲱鱼(错误和误导)。
截至 2016 年 8 月,YML 和 YAML 的 Google 搜索计数约为 6,000,000 和 4,100,000(精确到两位数)。此外,“YAML”计数高得不公平,因为它包括按名称提及该语言,而不是用作扩展。
截至 2018 年 7 月,Google 对 YML 和 YAML 的搜索计数分别约为8,100,000和4,100,000(同样精确到两位数)。所以,在过去的两年里,YML 的受欢迎程度基本上翻了一番,但 YAML 保持不变。
另一种文化措施是试图解释文件扩展名的网站。例如,在 FilExt 网站上(截至 2018 年 7 月),YAML页面显示:“糟糕!FILEXT.com 数据库没有任何关于文件扩展名 .YAML 的信息。”
然而,它有一个YML条目,它给出:“YAML ...使用文本文件并将其组织成人类可读的格式。'database.yml'是 Ruby on Rails 使用 YAML 时的典型示例连接到数据库。”
截至 2014 年 11 月,维基百科关于扩展名YML的文章仍然指出“.yml”是“ YAML 文件格式的文件扩展名”(强调添加)。它的YAML文章列出了这两个扩展,但没有表达偏好。
扩展名“.yml”足够清晰,更简短(因此更容易输入和识别),并且更常见。
当然,这两个扩展名都可以看作是一个很长的可能的扩展名“.yamlaintmarkuplanguage”的缩写。但是程序员(和用户)不想输入所有这些!
相反,我们程序员(和用户)希望尽可能少地打字,但仍要清晰明了。我们希望尽快查看它是什么类型的文件,而无需阅读更长的单词。输入多少个字符可以实现这两个目标?答案不是三(3)吗?换句话说,YML?
Wikipedia 的Category:Filename_extensions页面列出了.a、.o和.Z的条目。不知何故,它错过了 .c 和 .h(由 C 语言使用)。这些示例单字母扩展帮助我们看到扩展应该尽可能长,但不再是(半引用阿尔伯特爱因斯坦)。
相反,请注意,通常很少有扩展以“Y”开头。另一方面,通常,字母 X 用于多种含义,包括“交叉”、“可扩展”、“极端”、“可变”等(例如在 XML 中)。因此,以“Y”开头已经传达了很多信息(就信息论而言),而以“X”开头则没有。
因此,从语言上讲,首字母缩略词“XML”(在某种程度上)只有两个信息性字母(“M”和“L”)。相反,“YML”具有三个信息性字母(“M”、“L”和“Y”)。事实上,现有的以 Y 开头的首字母缩略词集似乎非常少。暗示,这就是为什么四字母 YAML 文件扩展名感觉被过度指定的原因。
也许这就是为什么我们在实践中看到将所讨论的缩写词延长到四 (4) 个字符的“语言”压力(自然使用)很弱,而将这个缩写词缩短到三 (3) 个字符的“语言”压力很弱强。
可能纯粹是这些因素的结果(而不是作为官方认可),我会注意到YAML.org网站的最新消息(从 2011 年 11 月开始)都是关于一个用 JavaScript 编写的项目,JS-YAML,它本身在内部更喜欢使用扩展名“.yml”。
上述因素可能是主要因素;尽管如此,所有因素(已知或未知)都导致缩写的三 (3) 个字符扩展成为 YAML 的主要用途——尽管发明人偏爱。
“.YML”似乎是事实上的标准。然而,同样的发明者对世界对人类可读数据语言的需求具有洞察力和正确性。我们应该感谢他们提供它。
.yaml
显然是官方扩展,因为某些应用程序在使用.yml
. 另一方面,我不熟悉任何使用 YAML 代码但因.yaml
扩展而失败的应用程序。
我只是偶然发现了这一点,因为我习惯于用.yml
Ansible 和 Docker Compose 编写代码。出于习惯,我.yml
在编写静默失败的 Netplan 文件时使用。我终于明白了我的错误。Netplan 的一个流行的 Ansible Galaxy 角色的作者在他的代码中做了同样的假设:
- name: Capturing Existing Configurations
find:
paths: /etc/netplan
patterns: "*.yml,*.yaml"
register: _netplan_configs
然而,任何带有扩展名的文件.yml
都会被 Netplan 以与带有.bak
扩展名的文件相同的方式忽略。由于 Netplan 非常安静,并且没有给出任何关于成功的反馈,即使使用netplan apply --debug
,这样的配置01-netcfg.yml
也会在没有任何有意义的反馈的情况下静默失败。
在阅读了网上一堆人对此的评论后,我的第一反应是,这基本上是那些真正不重要的辩论之一。但是,我最初的兴趣是找出正确的格式,以便与我的文件命名实践保持一致。
长话短说,YAML 的创建者在说.yaml
,但我个人一直在做.yml
。这对我来说更有意义。所以我踏上了寻找肯定的旅程,很快,我意识到 docker.yml
无处不在。我一直在写docker-compose.yml
文件,而你一直在 kubernetes 的文档中看到 kubectl apply -f *.yaml
......
因此,总而言之,这两种格式显然都被接受,如果您在另一端(即:编写接收 YAML 文件作为输入的系统),您应该同时允许这两种格式。这似乎是另一个蛇案与骆驼案的对比……