GetInvalidFileNameChars() 不包含所有非法字符

Question

根据http://msdn.microsoft.com/en-us/library/system.io.path.getinvalidpathchars%28v=vs.110%29.aspx，Path.GetInvalidFileNameChars()应该会返回以下内容。

// Note: Some characters may not be displayable on the console. 
// The output will look something like: 
// 
// The following characters are invalid in a path: 
// Char    Hex Value 
// ",      0022 
// <,      003C 
// >,      003E 
// |,      007C 
// ... 
// 
// The following characters are invalid in a filename: 
// Char    Hex Value 
// ",      0022 
// <,      003C 
// >,      003E 
// |,      007C 
// ...

然而我只得到

Char    Hex Value
,   0000
/,  002F

http://ideone.com/UdRbCC

发生了什么？

- Snæbjørn

---

这取决于环境。这就是推迟将此任务硬编码到基于您的机器上的代码中并将其委托给库函数的全部原因。显然，运行该代码的机器具有相当自由的文件名/路径限制。 - Servy

“输出看起来会 有点儿 像…” 的意思就是字面上的意思。同一页还提到“无效字符的完整集合可能因文件系统而异”。 - Paul Roub

我有一种感觉，这可能取决于环境。然而，如果我剥离无效字符（从Path.GetInvalidFileNameChars()）并执行Path.GetExtension(Filename)，它仍会抛出无效字符异常。让我很难过！ - Snæbjørn

Answer 1

从你提供的文章中：

该方法返回的数组不能保证包含文件和目录名称中所有无效字符的完整集合。无效字符的完整集合可以因文件系统而异。例如，在基于 Windows 的桌面平台上，无效路径字符可能包括 ASCII/Unicode 字符 1 到 31，以及引号 (")，小于 (<)，大于 (>)，管道 (|)，退格 (\b)，空字符 (\0) 和制表符 (\t)。

- pquest

---

“vary by file system” 部分很重要。仅仅因为一个字符在平台本身方面是有效的，并不意味着在每个挂载的文件系统中它都是有效的。更有趣的是，情况也可能反过来，文件系统可以允许更多字符，超过了平台所支持的范围，因此您可能无法处理包含无效字符的文件。 - CodesInChaos