loggingWindowspath中多个反斜杠的行为

显然,Windows(或者至lessWindows的某个部分)会忽略path中的多个反斜杠,并将它们视为单个反斜杠。 例如,从命令提示符或“运行”窗口执行这些命令中的任何一个都会打开记事本:

C:\Windows\System32\Notepad.exe C:\Windows\System32\\Notepad.exe C:\Windows\System32\\\Notepad.exe C:\Windows\System32\\\\Notepad.exe C:\\Windows\\System32\\Notepad.exe C:\\\Windows\\\System32\\\Notepad.exe 

这甚至可以使用在命令行上传递的参数:

 notepad "C:\Users\username\Desktop\\\\myfile.txt" 

这种行为logging在任何地方? 我尝试了几次search,只发现了这个问题,甚至提到了行为。

注意:我不是询问UNCpath(\\ servername),\\?\前缀或\\“双引号转义。

注意:我在处理batch file时偶然发现了这种行为。 batch file中的一行看起来像这样:

 "%SOME_PATH%\myapp.exe" 

variables扩展之后,命令如下所示:

 "C:\Program Files\Vendor\MyApp\\myapp.exe" 

令我惊讶的是,batch file按照需要执行,并没有失败,出现某种“找不到path”的错误。

Solutions Collecting From Web of "loggingWindowspath中多个反斜杠的行为"

在大多数情况下,Win32 API函数将接受路径名称格式中的各种变体,包括根据当前目录或每个驱动器当前目录将相对路径转换为绝对路径,将单个点解释为“此目录”和两个点作为“父目录”,将正斜杠转换为反斜杠,并删除多余的反斜杠和尾随句点。

所以像

 c:\documents\..\code.\\working\.\myprogram\\\runme.exe.. 

将结束解释为

 c:\code\working\myprogram\runme.exe 

其中一些是有记录的 ,有些则不是。 (正如汉斯所指出的那样,记录这种解决方法合法化的做法是错误的。)

请注意,这适用于Win32 API,不一定适用于每个应用程序,甚至每个系统组件。 特别是,命令解释器在处理长路径时有更严格的规则,Explorer不接受点或双点,通常不接受正斜杠。 此外,如果服务器未运行Windows,则网络驱动器的规则可能会有所不同。

没有任何结果,因为你甚至不能用反斜杠命名文件或文件夹。 所以多个连续的反斜杠总会被视为路径中的一个分隔符。