文件名中的键值对有标准的文件命名约定吗？

Question

我有多个数据文件，它们以它们包含的内容命名。例如

machine-testM_pid-1234_key1-value1.log

键和值之间用 - 和 _ 分隔。有更好的语法吗？是否有解析器可以自动读取这些类型的文件/文件名？

这里的想法是文件名是人类并且机器可读的。

Answer 1

8年后...

我建议您查看https://en.wikipedia.org/wiki/Query_string

它们不是漂亮的文件名，但您不必重新发明轮子，例如转换为 dict/json，因为有经过充分测试的方法来解析查询字符串，例如在 requests 库中。

在 https://unix.stackexchange.com/questions/44153/good-style-practices-for-separators-in-file-or-directory-names 也有一个相关问题，其中包含一些有用的信息包含一些更好的视觉分隔符的想法（

_-_

和

___

），在这种情况下可能会更好

Answer 2

键值似乎没有标准文件命名约定。

Answer 3

问题

由于 Windows (NT)、macOS (Darwin) 和 Linux 中当前对文件名的限制非常重要，大多数可用选项都无法运行。

举个例子：

YAML 和 JSON 需要冒号，而 Windows 禁止使用冒号。
此外，单纯的字符串数据每行不能容纳多个键。

解决方案

我确定的唯一可读、可解析的选项是 PowerShell HashTable 语法。考虑下面提到的目录名称示例：

@{Statuses='Uncommenced'; Names=@{Full='Royal Air Force'; Acronyms='RAF'}; Identifiers='skr43i'}

基本原理

所包含的字符在 Windows、macOS 或 Linux 中均无效。它的特点如下：

1. @{}

   语法表示哈希表。

2. ;

    表示同一行上的新值。

根据我选择的定制功能包括以下功能：

理想情况下，每个 inode 都应包含一个

Identifiers
1. 键及其关联值，以便当

   Name

    更改时，可以轻松找到目录的旧路径并进行追溯修改，而无需记住旧的 

   Name

    值。 

   从技术上讲，如果 inode 没有跨越任何文件系统边界，那么这在日志文件系统中是不必要的，但无论如何它显然都是有用的。

   目录 inode 的
.dir
2. 以文件的标准方式传达其 MIME 类型。这并不是独一无二的 -

   VMS 在操作系统级别使用此技术

   。

   开头的
3. 会将文件名与以

   .

    为前缀的其他文件名对齐，并且当被某些 Windows 应用程序（如资源管理器，尽管它对 NTFS 和 Win32 API 都有效）剥离时，就会消失。 

   这些都是多余的，并且在除 Linux 之外的任何系统上偶尔都会出现问题。

我所知道的具有相当严格语法的

Answer 4

文件的最基本类型是：

.properties

主要用于java配置文件，它们允许注释
• .env
主要用于unix、systemd-service 环境文件，它们允许注释
• .ini
主要用于 c#、python...应用程序，它们允许注释并且
• [sections] 也 （不过，您可以混合并仍然使用它们，这只是我的经验，开发人员如何根据库等命名他们的东西）

还有更多的

语法略有不同

，例如

.json

文件和/或语法
• "key":"value" .yaml
文件和/或语法
• key: "value" .xml
文件和/或语法
• <key>value</key>

  基于应用程序的自定义内容也可以是 key=value，但不必...寻找诸如 

  .cfg
、
• .conf 、 .config 、 .preferences、 .settings 之类的东西，... 希望有帮助。