是。yaml还是。yml?

文件扩展名的性质甚至存在是平台相关的(记住，一些不知名的平台甚至没有它们)——在其他系统中，它们只是常规的(UNIX及其同类)，而在其他系统中，它们有明确的语义，在某些情况下，它们对长度或字符内容有特定的限制(Windows等)。

因为维护者已经要求您使用”。yaml”，这是你能得到的最接近“官方”的裁决，但8.3的习惯很难摆脱(而且，令人震惊的是，在2013年仍然偶尔相关)。

编辑:

那我该用哪一种呢?是创作者建议的适当的4个字母扩展名，还是在互联网的狂野西部找到的3个字母扩展名?

这个问题可以是:

1. 征询意见的请求;或

2. 当一个人看到某些官方的建议被明显地、甚至主要地忽视时，他所经历的那种特定情感的自然表达。

人们在以下方面的偏好是不同的:

1. 官方的建议;或

2. 实践的优势。

当然，我不太可能影响你，这两条路你更愿意选择哪一条!

在接下来的内容中(并且，本着科学的精神)，我只是做一个假设，关于是什么(仅仅作为事实)导致大多数人使用3个字母的扩展名。并且，我关注有效的原因。

这样说，我并不是要做道德上的规劝。你可能还记得，事物存在的事实并不意味着它应该存在。

不管你个人的倾向是什么，是走这条路还是那条路，我都不反对。

(编辑结束。)

建议，这种偏好(在现实生活中使用)是由8.3字符DOS-ish限制引起的，IMO是红鲱鱼(错误和误导)。

截至2016年8月，YML和YAML的谷歌搜索量约为6,000,000和4,100,000(精确到两位数)。此外，“YAML”的数量高得不公平，因为它包括了语言的名字，而不仅仅是作为扩展使用。

截至2018年7月，谷歌对YML和YAML的搜索计数大约是8100000年和4100000年(同样是两位数的精度)。所以，在过去的两年里，YML的受欢迎程度基本上翻了一番，但YAML仍然保持不变。

另一个文化指标是试图解释文件扩展名的网站。例如，在FilExt网站上(截至2018年7月)，YAML页面的结果是:"Ooops!FILEXT.com数据库没有任何关于文件扩展名为。yaml的信息。”

然而，它有一个YML的条目，它给出:"YAML…使用文本文件，并将其组织成人类可读的格式。的数据库。yml’是Ruby on Rails使用YAML连接数据库的典型例子。”

截至2014年11月，维基百科关于扩展YML的文章仍然声明“。yml”是“YAML文件格式的的文件扩展名”(强调添加)。它的YAML文章列出了这两个扩展名，但没有表达偏好。

分机”。Yml”足够清晰，更简短(因此更容易输入和识别)，而且更常见。

当然，这两个扩展名都可以看作是一个可能的长扩展名“. yamlaintmarkupllanguage”的缩写。但是程序员(和用户)不希望输入所有这些!

相反，我们程序员(和用户)希望尽可能少地输入，并且仍然明确和清楚。我们想要看到它是什么样的文件，越快越好，不需要读一个更长的单词。输入多少字符可以同时实现这两个目标?答案不是三(3)吗?换句话说，YML?

维基百科的类别:Filename_extensions页面列出了。， . 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的创造者说.yaml，但我个人一直在做.yml。这对我更有意义。所以我踏上了寻找肯定的旅程，很快，我意识到docker在任何地方都使用.yml。我一直在写docker-compose.yml文件，而你一直在kubernetes的文档中看到kubectl apply -f *.yaml…

所以，总之，这两种格式都可以接受很明显，如果你在另一端，(即:编写接收YAML文件作为输入的系统)，你应该允许这两种格式。这看起来像是另一个蛇案和骆驼案……

.yaml显然是官方扩展，因为一些应用程序在使用.yml时失败。另一方面，我不熟悉任何使用YAML代码的应用程序，但使用.yaml扩展失败。

我只是偶然发现了这个，因为我习惯在Ansible和Docker Compose中编写.yml。出于习惯，我在写Netplan文件时使用.yml静默失败。我终于意识到我的错误了。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这样的配置也会无声地失败，没有任何有意义的反馈。