在文件命名中不使用大写字母是否被视为最佳实践？

28

人们说您不应该在Unix文件命名中使用空格。是否有充分的理由不在文件名中使用大写字母（即，File_Name.txt vs file_name.txt）？还是只是个人喜好？

filenames

— DD343
source

您可以使用大写字母，但通常不使用大写字母。只需使用小写字母和_，这样file_name.txt就可以了。

— Shabir A.

9

在Unixy中，有些文件名使用大写字母...例如，Makefile，INSTALL，CHANGELOG，当然还有古老的README。

— 托马斯

PSR-2-PHP世界的事实上的命名标准，大多数在Linux上运行，使用的是camelCase php-fig.org/psr/psr-2

— jdog，2015年

46

人们说您不应在Unix文件命名中留空格。

人们说很多话。有一些工具可能会搞砸，但希望在当前时间点上它们的数量很少，因为空间是大型消费者专有操作系统公司繁殖的病毒，现在已经无法避免。

空格使在命令行等上指定文件名显得笨拙。就是这样 * nix系统上唯一被绝对禁止使用的字符是NUL（不用担心，它不在您的键盘上，也不在任何其他人的键盘上）和/，因为这是路径分隔符。¹ 除此之外，其他任何事情都不会发生。单个路径元素（文件名）限制为255 个字节（如果使用扩展字符集，可能会很复杂），并提供4 KiB的完整路径。

还是这只是个人喜好问题

我会说是的。大多数DE的似乎在创造资本目录的转换$HOME（Downloads，Desktop，Documents-将D是非常受欢迎的），所以没有什么奇怪的了。还有一些非常常见的带有大写字母的传统文件，例如.Xclients和.Xauthority。

一开始将事物大写的价值在于，按字典顺序列出时，它们将排在小写字母之前-至少使用许多工具并受地区限制。

我是骆驼保护套（也称为camelCase）的爱好者，并且将其与文件名一起使用，例如/home/goldilocks/blueSuedeShoes-不用担心里面有什么。绝对是个人喜好问题，但尚未使我感到悲伤。

Java类文件本质上倾向于包含大写字母，因为Java类名称确实如此。当然，NetworkManager即使我们中的某些人愿意，也不要忘记。

^{1. POSIX “ Portable Filename Character Set”建议使用更多分隔符，其中不包含空格-但包含大写字母！ POSIX还在同一文档的其他地方指定了有关“斜杠字符和空字节”的更一般的限制。这反映了长期的常规做法，或反映了这种做法。}

— 金发姑娘
source

5

米娅：“那是事实吗？” 文森特：“不，不是，这是我所听到的。” 米娅：“谁告诉你的？” 文森特：“他们。” 米娅：“他们说话很多吗？” 文森特：“他们当然会。”

— corsiKa

4

“ 一开始大写的价值是，按字典顺序[…]列出时，它们会排在其他所有字符之前。” —当然，这仅在大多数文件名都为小写时才有效，这给您保留大写字母的理由（至少领先的上限）为您的READMES和MakefileS和等。

— Blacklight Shining 2015年

4

在许多键盘上，ctrl-space或ctrl- @或alt-0都会键入NUL。

— dubiousjim 2015年

2

@dodgethesteamroller我相信您对于ext *中的正斜杠（或更确切地说，值为0x2F 的字节）完全误解了。实际上，我什至认为它甚至不会进入文件系统。无论后备存储如何，VFS层都将不允许它。

— zwol 2015年

3

只是不要在文件名和目录名中使用空格。即使您的系统在技术上允许它，也只会引起您的悲伤。而是使用下划线字符“ _”。

— SnakeDoc

9

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

也就是说，就文件名而言，您可能做得更糟：

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

— 德米特里·格里戈里耶夫（Dmitry Grigoryev）
source

4

这不再是正确的，如今现代语言环境中的排序通常不区分大小写，并且许多工具和外壳程序都使用语言环境来对文件名进行排序。

— 斯特凡Chazelas

2

您是rm *不是要说：不会删除类似文件.config？

— 2015年

1

@Wildcard不是真的，但是也许您的例子比我的更现实。我的观点是要证明，即使用户明确指定了点，以点开头的文件名也不会受到干扰。

— 德米特里·格里戈里耶夫

1

