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而不是试图强制执行firstlast单独(这使我非常生气)。或者,当我遇到任何的比其他密码限制最小长度。(“不允许有空格吗?!?出于什么尘世原因!?”)显然,在某些情况下,这比其他情况更合适。有时,出于完全有效的原因,您必须让用户指定实际的文件名。
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.