Почему File.OpenRead() добавляет относительный путь к исполняемому файлу?
Почему при использовании следующего кода
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, а filePath (C:\test\upload.pdf) отправляется через приложение, использующее dll.
нет необходимости. File.OpenRead — настолько фундаментальный вызов, что каждый разработчик .NET Core заметил бы проблему. Очевидно, что строка не является допустимым путем. Наиболее вероятной причиной могут быть недопустимые или невидимые символы или символы, похожие на : или \ .
Поместите курсор на " из "C:\. Нажмите вправо несколько раз. Что (странное) вы заметили? Если вы этого не заметите, попробуйте еще раз. Еще один способ обнаружить такого рода проблемы — проверить длину строки. При любом странном поведении строк проверьте их длину перед дальнейшим исследованием. Невидимые символы по своей природе трудно увидеть, но они влияют на длину.
Ответы 2
Строка начинается с невидимого символа, поэтому это недопустимый путь. Этот
(int)@"C:\test\upload.pdf"[0]
Возвращает
8234
Или шестнадцатеричный 202A. Это знак препинания ВНЕДРЕНИЕ СЛЕВА НАПРАВО
ОБНОВИТЬ
Рэймонд Чен опубликовал статью Почему в начале имени моего файла есть невидимая буква U+202A?.
We saw some time ago that you can, as a last resort, insert the character U+202B (RIGHT-TO-LEFT EMBEDDING) to force text to be interpreted as right-to-left. The converse character is U+202A (LEFT-TO-RIGHT EMBEDDING), which forces text to be interpreted as left-to-right.
The Security dialog box inserts that control character in the file name field in order to ensure that the path components are interpreted in the expected manner. Unfortunately, it also means that if you try to copy the text out of the dialog box, the Unicode formatting control character comes along for a ride. Since the character is normally invisible, it can create all sorts of silent confusion.
(We’re lucky that the confusion was quickly detected by Notepad and the command prompt. But imagine if you had pasted the path into the source code to a C program!)
Спустя 4 года после этой статьи Блокнот получил поддержку UTF8, поэтому символ не заменен знаком вопроса. Вставка в текущую консоль Windows с ее неполной поддержкой UTF8 по-прежнему заменяет символ.
@Bogdan Doicin: самый 1-й символ (ВСТАВКА СЛЕВА НАПРАВО, с кодом 0x202A), который является невидимый, неверен. Перепечатайте "C: фрагмент
@BogdanDoicin нет, я говорю, что нить неверен с самого начала. Где ты взял эту строку? Это пришло из текстового поля справа налево? Кто-то на самом деле Добавить символ там?
@PanagiotisKanavos Я бы искал целую вечность. Вот оно. Вы все описали выше. Я скопировал путь из свойств файла в windows
@OrElse вы найдете много вопросов ТАК, где проблема была вызвана невидимыми символами или странными комбинациями, такими как ... как один символ или, что еще хуже, , то есть запятая-пробел как один символ Unicode в файле CSV
File.OpenRead() в моем случае существует в dll.
Установите CopyLocal= true в свойствах dll, в которой существует File.OpenRead.
Ошибка не имеет ничего общего с существованием. File.OpenRead обрабатывает строку так, как будто это не путь. Любая другая функция будет делать то же самое, потому что это нет допустимый путь - он начинается с невидимого символа.
File.OpenReadничего подобного не делает. Сообщите код, который фактически воспроизводит проблему, и отправьте полный текст исключения, включая стек вызовов. Вы можете получить это легко сException.ToString()