Unix文件名应限制哪些字符?


71

考虑一个带有自由文本条目的另存为对话框,在该对话框中,用户以自由文本形式输入文件名,然后单击“保存”按钮。然后,软件将验证文件名,如果文件名有效,则将其保存。

在Unix文件系统上,应在验证中应用哪些规则,例如:

  • 该名称以后在转义特殊字符等方面将不难操作。
  • 规则不是太严格,以至于保存文件变得对用户不友好。

因此,基本上,应该从Unix文件名中限制的最小字符集是什么?

Answers:


60

的最小是斜线( '/')和NULL( '\ 0')


1
最小值为/,; 和 为了避免用户运行任意命令(假设它没有被转义:))
— workmad3

3
这个。除“ /”外,不得使用其他字符。
— 没人在2009年

3
和ASCII NUL'\ 0',因为这标志着文件名的结尾:D
— Jonathan Leffler

5
这是严格的答案。应将应用程序编码为假定用户不受限制(因此,在打开文件时,它应接受任何名称)。保存(新)文件不是一个很好的答案。对文件名设置一些限制是合理的。
— 乔纳森·莱夫勒

@mouviciel:像like这样的某些文件系统支持ɴᴜʟʟ字符。如果文件名中间出现ɴᴜʟʟ字符会发生什么情况。
— user2284570

40

首先,您要描述的是黑名单。更好的选择是将字符列入白名单,因为从用户角度看,插入字符比删除字符更容易。

关于在UNIX环境中会是什么好:

  • z
  • AZ
  • 0-9
  • 下划线(_)
  • 破折号(-)
  • 期间(.)

应该涵盖您的基础知识。空格可以,但是会使事情变得困难。Windows用户喜欢它们,而Unix / Linux则不喜欢。因此,根据您的目标受众进行相应选择。


2
换行符很麻烦。逗号非常无害。在Unix中,冒号不会造成任何损害,但是如果将名称复制到Windows或“文件”是可能需要添加到PATH的目录,则会出现问题。
— 乔纳森·莱夫勒

2
有一些争论的地方是,在当前语言环境中任何被分类为'isalpha()'的字符都可以-允许人们在名称中使用带重音符号的字符。但是,这使故事复杂化了。
— 乔纳森·莱夫勒

28
我会认为任何可能将带重音符号的字符视为用户不友好的词

4
使用不同语言的文件名会怎样?
— 库特希尔·阿特奇博士(Dr. Koutheir Attouchi)

23

尽管公认的答案可能有道理,但我认为对脚本或其他内容进行一些限制可能会带来好处:

  • 正斜杠(/)
  • 反斜杠(\)
  • NULL(\ 0)
  • 勾号(`)
  • 以破折号(-)开头
  • 星号(*)
  • 管道(|)
  • 分号(;)
  • 引号(“或”)
  • 冒号(:)

(-也许是空格,尽管我不愿意添加。)

如您所见,按照@Gavin的建议,您最好将其列入白名单...


这是一个很好的清单。我也建议排除“!” 但是,以交互方式键入时可能会用于历史记录扩展。哦,还有前导句点(隐藏)和“ <”或“>”(重定向)。
— 史蒂夫·乔根森

并且要记住,在Unix中,文件名中仍然可能在空格,制表符和换行符之间运行。您的代码不应仅仅因为看到它而崩溃。
— Randal Schwartz

22

经常被遗忘:冒号(:)不是一个好主意,因为它通常用在$ PATH之类的东西中,即“自动”找到可执行文件的目录列表。这可能会导致与DOS / Windows目录名称混淆,当然在驱动器名称中使用冒号。


如果有冒号,在linux上的ldd也可能会困惑寻找rpath
— Jon

如果文件名中有一个冒号,并且在Windows上使用该分区并删除了该文件,则将导致文件系统损坏。不过,可以使用Windows的“修复磁盘”工具来解决。
— Kenji

11

不要忘记,您可以.在开头添加一个点()以隐藏文件和文件夹...否则,我将遵循* NIX名称约定(来自Wikipedia):

大多数UNIX文件系统

  • 案例处理:区分大小写的案例保存
  • 允许的字符集:任意。
  • 保留字符:/,null。
  • 长度上限:255。
  • 备注:领先。指示ls和文件管理器默认情况下将不显示文件

链接到有关文件名的维基百科文章


8

编码FTW

正如Bombe在回答中指出的那样,限制用户输入至少不会令人烦恼,这是令人沮丧的。但是,作为开发人员,我们应该假定与我们的代码的每次交互都是恶意的,并将其视为恶意代码。

为了解决实际应用中的两个问题,而不是将某些字符列入白名单或黑名单,我们不应该简单地将用户输入用作文件名。

取而代之的是,使用[a-f0-9]我们自己设计的安全名称(仅十六进制字符,以确保最终安全),该名称是通过用户输入(例如PHP的bin2hex)编码的,或者是随机生成的ID(例如PHP的uniqid),然后通过某种方法进行映射(例如您的选择)。

编码/解码可以在不依赖映射的情况下即时完成,因此实际上是理想的。用户永远不需要知道文件的真正名称。只要他们能够获取/设置文件,并且文件似乎像他们想要的那样,每个人都是赢家。

通过这种方法,用户可以调用它们的文件为所欲为,黑客将是唯一的人感到沮丧,你的文件系统会爱你:-)


1
极好的建议!这与存储名称的原理相同name而不是试图强制执行first和last单独(这使我非常生气)。或者,当我遇到任何的比其他密码限制最小长度。(“不允许有空格吗?!?出于什么尘世原因!?”)显然,在某些情况下,这比其他情况更合适。有时,出于完全有效的原因,您必须让用户指定实际的文件名。
— DaveGauer

-4

让用户输入他想要的任何名称。人为地限制字符范围只会使用户烦恼,并且没有真正的目的。


9
或者,更好的方法是:'$(rm -fr $ HOME)'(减去单引号)作为文件名?这将早日造成严重破坏。反引号和$(...)特别引人注目,因为在引用文件名时它们会“工作”,这与大多数其他特殊字符不同。嵌入式引号也很棘手。
— 乔纳森·莱夫勒

7
保存文件名时,这些都是非问题。fopen()不在乎您的文件名。使用图形外壳(例如konqueror)时,它并不关心您的文件名。当您在外壳中使用自动完成功能时,它并不在乎您的文件名。那么您的观点是什么?:)
— 孟买

3
@Bombe,在许多情况下一个用户可能想要的东西都会疏远其他用户,而不管它对您的UI开发过程造成的破坏如何。馊主意。
— dkretz

9
这就是我的观点:选择陌生的名字不会对任何事情造成破坏,除非您的“任何东西”写得不好。没有UNIX的标准工具写得不好。再说一遍:你有什么意思?
— 孟买

3
一个真正应该更了解的人的短视答案。您的答案甚至无法正确回答原始问题。他们说The name will not be difficult to manipulate later in terms of escaping special characters, etc.。人们在这里指出,有效文件名中可以包含许多字符,但实际上会引起很多问题。
— JamEngulfer 2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.