@DmitryGrigoryev，不，不是。在任何具有点文件的目录中尝试ls -ald。?? *。

— 比尔·巴特

1

我相信说“如果选择在文件名中使用大写字母，则应该记住一个事实，即Unix中的排序顺序有时是区分大小写的”。用户可能想要这种行为，Makefile并且README是这种行为的完美示例。还请注意，如果字母不是名称中的第一个字母，则这种影响可以忽略不计，因此，如果您使用camelCase，则影响不大。当然，你可能会惊奇地发现anOctagon之前angle，但至少他们会一起上市。

— G-Man说'恢复莫妮卡'

6

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

— NL_Derek
source

10

这不是真的。NTFS，VFAT和exFAT都不区分大小写，但保留大小写，这意味着它们出于查找目的会忽略大小写，但是仍然存储大小写。同样的情况适用于OSX上的默认文件系统HFS +。NTFS甚至具有一个POSIX命名空间，该命名空间的工作方式与所有其他Unices 完全相同，即，非常长的未解释八位字节的文件名，只有NUL且被/禁止。

— 约尔格W¯¯米塔格

5

更重要的是，“不区分大小写但保留大小写”是另一种说法，“因为文件名仅与文件B有所不同，因此能够静默覆盖文件A”（反之亦然，取决于以后保存的文件）。换句话说，如果您使用* nix shell访问NTFS共享，cat > Foo则会覆盖file foo。如果您习惯于保留大小写且区分大小写的文件系统（例如ext *），则此行为可能是意外的并且令人困惑。

— dodgethesteamroller 2015年

1

@JörgWMittag除非我没有记错，否则NTFS 并不区分大小写，只是Windows以一种神秘的方式工作。

— 克苏鲁2015年

1

@Cthulhu：AFAIK，NTFS具有四个不同的名称空间，您可以在其中创建文件名。（不过，我不知道单个文件是否可以在多个名称空间中使用名称。）一个“ DOS”名称空间（8.3，不区分大小写），一个“长”名称空间（不区分大小写，保留大小写， UTF-16），一个特殊的名称空间，用于“短长名称”，即应保留大小写但适合8.3的名称，以及POSIX名称空间（除了\0and /，区分大小写的八位字节流）。至少那是我记得的方式。但是我同意这有点混乱。有在...进一步的限制

— 约尔格W¯¯米塔格

1

…内核，甚至API中的更多限制（实际上，来自不同时代的不同API都有不同的限制），由于与DOS和FAT的兼容性而存在限制，命令解释器中存在限制，（中有限制图形）外壳程序，并且Explorer中有一些限制。而且它往往无法可靠地确定其中一个限制是从哪里来的。这很疯狂。我曾经设法使用Explorer创建文件，但使用我尝试使用的任何工具都无法打开，复制，移动，重命名或删除该文件。它基本上留在...

— 约尔格W¯¯米塔格

4

避免使用上限的原因之一是bashs的制表符区分大小写（至少在默认情况下是区分大小写的）– 每当我使用默认配置结束时，这仍然使我感到困惑bash。当然，还有其他流行的Shell，但这与bash许多操作系统上的默认登录Shell 结合在一起，意味着默认值通常区分大小写。使用全小写的文件名在此简化了事情。

— 黑光闪耀
source

2

echo set completion-ignore-case On >> ~/.inputrc至少在您自己的系统上可以有所帮助。

— wchargin

1

我不清楚这个答案的意义是什么，除非您可能会忘记如何“拼写”文件名。例如，如果您创建一个名为的文件，Foo然后再键入cat f（Tab），它将失败。但是，如果您键入cat foo，cat Foobar或cat Fu-遇到访问名称不正确的文件的麻烦，这实际上与自动完成没有任何关系。

— G-Man说“恢复莫妮卡”

@ G-ManTouché。不过，使用全小写的文件名意味着您要记住的少一件事。

— Blacklight Shining

3

由于NL_Derek打开了这罐蠕虫，但没有正确表达，因此我将这样说：

可以使用大写字母，但应避免创建仅按大小写不同的文件（在同一目录中），例如File_Name.txt 和 file_name.txt，因为

