是 .yaml 还是 .yml？

Question

根据yaml.org，官方文件扩展名为.yaml。

引用：

YAML 文件有官方扩展名吗？

请尽可能使用“.yaml”。

但是，互联网上似乎存在使用哪个扩展的分歧。如果您查找examples on the web，他们中的许多人使用未经批准的.yml 扩展名。

用 Google 搜索返回的结果是较短的结果的近 3 倍。

---

49,100

---

15,400

---

那么我应该使用哪个？创建者建议的正确的 4 个字母扩展名，还是在互联网的狂野西部发现的 3 个字母扩展名？

Answer 1

文件扩展名的性质甚至存在是依赖于平台的（一些晦涩的平台甚至没有，记住）——在其他系统中它们只是传统的（UNIX 及其同类），而在其他系统中它们有明确的语义，在某些情况下对长度或字符内容（Windows 等）有特定的限制。

由于维护人员要求您使用“.yaml”，这与您可以得到的“官方”裁决一样接近，但8.3 的习惯很难摆脱（而且，令人震惊的是，仍然偶尔2013 年相关）。

Answer 2

编辑：

那么我应该使用哪个？创建者建议的正确的 4 字母扩展名，还是在互联网狂野西部发现的 3 个字母扩展名？

这个问题可能是：

1. 征求意见；或

2. 当人们观察到某些官方建议被忽视时——明显地，甚至主要地，这种特定情绪的自然表达。

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

1. 官方建议；或

2. 实践的优势。

当然，我不太可能影响你，你更喜欢这两条路中的哪一条！

在接下来的内容中（并且，本着科学的精神），我只是提出一个假设，关于是什么（仅作为事实）导致大多数人使用 3 字母扩展名。而且，我关注efficient causes.

由此，我无意进行道德劝告。您可能还记得，the fact that something is, does not imply that it should be.

无论你的个人倾向如何，无论是走哪条路，我都不反对。

（编辑结束。）

建议，这种偏好（在现实生活中使用）是由 8.3 个字符的 DOS 限制引起的，IMO 是 red herring（错误和误导）。

截至 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' 是 YAML 的典型示例Ruby on Rails 使用它来连接数据库。”

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

扩展名“.yml”足够清晰，更简短（因此更容易输入和识别），并且更常见。

当然，这两个扩展名都可以看作是一个很长的可能的扩展名“.yamlaintmarkuplanguage”的缩写。但是程序员（和用户）不想输入所有这些！

相反，我们程序员（和用户）希望尽可能少地打字，但仍要清晰明了。我们希望尽快查看它是什么类型的文件，而无需阅读更长的单词。输入多少个字符可以实现这两个目标？答案不是三（3）吗？也就是说，YML？

维基百科的Category:Filename_extensions 页面列出了.a、.o 和.Z 的条目。不知何故，它错过了 .c 和 .h（由 C 语言使用）。这些单字母扩展名示例帮助我们了解扩展名应该尽可能长，但不能再长（半引用 Albert Einstein）。

相反，请注意，通常很少有扩展名以“Y”开头。另一方面，通常，字母 X 用于多种含义，包括“交叉”、“可扩展”、“极端”、“变量”等（例如在 XML 中）。所以以“Y”开头已经传达了很多信息（就信息论而言），而以“X”开头却没有。

因此，从语言上讲，首字母缩略词“XML”（在某种程度上）只有两个信息字母（“M”和“L”）。相反，“YML”具有三个信息性字母（“M”、“L”和“Y”）。事实上，现有的以 Y 开头的首字母缩略词集似乎非常少。言外之意，这就是为什么四字母 YAML 文件扩展名感觉被过度指定的原因。

也许这就是为什么我们在实践中看到将相关缩写词延长到四 (4) 个字符的“语言”压力（在自然使用中）很弱，而将这个缩写词缩短为三个 ( 3) 性格强。

可能纯粹是这些因素的结果（而不是作为官方认可），我会注意到YAML.org 网站的最新消息（从 2011 年 11 月开始）都是关于一个用 JavaScript 编写的项目，@ 987654335@，它本身在内部更喜欢使用扩展名“.yml”。

上述因素可能是主要因素；尽管如此，所有因素（已知或未知）都导致缩写的三 (3) 个字符扩展成为 YAML 的主要用途——尽管发明人偏好。

".YML" 似乎是事实上的 标准。然而，同样的发明者对世界对人类可读数据语言的需求具有洞察力和正确性。我们应该感谢他们提供它。

Answer 3

在网上阅读了一堆人的 cmets 后，我的第一反应是，这基本上是那些真正不重要的辩论之一。不过，我最初的兴趣是找出正确的格式，以便与我的文件命名习惯保持一致。

长话短说，YAML 的创建者说的是.yaml，但我个人一直在说.yml。这对我来说更有意义。所以我踏上了寻找肯定的旅程，很快，我意识到 docker 到处都在使用.yml。我一直在写 docker-compose.yml 文件，而你一直在 kubernetes 的文档中看到 kubectl apply -f *.yaml...

因此，总而言之，这两种格式显然都被接受，如果你在另一端，（即：编写接收 YAML 文件作为输入的系统）你应该同时允许这两种格式。这似乎是另一个蛇案与骆驼案……

Answer 4

.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 这样的配置也会在没有任何有意义的反馈的情况下静默失败。