在文件命名中不使用大写字母是否被认为是最佳做法？

Question

在文件命名中不使用大写字母是否被认为是最佳做法？

人们说你不应该在 Unix 文件命名中使用空格。是否有充分的理由不在文件名中使用大写字母（即File_Name.txtvs. file_name.txt）？或者这只是个人喜好问题？

Answer 1

人们说你不应该在 Unix 文件命名中使用空格。

人们说了很多事情。有一些工具可能会出错，但希望此时它们的数量很少，因为空间是一种由大型消费者专有操作系统公司扩散的病毒，现在无法避免。

空格使在命令行上指定文件名等变得笨拙。就是这样。*nix 系统上唯一明确禁止的字符是 NUL（别担心，它不在您的键盘或其他任何人的键盘上）和/，因为这是路径分隔符。¹ 除此之外什么都没有。单个路径元素（文件名）被限制为 255个字节（如果您使用扩展字符集，可能会出现复杂情况）和 4 KiB 的完整路径。

或者这只是个人喜好问题

我会说是的。大多数 DE 似乎在您的$HOME( Downloads, Desktop, Documents--D非常流行) 中创建了大量大写的目录，因此没有什么奇怪的。还有非常常见的带有大写字母的传统文件，例如.Xclients和.Xauthority。

开始时将事物大写的一个价值是，当按字典顺序列出时，它们将出现在小写的事物之前——至少，对于许多工具，并且受语言环境的影响。

我是驼峰命名法（又名驼峰命名法）的粉丝，并将它与文件名一起使用，例如/home/goldilocks/blueSuedeShoes——不管里面有什么。绝对是个人喜好的问题，但它尚未引起我的悲伤。

Java 类文件本质上倾向于包含大写字母，因为 Java 类名包含大写字母。当然，我们不要忘记NetworkManager，即使我们中的一些人更愿意这样做。

^{1.有一个更加分隔，通过POSIX推荐“移植文件名字符集”是不包括空间-但它确实包含大写！ POSIX还在同一文档的其他地方指定了关于“斜杠字符和空字节”的更一般的限制。这反映或反映在长期的传统做法中。}

米娅：“这是事实吗？” 文森特：“不，不是，这只是我听说的。” 米娅：“这是谁告诉你的？” 文森特：“他们。” 米娅：“他们话很多，不是吗？” 文森特：“他们当然会。” (7认同)
“开头大写的 _value_ 是当按字典顺序列出 [...] 时，它们将排在其他所有内容之前。”-当然，这仅在 _most_ 文件名是小写时才有效，这给了你_reserve_大写的理由（至少 _leading_ caps) 用于你的 `README`s 和 `Makefile`s 等等。 (5认同)
在许多键盘上，ctrl-space 或 ctrl-@ 或 alt-0 将键入 NUL。 (4认同)
只是不要在文件名和目录名中使用空格。即使您的系统在技术上允许它，它也只会引起您的悲伤。而是使用“_”作为下划线字符。 (4认同)
@dodgethesteamroller 我相信您完全误解了 ext* 中的正斜杠（或更准确地说，值为 0x2F 的 *byte*）。事实上，我不相信它甚至会到达文件系统。无论后备存储如何，VFS 层都将禁止它。 (2认同)

Answer 2

Dmi*_*yev 10

避免在文件名中使用大写字母的原因之一是 Unix 中的排序顺序区分大小写，因此以大写字母开头的文件将出现乱序。这就是为什么Makefile通常使用大写字母命名的原因M- 它是您想要首先查看的文件之一，而无需滚动/跳过低谷a-l.

这就是说，你可以在文件名方面做得更糟：

使用空格会破坏一些写得不好的程序和脚本，这些程序和脚本没有正确引用文件名
以 a 开头的文件名-可能会导致问题，因为许多程序会将其视为命令行选项而不是文件名（例如，rm -r不会删除名为的文件-r）。
以 a 开头的文件名将.在许多实用程序和 shell globbing 中隐藏它（例如rm *不会删除诸如.config）
使用特殊字符|<>*?甚至不可打印字符newline在技术上是可行的，但可能会破坏类似于空格字符的脚本/程序。不同之处在于空格字符经常被使用，所以程序员倾向于用它来测试他们的程序，而不太流行的字符通常没有经过测试。

这不再是真实的，现代语言环境中的排序现在往往不区分大小写，并且许多工具和 shell globbings 尊重用于排序文件名的语言环境。 (4认同)
你的意思是说：`rm *` 不会删除像 `.config` 这样的文件吗？ (2认同)

Answer 3

小智 6

如果您要与 Windows 环境交互，则应避免使用大写字母，因为 Windows 会将所有内容小写。这通常是相反的问题；一个链接Page_2.html会page_2.html在 Windows 中找到，但在 Unix 中会失败。

这不是真的。NTFS、VFAT 和 exFAT 都是不区分大小写但保留大小写的，这意味着它们出于查找目的*忽略*大小写，但仍然*存储*大小写。这同样适用于 HFS+，OSX 上的默认文件系统。NTFS 甚至有一个 POSIX 命名空间，它*完全*像所有其他 Unices 一样工作，即未解释的八位字节的非常长的文件名，只有“NUL”和“/”被禁止。 (12认同)
更重要的是，“不区分大小写但保留大小写”是另一种说法“能够静默覆盖文件 A，因为它的名称仅在大小写与文件 B 不同”（反之亦然，取决于稍后保存的文件）。换句话说，如果您使用 \*nix shell 访问 NTFS 共享，`cat > Foo` 将覆盖文件 `foo`。如果您习惯于保留大小写的 _and_ 区分大小写的文件系统（例如 ext\*），则此行为可能会出乎意料且令人困惑。 (5认同)

Answer 4

G-M*_*ca' 5

由于 NL_Derek 打开了这堆蠕虫，但没有正确阐明它，\n我会这样说：

\n\n

使用大写字母是可以的，但您应该避免创建仅大小写不同的文件\n（在同一目录中），\ne.g.File_Name.txt 和 file_name.txt，因为

\n\n
\n
如果您以某种方式使该目录可供 Windows 系统使用，\n将无法访问这两个文件。\xc2\xa0\n它可能只能访问\n目录中第一个出现的文件，\n无论是哪个您使用的名称。\xc2\xa0\n（例外：它可以让您访问它们，并键入FILENA~1.TXT\ FILENA~2.TXTn\xe2\x80\x94dir /x来查看哪个短名称（如果有）与哪个长名称搭配。）
\n
如果文件系统实际上是 Windows 文件系统\n（例如，从 exFAT 或 NTFS 文件系统\n从运行 Windows 的 NFS 服务器安装），\n这两个名称将（可能）不允许共存。\xc2\xa0 \n例如，如果您执行\nand ，您最终可能会得到一个文件，其中包含的输出。cmd₁ > foocmd₂ > Foocmd₂
\n
同样，如果您曾经转移到 Windows 系统，\n这两个名称（可能）将不允许共存。\xc2\xa0\n例如，如果您创建了包含这两个文件的存档（例如 zip）， \n并在 Windows 系统上提取它，\n第二个文件可能会覆盖第一个文件。\xc2\xa0 同样的情况\n如果您使用 FTP 或类似工具将它们传输到 Windows 机器。
\n
\n

归档时间：	9 年，10 月前
查看次数：	37134 次
最近记录：	9 年，10 月前