为什么File.OpenRead（）将相对路径附加到可执行文件？

Question

为什么同时使用以下代码

string filePath = @"‪C:\test\upload.pdf"
FileStream fs = File.OpenRead(filePath);

引发以下异常？

The filename, directory name, or volume label syntax is incorrect : 
'C:\ConsoleApp\bin\Debug\netcoreapp2.1\‪‪C:\test\upload.pdf'

C:\\ConsoleApp\\bin\\Debug\\netcoreapp2.1\\‪‪目录从何而来？

更新：就我而言， File.OpenRead()存在于dll中，并且通过使用该dll的应用程序发送filePath （‪ C:\\test\\upload.pdf ）。

Answer 1

该字符串以不可见的字符开头，因此不是有效路径。 这个

(int)@"‪C:\test\upload.pdf"[0]

退货

8234

或六角202A 。 这就是从左向右嵌入的标点符号

更新

雷蒙·陈（Raymond Chen）发表了一篇文章， 为什么我的文件名开头没有隐藏的U + 202A？ 。

我们前段时间看到，作为最后的选择，您可以插入字符U + 202B（从右向左嵌入）以强制将文本解释为从右至左。 相反的字符是U + 202A（从左向右嵌入），它强制将文本解释为从左到右。

“安全性”对话框会在文件名字段中插入该控制字符，以确保以预期的方式解释路径组件 。 不幸的是，这还意味着，如果您尝试将文本复制到对话框外，则会附带Unicode格式控制字符。 由于角色通常是不可见的，因此可以造成各种无声的混乱。

（我们很幸运，记事本和命令提示符很快就检测到了混乱。但是，请想象一下，您是否已将该路径粘贴到了C语言的源代码中！）

自该文章发表以来的4年中，记事本获得了UTF8支持，因此该字符不会被问号代替。 粘贴到具有不完整的UTF8支持的当前Windows控制台中仍会替换该字符。

Answer 2

就我而言，File.OpenRead（）存在于dll中。

在存在File.OpenRead的dll的属性中设置CopyLocal = true。