GetInvalidFileNameChars（）不包含所有非法字符

根据http://msdn.microsoft.com/en-us/library/system.io.path.getinvalidpathchars%28v=vs.110%29.aspxPath.GetInvalidFileNameChars()应该提供以下输出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

什么继续？

来源

2014-12-02 Snæbjørn

这取决于环境。这就是全部的原因推迟此任务的库函数，而不是硬编码它的基础上显然，运行该代码的机器具有相当宽松的文件名/路径限制 – Servy 2014-12-02 15:49:15

“输出看起来像* ...的东西*”意味着它说什么，相同的页面也注意到“全套无效字符可以因文件系统而异。“ – 2014-12-02 15:49:44

我有一种感觉它可能取决于环境。然而，如果我去掉无效字符（从'Path.GetInvalidFileNameChars（）'）并执行'Path.GetExtension（Filename）'，它仍会抛出无效字符异常。让我成为一只伤心的熊猫！ – 2014-12-02 16:02:34

从你链接的文章：

数组此方法返回不能保证包含一套完整的文件和目录名称中的无效字符。全套无效字符可能因文件系统而异。例如，对于示例，在基于Windows的桌面平台上，无效路径字符可能包含ASCII/Unicode字符1到31以及引号（“），小于（<），大于（>），管道（|），退格（\ b）中，空（\ 0）和标签（\ t）。

来源

2014-12-02 15:49:55 pquest

“根据文件系统而异”部分很重要。就平台本身而言，字符的有效性并不意味着它在每个安装的文件系统中都是有效的。为了获得额外的乐趣，它也可以是相反的方式，文件系统可以允许比平台更多的字符，因此您可能无法使用包含无效字符的文件。 – CodesInChaos 2014-12-02 16:43:30

GetInvalidFileNameChars（）不包含所有非法字符

回答

相关问题