如果您以某种方式使该目录可用于Windows系统，它将无法访问这两个文件。无论您使用哪个名称，它都将只能访问目录中最先出现的那个。（除了：可能会以FILENA~1.TXT和方式使您访问它们FILENA~2.TXT -键入dir /x以查看短名称（如果有）与长名称一起使用。）
如果文件系统实际上是Windows文件系统（例如，从运行Windows的NFS服务器的exFAT或NTFS文件系统安装），则（可能）这两个名称将不能共存。例如，如果您执行和，则可能最终得到一个包含的输出的文件。cmd₁ > foocmd₂ > Foocmd₂
同样，如果您曾经将文件传输到Windows系统，则这两个名称（可能）将不允许共存。例如，如果您创建了包含两个文件的存档（例如zip），并将其解压缩到Windows系统上，则第二个文件可能会覆盖第一个文件。如果将它们传输到带有FTP或类似内容的Windows机器上，也是一样。

— G-Man说“恢复莫妮卡”
source

不只是Windows，还有其他几个操作系统（我认为VMS，当然还有CP / M，其他...）

— Toby Speight 2015年

3

除了技术原因外，我对此还有实际的看法。坚持使用小写字母将确保搜索更加容易，除非一个人太喜欢使用grep -i或定位-i。有时，如果必须像存储NYCDCPrimary中那样使用一串类似大小写的单词，即使是camelCase也会造成混淆。因此，我发现最好坚持小写字母，并在其下加上下划线或连字符以提高可读性，例如storage_nyc_dc_primary。

— 跳兔
source

snake_case在眼睛上很容易- storageNycDcPrimary而且StorageNycDcPrimary都很奇怪。

— go2null

1

我确实考虑 最好的方法是避免在文件名中使用大写和空格。

有人会说他们不同意，但这是一个问题或我所说的宗教信仰：很难讨论和达成共识。那些不同意的人说，现在大多数工具都固定为对首都和太空友好：它们是正确的，但这不是问题。

正确的问题是，文件名中需要使用大写和空格。对于这个问题，除了我用Java编程时，答案通常都是无时无刻：我的文件名不需要大写和空格。我用下划线（_）或减号（-）代替的所有空格，因此，我不使用驼峰式大小写（亦称camelCase），这与某些其他宗教信仰相反。

许多人称我为胡说八道是因为他们这样做并教导他们-有些人仍然这样做-有些人绊倒了一个对资本/空间不友好的工具，向我说我是对的，他们应该听我的话。 做任何您想做的事情，并且如果您在文件名中使用大写和空格，我希望您永远不会使用写得不好的工具。但是，如果您希望再次使用该工具，将不会很困难，也不会花费您的业务和/或大量金钱和/或时间。但是，如果最终结果不佳，您会记住，过去有人告诉过您，在文件名中使用大写字母和空格是不好的做法。

最后一件事，如果要避免所有问题，则文件名中不应包含特殊字符（仅小写字母，数字，下划线和减号[1]）。此有害字符列表还包括所有非ascii字符（是，法语和其他非英语的人-我是其中的一个-都不是à，â，ä，ç，é，...，ö，æ，œ ，...）。这还扩展到许多其他方面，包括login和password。我将让您猜测当您在登录名或密码中加上引号或双引号（'或"）时会发生什么情况，该登录名或密码由bash脚本处理，而不是由经确认的sysadmin编写。

[1]：也许我们可以扩大，为~，@，#和其他一些人，但这是自找麻烦（是的，我知道emacs的文件...）。

— f
source

1

最后一件事是验证系统应该处理的事情，而不是用户输入密码的事情。如果系统限制了密码中允许的字符集，那么这是一个错误的系统。

— Blacklight Shining 2015年

好吧，限制密码中的字符是一个有争议的话题：li1，oO0，...取决于喜欢的，难以交流的人。有人会说不应传递密码，但是WiFi密钥是一种当我在朋友家时与我交流的密码...

— jfg956

这是在有意识地选择你的一部分，以避免使用某些字符，而不是限制内置到系统中（在这个例子中，Wi-Fi标准，AP和客户端实现，等等）。如果您使用一串随机选择的字符作为密码，则可以通过使用（或鼓励收件人使用）等宽字体来提高可读性，或者如果要手写它们，则只需使用更具特色的字形即可（小写的小写字母） L，大写字母I和数字1；小写小写字母O，更圆的大写字母O（斜线或虚线数字0；等等）。或者，您可以使用密码短语。

— Blacklight Shining