Можно ли в ос windows при записи адреса файла использовать прямой слэш как разделитель
Обновлено: 04.07.2024
Мне нужно создать файл с именем файла, например :>? , возможно ли это как-то? Windows это останавливает.
У каждого ограниченного символа есть другое значение или использование, поэтому, если имя файла или папки действительно содержит их, это может привести к возникновению Bad Things ™. Не возражаете, если я спрошу, почему вы пытаетесь это сделать? @ DMA57361, когда я делал это несколько лет назад, я проверял некоторые вещи. Если я правильно помню, результаты были забавными, но я не помню ничего особенно плохого . Самое большее, я просто не мог получить к ним доступ. (Хотя я полагаю, что это может вызвать проблемы, если, например, у вас есть файлы с именами a , b и вы a>b type a>b @moorecast, когда я делал это несколько лет назад, я создавал файлы / каталоги с фиктивными именами, а затем использовал редактор дисков, чтобы вручную устанавливать имена в записях каталога. Конечно, это было на томе FAT32, так что это было очень легко. Это было бы немного сложнее на томе NTFS. Mind if I ask why you are trying to do this? Может быть, реализовать (плохую) защиту от копирования ? «Мне нужно создать файл с именем файла, например:>?» - Сомневаюсь, что тебе нужно это сделать.К сожалению, вы не можете использовать зарезервированные символы при создании папок или файлов, поскольку они являются частью системных функций.
То, что я рекомендую вам сделать, это просмотреть Character Map приложение - вы можете запустить и набрать charmap .
отсюда вы можете найти альтернативные символы, которые выглядят одинаково, например:
(скопируйте и вставьте их, вы увидите, что они разные)
Вместо косой черты / - вы можете использовать символ деления ∕
Вместо двоеточия : - вы можете использовать модификатор буквы двоеточия ꞉
Вы можете загрузиться с диска Linux (например, Knoppix ) и смонтировать раздел NTFS.
Linux имеет гораздо меньше ограничений на имена файлов, и позволит вам создавать такие имена (я пробовал).
Некоторые операционные системы запрещают отображение определенных символов в именах файлов: (Ресурс из Википедии )
\ backslash Также используется как разделитель компонентов имени пути в MS-DOS, OS / 2 и Windows (нет разницы между косой чертой и обратной косой чертой); разрешено в Unix имени файла
? знак вопроса, используемый в качестве подстановочного знака в Unix, Windows и AmigaOS; отмечает один символ Разрешено в Unix имена файлов
* звездочка используется в качестве подстановочного знака в Unix, MS-DOS, RT-11, VMS и Windows. Отмечает любую последовательность символов (Unix, Windows, более поздние версии MS-DOS) или любую последовательность символов в базовом имени или расширении (таким образом, « . » В ранних версиях MS-DOS означает «все файлы». Допускается в именах файлов Unix ,
: двоеточие используется для определения точки монтирования / диска в Windows; используется для определения виртуального устройства или физического устройства, такого как накопитель на AmigaOS, RT-11 и VMS; используется в качестве разделителя пути в классической Mac OS. Удваивается после имени в VMS, указывает имя узла DECnet (эквивалентно имени хоста NetBIOS (сеть Windows), которому предшествует "\".)
| вертикальная черта обозначает программную конвейеризацию в Unix и Windows; разрешено в именах файлов Unix
"кавычка используется для обозначения начала и конца имен файлов, содержащих пробелы в Windows
<меньше, чем используется для перенаправления ввода, разрешено в именах файлов Unix
> больше, чем используется для перенаправления вывода, разрешено в именах файлов Unix
, период разрешен, но последнее вхождение будет интерпретироваться как разделитель расширений в VMS, MS-DOS и Windows. В других ОС, обычно рассматриваемых как часть имени файла, допускается более одной полной остановки.
Члены большинства типов в пространстве имен System.IO имеют параметр path , который позволяет указать абсолютный или относительный путь к ресурсу в файловой системе. Этот путь передается в API файловой системы Windows. В этом разделе рассматриваются форматы путей к файлам, которые можно использовать в операционных системах Windows.
Традиционные пути DOS
Стандартный путь DOS может состоять из трех компонентов:
- Буква тома или диска, после которой следует разделитель томов ( : ).
- Имя каталога. Символ разделителя каталогов служит для разделения подкаталогов во внутренней иерархии каталога.
- Необязательное имя файла. Символ разделителя каталогов служит для разделения пути к файлу и его имени.
Если присутствуют все три компонента, путь является абсолютным. Если буква тома или диска не указана и имя каталога начинается с символа разделителя каталогов, такой путь задан относительно корня текущего диска. В противном случае путь задан относительно текущего каталога. В следующей таблице показаны некоторые возможные пути к каталогам и файлам.
| Путь | Описание: |
|---|---|
| C:\Documents\Newsletters\Summer2018.pdf | Абсолютный путь к файлу из корня диска C: . |
| \Program Files\Custom Utilities\StringFinder.exe | Абсолютный путь из корня текущего диска. |
| 2018\January.xlsx | Относительный путь к файлу в подкаталоге текущего каталога. |
| ..\Publications\TravelBrochure.pdf | Относительный путь к файлу в каталоге, который является одноранговым для текущего каталога. |
| C:\Projects\apilibrary\apilibrary.sln | Абсолютный путь к файлу из корня диска C: . |
| C:Projects\apilibrary\apilibrary.sln | Относительный путь из текущего каталога диска C: . |
Обратите внимание на различия между двумя последними путями. В обоих случаях задается необязательный описатель тома ( C: ), однако первый путь, в отличие от второго, начинается с корня указанного тома. В результате первый путь является абсолютным из корневого каталога диска C: , тогда как второй — относительным из текущего каталога C: . Использование второй формы пути в тех случаях, когда предполагается наличие первой, является распространенным источником ошибок, связанных с путями к файлам в Windows.
Чтобы определить, является ли путь к файлу полным (такой путь не зависит от текущего каталога и не изменяется при смене текущего каталога), можно вызвать метод Path.IsPathFullyQualified. Обратите внимание, что такой путь может включать сегменты с относительным путем к каталогу ( . и .. ), но при этом по-прежнему будет полным, если разрешенный путь всегда указывает на одно и то же место.
В приведенном ниже примере показано различие между абсолютными и относительными путями. Предполагается, что каталог D:\FY2018\ существует и вы не установили какой-либо текущий каталог для диска D:\ из командной строки перед запуском этого примера.
Если вы хотите увидеть комментарии к коду, переведенные на языки, отличные от английского, сообщите нам на странице обсуждения этой проблемы на сайте GitHub.
UNC-пути
UNC-пути (универсальное соглашение об именовании) используются для доступа к сетевым ресурсам и имеют следующий формат:
- Имя сервера или узла, которому предшествуют символы \\ . В качестве имени сервера может выступать имя компьютера NetBIOS, а также IP-адрес или полное доменное имя (поддерживаются адреса IPv4 и IPv6).
- Имя общего ресурса, которое отделяется от имени узла символами \ . Имя сервера и имя общего ресурса в совокупности образуют том.
- Имя каталога. Символ разделителя каталогов служит для разделения подкаталогов во внутренней иерархии каталога.
- Необязательное имя файла. Символ разделителя каталогов служит для разделения пути к файлу и его имени.
Ниже приводятся некоторые примеры UNC-путей:
| Path | Описание |
|---|---|
| \\system07\C$\ | Корневой каталог диска C: на компьютере system07 . |
| \\Server2\Share\Test\Foo.txt | Файл Foo.txt в тестовом каталоге тома \\Server2\Share . |
UNC-пути всегда должны быть полными. Они могут включать сегменты с относительным путем к каталогу ( . и .. ), однако они должны быть частью полного пути. Использовать относительные пути можно только посредством сопоставления UNC-пути с буквой диска.
Пути к устройствам DOS
В операционной системе Windows используется унифицированная объектная модель, которая указывает на все ресурсы, включая файлы. Эти пути к объектам доступны из окна консоли и предоставляются на уровень Win32 с использованием специальной папки с символьными ссылками, с которыми сопоставляются устаревшие пути DOS и UNC. Доступ к этой специальной папке осуществляется с использованием синтаксиса пути к устройству DOS, который может иметь одну из приведенных ниже форм:
Помимо использования буквы диска, вы можете указать том с помощью его GUID. Синтаксис будет иметь вид:
Путь к устройству DOS состоит из следующих компонентов:
Описатель пути к устройству ( \\.\ или \\?\ ), который идентифицирует путь как путь к устройству DOS.
Символьная ссылка на "реальный" объект устройства (C: в случае имени диска или Volume в случае GUID тома).
Первый сегмент пути к устройству DOS после описателя пути к устройству идентифицирует том или диск. (Например, \\?\C:\ и \\.\BootPartition\ .)
Для UNC-путей существует специальная ссылка, которая называется UNC . Пример:
Для UNC-путей к устройствам часть сервера или общего сетевого ресурса образует том. Например, в пути \\?\server1\e:\utilities\\filecomparer\ часть server1\utilities представляет сервер или общий сетевой ресурс. Это важно при вызове такого метода, как Path.GetFullPath(String, String) с сегментами с относительным путем к каталогу, поскольку переход дальше тома невозможен.
Пути к устройствами DOS по определению являются полными. Сегменты с относительным путем к каталогу ( . и .. ) в них не допускаются. Они никогда не задаются относительно текущего каталога.
Пример. Способы задать ссылку на один и тот же файл
В следующем примере демонстрируются некоторые способы задать ссылку на файл с использованием API в пространстве имен System.IO. В этом примере создается экземпляр объекта FileInfo и используются его свойства Name и Length, чтобы отобразить имя и длину файла.
Нормализация путей
Практически все передаваемые в API Windows пути нормализуются. При нормализации в Windows выполняются следующие действия:
- Идентифицируется путь.
- Текущий каталог применяется к неполным (относительным) путям.
- Выполняется канонизация разделителей каталогов.
- Вычисляются относительные компоненты каталога ( . для текущего и .. для родительского каталога).
- Удаляются некоторые символы.
Нормализация осуществляется неявно, но при необходимости вы можете выполнить ее явно, вызвав метод Path.GetFullPath, который создает оболочку для вызова функции GetFullPathName(). Также можно вызвать функцию GetFullPathName() Windows напрямую с помощью P/Invoke.
Идентификация пути
На первом шаге процесса нормализации осуществляется идентификация типа пути. Пути могут относиться к одной из нескольких категорий:
- Пути к устройствам: начинаются с двух разделителей и знака вопроса или точки ( \\? или \\. ).
- UNC-пути: начинаются с двух разделителей без знака вопроса или точки.
- Полные пути DOS: начинаются с буквы диска, разделителя томов и компонентов ( C:\ ).
- Пути к устаревшим устройствам ( CON , LPT1 ).
- Пути относительно корня текущего диска: начинаются с одного разделителя компонентов ( \ ).
- Пути относительно текущего каталога указанного диска: начинаются с буквы диска и разделителя томов, но не содержат разделителя компонентов ( C: ).
- Пути относительно текущего каталога: начинаются с любых других символов ( temp\testfile.txt ).
Тип пути определяет, будет ли каким-либо образом применяться текущий каталог. Кроме того, от типа пути зависит применяемый корень.
Работа с устаревшими устройствами
Если путь указывает на устаревшее устройство DOS, например CON , COM1 или LPT1 , он преобразуется в путь к устройству путем добавления перед ним последовательности \\.\ и возвращается в таком виде.
Путь, который начинается с имени устаревшего устройства, всегда интерпретируется как путь к устаревшему устройству с помощью метода Path.GetFullPath(String). Например, путь к устройству DOS CON.TXT будет выглядеть как \\.\CON , а путь к устройству DOS COM1.TXT\file1.txt будет выглядеть как \\.\COM1 .
Применение текущего каталога
Если путь не является полным, система Windows применяет к нему текущий каталог. К UNC-путям и путям к устройствам текущий каталог не применяется. Также текущий каталог не применяется к полным путям к диску с разделителем C:\ .
Если путь начинается с одного разделителя компонентов, применяется диск текущего каталога. Например, для пути к файлу \utilities и текущего каталога C:\temp\ в результате нормализации будет получен путь C:\utilities .
Если путь начинается с буквы диска, разделителя томов и не содержит разделителя компонентов, применяется последний текущий каталог, установленный из командной оболочки. Если последний текущий каталог не был установлен, применяется диск сам по себе. Например, для пути D:sources , текущего каталога C:\Documents\ и последнего текущего каталога D:\sources\ на диске D: в результате будет получен путь D:\sources\sources . Пути, задаваемые относительно диска, являются распространенными источниками ошибок программ и логики скрипта. Предположение, что путь, начинающийся с буквы и двоеточия, не является относительным, очевидно неверно.
Если путь не начинается с разделителя, применяются текущий диск и текущий каталог. Например, для пути к файлу filecompare и текущего каталога C:\utilities\ в результате будет получен путь C:\utilities\filecompare\ .
Канонизация разделителей
Все символы косой черты ( / ) преобразуются в стандартные разделители Windows, то есть символы обратной косой черты ( \ ). Если они присутствуют, последовательность символов косой черты после первых двух таких символов свертывается в один символ косой черты.
Вычисление относительных компонентов
При обработке пути выполняется вычисление любых его компонентов или сегментов, которые состоят из одной или двух точек ( . или .. ):
Если обнаруживается одна точка, текущий сегмент удаляется, поскольку он ссылается на текущий каталог.
Если обнаруживаются две точки, удаляются текущий и родительский сегмент, поскольку в этом случае задается ссылка на родительский каталог.
Родительские каталоги удаляются только в том случае, если они не находятся после корня пути. Корень пути зависит от его типа. Это будет диск ( C:\ ) для путей DOS, сервер или общий сетевой ресурс для UNC-путей ( \\Server\Share ) и префикс пути к устройству для путей к устройствам ( \\?\ или \\.\ ).
Удаление знаков
Помимо удаленных ранее разделителей и относительных сегментов во время нормализации также удаляются некоторые дополнительные знаки:
Если сегмент заканчивается одной точкой, эта точка удаляется. (Сегмент, состоящий из одной или двух точек, нормализуется на предыдущем шаге. Сегмент, состоящий из трех или более точек, не нормализуется и фактически представляет собой допустимое имя файла или каталога.)
Если путь не заканчивается разделителем, удаляются все конечные точки и пробелы (U+0020). Если последний сегмент содержит только одну или две точки, к нему применяется приведенное выше правило для относительных компонентов.
Это правило устанавливает, что вы можете создать имя каталога с конечным пробелом, добавив разделитель после пробела.
Создавать имена каталогов или файлов с конечным пробелом нельзя. Наличие конечных пробелов может затруднить или исключить возможность доступа к каталогу. В связи с этим при попытке обработать каталоги или файлы, имена которых содержат конечные пробелы, происходит сбой приложения.
Пропуск нормализации
Как правило, любой путь, передаваемый в API Windows передается в функцию GetFullPathName и нормализуется. Существует одно важное исключение: путь к устройству, который начинается со знака вопроса, а не с точки. Если путь не начинается с последовательности \\?\ (обратите внимание на использование канонической формы с обратной косой чертой), он нормализуется.
Зачем нужно пропускать нормализацию? Существует три основных причины:
Получение путей, которые в обычных обстоятельствах недоступны, но являются допустимыми. Например, невозможно каким-либо иным способом получить доступ к файлу или каталогу с именем hidden. .
Повышение производительности за счет пропуска нормализации в тех случаях, когда нормализация уже выполнена.
Пропуск нормализации и проверки максимальной длины пути является единственным отличием между двумя видами синтаксиса путей к устройствам. В остальных аспектах они идентичны. Пропуск нормализации следует использовать с осторожностью, поскольку в этом случае легко получить пути, при работе с которыми в обычных приложениях будут возникать трудности.
Пути, начинающиеся с последовательности \\?\ , по-прежнему нормализуются, если явно передать их в функцию GetFullPathName.
Вы можете передавать пути длиной более MAX_PATH символов в функцию GetFullPathName без \\?\ . Она поддерживает пути произвольной длины, которая ограничивается лишь максимальным размером строки, поддерживаемым в Windows.
Регистр символов и файловая система Windows
Особенность файловой системы Windows заключается в том, что пользователи и разработчики, имеющие дело с другими операционными системами, могут сталкиваться с проблемами из-за того, что в именах каталогов и путях не учитывается регистр символов. Это значит, что в именах каталогов и файлов сохраняется регистр строк, используемый в момент их создания. Например, вызов метода
Боб Бемер ввел обратный слеш (\) в набор символов ASCII, 18 сентября 1961 года, как результат изучения частоты использования символов встречающихся в частности в программах на ALGOL’е. Тогда же вместе с обратным слешем в стандарт были включены и квадратные скобки.
В частности \ был введен, чтобы булевы операторы ALGOL’a AND и OR могли быть представлены с помощью ASCII символов как "/\" и "\/" соответственно [3,4].
Как же вышло, что исторически православный слеш заменился на свое зеркальное отображение, введенное как вспомогательный символ специально для уже мертвого языка?
Русскоязычная Википедия по этому говорит вот что:
В операционных системах DOS и Windows фирмы Microsoft и их аналогах других разработчиков, обратная косая используется для разделений имён директорий (каталогов) при указании пути к файлу. Прямая косая, применяемая для этого в Unix не могла быть использована в MS-DOS, потому что уже была задействована для указания ключей командной строки (оставшегося в наследство от СР/M, где MS-DOS команда «dir /w» писалась как «dir/w») [5].
Так как такое объяснение меня не слишком удовлетворило, пришлось найти статью «Why is the DOS path character "\"?» [6], которая вполне утолила моё любопытство. Вольный перевод избранных частей в моем исполнении:
То что символ "/" конфликтовал с разделителем пути другой относительно популярной ОС не был связан напрямую с разработчиками – в конце концов, DOS не поддерживал директорий, просто файлы в одном корневом каталоге.
Для MS-DOS 2.0 (в котором появился поддержка каталогов), дизайнеры DOSа выбрали гибридную версию – у них уже были имена дисков в наследство от DOS 1.0, поэтому разработчикам пришлось их использовать. И в дополнение к именам дисков они решили использовать *nix-style метод определения иерархии каталогов — вместо использования каталога в имени файла (как это было сделано в VMS и DEC-20), они просто сделали каталог и имя файла неотъемлемыми частями пути. Но с этим была проблема. Невозможно было использовать разделитель пути *nix (/), по той причине что слэш уже использовался как разделитель ключей.
Что им было делать? Они конечно могли использовать "." как в DEC, но точка уже использовалась как разделитель между именем файла и расширением. Поэтому они выбрали наилучший вариант из оставшихся — символ "\", который был визуально похож на "/".Таким вот образом и был выбран символ "\" для разделения путей в DOS.
Кстати есть небольшой секрет про MS-DOS. Разработчики DOS не были довольны таким положением дел – они использовали Xenix [7] для почты и прочих вещей, поэтому они были знакомы со структурой *nix команд. Поэтому они добавили в ОС возможность принимать в качестве разделителя путей как "/" так и "\" (это работает и сегодня, кстати – попробуйте выполнить «notepad c:/boot.ini» под XP (если ваш пользователь имеет права админа)). Дальше — больше. Они добавили недокументированный системный вызов, чтобы изменить символ разделителя ключей. И обновили утилиты, чтобы те поддерживали этот флаг. Они даже добавили в config.sys параметр, SWITCHAR, который позволит пользователю установить разделитель ключей на "-". Таким образом можно было превратить MS-DOS в *nix-style ОС, используя "-switch", и пути с разделителем "/".
Собственно к чему это все?
Меня побудила разобраться в этой теме следующая ситуация.
Была поставлена задача — наладить систему отчетов для автоматизированных тестов. Тесты у нас используются двух видов – Selenium (функциональные) и Jmeter (нагрузочные). Собственно в этом не было ничего сложного — для этих целей существует вполне себе open-source проект под названием logging selenium [8] и plugin для maven — chronos [9]. Настроив всё и протестировав отчеты локально, принялся за интеграцию с нашей CI — TeamCity. Вот тут-то меня и ждала та самая неожиданность, которая стала поводом для написания этой статьи.
После выполнения всех тестов отчет о Selenium-тестах имел следующий вид:
Всё отлично отображалось, и никаких отличий от локальной версии не было.
Но вот отчет, который отобразился для Jmeter-тестов, воодушевления не вызывал:
Напрочь отсутствовали все изображения на странице.
После просмотра исходного кода страницы стало понятно, что во всем виноват backslash. Ссылки на изображения были указаны в таком формате:
Справедливости ради стоит заметить, что изображения отсутствовали в Firefox, но прекрасно отображались в IE. Хотя если бы IE не отображал ресурсы в URI которых встречается обратный слеш, как разделитель пути для Windows, то в, и не без того подпорченной, репутации индийских программистов образовалась бы еще одна брешь.
в чем основное различие между прямой косой чертой (/) и обратной косой чертой () в отношении путей, как удаленных, так и локальных?
Я хотел бы знать, является ли это точным объяснением или если разница на самом деле глубже, чем это, и примеры, которые я привел, просто случайны.
Unix и его варианты всегда использовали косую черту (/) для обозначения иерархии файловой системы.
тем не менее, Windows обязана своим разделителем файловой системы, обратной косой чертой ( \ ), своему предшественнику MS-DOS. И MS-DOS не была инициатором этого. Он был привезен из операционной системы QDOS (которая заимствована из CP/M), которую MS купила и переработала в MS-DOS.
Это не точное объяснение. Разделитель пути - это просто символ, маркер, который является несколько произвольным, но обычно выбирается для обозначения естественного разделения. Обратный Слэш как разделитель пути происходит из рода СР/M, DOS и Windows. Слэш приходит из Unix и, возможно, других систем до него.
разделитель URL-адресов Интернета был выбран в качестве косой черты, так как большинство разработчиков стандартов знакомы с Unix. В Unix Слэш как разделитель пути обычно считается каноническим сепаратором. Его положение на клавиатуре также облегчает ввод текста для большинства людей, которым приходится вводить его много.
даже кроссплатформенные языки сценариев, такие как Python, используют косую черту - "нормализованную форму" указания путей.
на уровне реализации windows будет обрабатывать ' / 'так же, как и'\'. Я бы просто использовал'/'. Это сделает все приложения портативными. MySQL и python также переводит " / " на то, что вам нужно в вашей системе, в зависимости от того, какой разделитель путей они используют.
' \ ' используется в других областях, таких как регулярные выражения, и некоторые терминалы и языки программирования в качестве escape-символа. Это гарантирует, что следующий символ после него будет интерпретирован как литерал символ, например \n \r в конце строк.
Что касается обозначения внутренних или внешних систем, то это не так. '/'Был более популярен на ранних этапах работы с системами *nix. Microsoft тогда стала популярной, и теперь " \ " - это то, что люди ожидают. Но, как я уже упоминал, Microsoft должна быть posix (posix-стандарт о том, как должны работать операционные системы) совместимым, что означает, что вы можете заменить все " \ " на " / " в большинстве мест, и каждая вещь будет работать проблемы.
Читайте также: