是。yaml还是。yml?

编辑:

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

这个问题可以是:

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

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

官方的建议;或实践的优势。

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

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

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

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

(编辑结束。)

这种偏好(在现实生活中使用)是由8.3字符dos限制引起的，在我看来是转移注意力(错误和误导)。

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

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

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

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

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

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

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

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

维基百科的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扩展名失败的应用程序。

我只是偶然发现了这个，因为我习惯在Ansible和Docker Compose中编写.yml。出于习惯，我在编写Netplan文件时使用.yml，它会无声地失败。我终于意识到我的错误了。Netplan的一个流行Ansible Galaxy角色的作者在他的代码中做出了同样的假设:

- name: Capturing Existing Configurations
  find:
    paths: /etc/netplan
    patterns: "*.yml,*.yaml"
  register: _netplan_configs

然而，Netplan会像忽略扩展名为.bak的文件一样忽略任何扩展名为.yml的文件。由于Netplan非常安静，在成功时没有任何反馈，即使使用Netplan apply -debug，配置如01-netcfg。Yml将在没有任何有意义的反馈的情况下默默失败。

在网上看了很多人对此的评论后，我的第一反应是，这基本上是一个非常不重要的辩论。然而，我最初的兴趣是找出正确的格式，这样我就可以与我的文件命名实践保持一致。

长话短说，YAML的创造者说。YAML，但我个人一直在用。yml。这对我来说更有意义。所以我开始了寻找肯定的旅程，很快，我意识到docker在任何地方都使用。yml。我一直在写码头式写作。当你一直在kubernetes的文档中看到kubectl apply -f *.yaml…

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