虽然唯一非法的Unix字符可能是/和NULL，但应该考虑到命令行解释。

例如，虽然在Unix中将文件命名为1>&2或2>&1是合法的，但在命令行中使用这样的文件名可能会被误解。

类似地，也可以将文件命名为$PATH，但当试图从命令行访问它时，shell将把$PATH转换为其变量值。

在Unix shell中，您几乎可以用单引号引用每个字符。除了单引号本身之外，您不能表示控制字符，因为\没有展开。从带引号的字符串中访问单引号本身是可能的，因为您可以用单引号和双引号连接字符串，如'I' ' ' ' 'm'，它可以用于访问名为"I'm"的文件(这里也可以使用双引号)。

因此应该避免所有控制字符，因为它们很难在shell中输入。其余部分仍然很有趣，特别是以破折号开头的文件，因为大多数命令将这些文件视为选项，除非您在前面有两个破折号，或者您使用./指定它们，这也隐藏了开头的-。

如果你想要更好，不要使用shell和典型命令使用的任何字符作为语法元素，有时依赖于位置，例如，你仍然可以使用-，但不能作为第一个字符;与.相同，只有当你想要使用它(“隐藏文件”)时，你才能将它作为第一个字符。如果您是恶意的，您的文件名是VT100转义序列;-)，因此ls会使输出乱码。

禁止文件名字符的“全面指南”在Windows上不起作用，因为它保留了文件名和字符。是的，像这样的角色 *”?还有一些名字是禁止使用的，但是有无数个名字是只由有效字符组成的，是禁止使用的。例如，空格和点是有效的文件名字符，但仅由这些字符组成的名称是禁止的。

Windows不区分大写字母和小写字母，因此如果已经存在名为a的文件夹，则不能创建名为a的文件夹。更糟糕的是，像PRN和CON这样看似允许的名字，以及许多其他的名字，是被保留和不允许的。Windows也有一些长度限制;在一个文件夹中有效的文件名如果移到另一个文件夹中可能会失效。的规则 命名文件和文件夹 都在微软文档里。

一般来说，不能使用用户生成的文本创建Windows目录名。如果您希望允许用户任意命名，则必须创建安全的名称，如A、AB、A2等，将用户生成的名称及其等效路径存储在应用程序数据文件中，并在应用程序中执行路径映射。

如果您绝对必须允许用户生成文件夹名，那么判断它们是否无效的唯一方法是捕获异常并假定名称无效。即使这样也充满了危险，因为为拒绝访问、脱机驱动器和驱动器空间外抛出的异常与为无效名称抛出的异常重叠。你正在打开一个巨大的伤害罐。

在Windows中创建internet快捷方式时，为了创建文件名，它会跳过非法字符，除了正斜杠被转换为减号。

您可以使用白名单，而不是创建字符黑名单。考虑到所有因素，在文件或目录名称上下文中有意义的字符范围非常短，除非您有一些非常特定的命名要求，否则如果用户不能使用整个ASCII表，他们不会反对您的应用程序。

它不能解决目标文件系统中保留名称的问题，但是使用白名单可以更容易地降低源上的风险。

本着这种精神，这是一个可以被认为是安全的字符范围:

字母(a-z a-z) -如果需要，也可以使用Unicode字符 数字(0 - 9) 下划线(_) 连字符(-) 空间 点号(.)

以及您希望允许的任何其他安全字符。除此之外，您还必须执行一些关于空格和点的附加规则。这通常就足够了:

名称必须包含至少一个字母或数字(以避免只有点/空格) 名称必须以字母或数字开头(以避免前导点/空格) 名称不能以点或空格结尾(如果存在，只需修剪它们，就像资源管理器一样)

这已经允许相当复杂和无意义的名称。例如，在这些规则下，这些名称是可能的，并且在Windows/Linux中是有效的文件名:

一个 ........... ext B -。- - - - - - ext

从本质上讲，即使白名单上的角色很少，你仍然应该决定什么是真正有意义的，并相应地验证/调整名称。在我的一个应用程序中，我使用了与上面相同的规则，但去掉了任何重复的点和空格。

好吧，如果只是为了研究目的，那么你最好的选择是看看维基百科上关于文件名的条目。

如果您想编写一个可移植的函数来验证用户输入并基于此创建文件名，简单的回答是不要。看一看像Perl的File::Spec这样的可移植模块，了解一下完成这样一个“简单”任务所需的所有跳转。