Windows создать ссылку пробел в имени директории

Обновлено: 07.07.2024

Члены большинства типов в пространстве имен 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 заключается в том, что пользователи и разработчики, имеющие дело с другими операционными системами, могут сталкиваться с проблемами из-за того, что в именах каталогов и путях не учитывается регистр символов. Это значит, что в именах каталогов и файлов сохраняется регистр строк, используемый в момент их создания. Например, вызов метода

В средах командной строки, таких как командная строка Windows и PowerShell, пробелы используются для разделения команд и аргументов, но имена файлов и папок также могут содержать пробелы. Чтобы указать путь к файлу имеющего символ пробела в названии или пути к файлу, вам нужно «экранировать» его.

Почему нужно избегать символ пробела?

«Пробел» в названии файла или папки, может препятствовать правильной обработке команды, экранирование пробела заставит оболочку рассматривать его как стандартный пробел, а не как специальный символ, разделяющий аргументы командной строки.

Например, предположим, что у вас есть текстовый файл, содержимое которого вы хотите просмотреть. Вы можете сделать это с помощью команды type. Предполагая, что текстовый файл находится по адресу C:\Папка\File.txt, следующая команда в командной строке покажет содержимое файла:

Отлично! А что, если у вас есть такой же файл по адресу C:\Новая папка\File.txt? Если вы попробуете выполнить приведенную ниже команду, это не сработает - пробелы в пути к файлу мешают правильно обработать команду.

Командная строка считает, что вы пытаетесь найти файл с именем Новая, в результате вы получаете: «Ошибка во время обработки: C:\Новая.
Системе не удается найти указанный путь.». Тоже самое будет? если пробел есть в имени файла New File.txt

Ошибка командной строки при отсутствии экранирования пробелов

Три способа избежать ошибок из-за символа пробел в Windows 10

Есть три разных способа избежать проблем используя пробел в пути к файлу Windows:

  1. Заключив путь (или его части) в двойные кавычки ( ” ).
  2. Добавляя символ вставки ( ^ ) перед каждым пробелом. (Это работает только в командной строке / CMD.)
  3. Добавляя знак ударения ( ` ) перед каждым пробелом. (Это работает только в PowerShell.)

Мы покажем вам, как использовать каждый из перечисленных способов.

Заключите путь к файлу в кавычки (")

Стандартный способ убедиться, что Windows правильно обрабатывает путь к файлу, - заключить его в двойные кавычки " . Например, в нашем примере команды выше мы просто выполняем следующее:

Вы можете заключить части пути в кавычки, если хотите. Например, предположим, что у вас есть файл с именем File.txt в этой папке. Вы можете запустить следующее:

Однако в этом нет необходимости - в большинстве случаев вы можете просто заключить весь путь в кавычки.

Это решение работает как в традиционной среде командной строки (CMD), так и в Windows PowerShell.

Заключение пробелов в двойные кавычки в командной строке

Иногда: используйте символ каретки для правильной обработки пробелов (^)

В командной строке символ каретки ^ теоретически позволяет избежать пробелов. Просто добавьте его перед каждым пробелом в имени файла. (Вы найдете этот символ в числовом ряду на клавиатуре. Чтобы ввести символ каретки, нажмите Shift + 6 .)

Вот проблема: хотя это должно работать, а иногда и работает, это работает не всегда. Командная строка обрабатывает этот символ странно.

Например, запустите следующую команду, но она не сработает:

Ошибка экранирования пробела в командной строке

С другой стороны, если мы попытаемся открыть наш файл напрямую, введя его путь в командную строку, мы увидим, что символ каретки правильно экранирует пробелы:

Экранирование пробела каретки работает в командной строке

Итак, когда это работает? Что ж, исходя из нашего исследования, похоже, что с некоторыми приложениями он работает, а с другими - нет. Это может варьироваться в зависимости от команды, которую вы используете. Командная строка обрабатывает этот символ странно. Если вам интересно, попробуйте с любой командой, которую вы используете, - она ​​может работать, а может и не работать.

Мы рекомендуем использовать двойные кавычки в командной строке или переключиться на PowerShell и использовать способ, рассмотренный ниже.

PowerShell: используйте символ ударения (`)

PowerShell использует знак ударения ` в качестве символа-пробела. Просто добавьте его перед каждым пробелом в имени файла. (Вы найдете этот символ над клавишей Tab и под клавишей Esc на клавиатуре.)

Каждый знак ударения сообщает PowerShell, что нужно избегать следующего символа.

Каждый знак ударения сообщает PowerShell, что нужно избегать следующего символа.

Обратите внимание, что это работает только в среде PowerShell. В командной строке вам нужно будет использовать символ каретки.

Если вы знакомы с UNIX-подобными операционными системами, такими как Linux и macOS, вы, возможно, привыкли использовать символ обратной косой черты ( \ ) перед пробелом, чтобы правильно обработать команду. Windows использует его для пути к файлам, поэтому он не работает - символы каретки ( ^ ) и ударения ( ` ) это своего рода обратная косая черта Windows в зависимости от того, какую оболочку вы используете.

Я пытался создать символическую ссылку, используя следующую команду:

Как создать ссылку, не убирая пробел в имени папки?

Я ищу способ сделать это в терминале, а не в пользовательском интерфейсе Finder.

Хотя Гордон Дэвиссон прав, вы должны знать, что псевдонимы и символические ссылки (символические ссылки) разные. ln -s делает символические ссылки. Искатель делает псевдонимы. Они практически идентичны в практическом, обычном использовании, но важно признать, что они разные . Символьные ссылки указывают на путь к каталогу, а псевдонимы указывают на файл. Если вы оба указали на один и тот же файл и переместите файл в другую папку, а затем создайте новый файл в старой папке, псевдоним будет указывать на перемещенный оригинал, а символическая ссылка будет указывать на новый файл. @ Cajun: спасибо за разъяснения. Это сбивает с толку тот факт, что искатель отображает свойство «Вид» символической ссылки как «Псевдоним». Завершение табуляции также замечательно, если вы сделаете это: ln -s

/Foo<tab> (где <tab> обозначает фактическую клавишу tab (табуляции) на вашей клавиатуре), если есть только одна папка, которая начинается с «Foo»,

тогда она будет автоматически расширить путь к

Кавычки не могут

быть расширены до вашей домашней папки, поэтому вам нужно либо заключить в кавычки только часть с пробелом в ней:

Примечание: сколько именно указано в кавычках, не имеет значения, если пробел находится в указанной части, а

/Fo"o B"ar/ т.д., все эквивалентны. Кроме того, одинарные и двойные кавычки одинаково влияют на пробелы (хотя они различаются для других символов), поэтому

/Foo' 'Bar/ т. Д. Также будут работать.

Вы также можете использовать escape, чтобы не использовать пространство как разделитель:

Вы можете серьезно процитировать просто пространство? Это потрясающе! @wchargin Это сработает. Обратите внимание, что в отличие от

, $HOME должны быть в двойных кавычках, чтобы избежать путаницы, если ваш домашний каталог содержит пробелы или другие странные символы. "$HOME/Foo Bar/" (как вы предлагаете) "$HOME"/Foo" "Bar/ , "$HOME"/Foo\ Bar/ и т. д. будет работать.

Я проверял это сам. У меня нет проблем с пробелом в нем:

ls показывает: $ linkToFoo_Bar -> /Users/joe/test/foo bar/ и работает без проблем в терминале и поиске.

Символьная ссылка (также симлинк от англ. Symbolic link, символическая ссылка) — специальный файл в файловой системе, для которого не формируются никакие данные, кроме одной текстовой строки с указателем. Эта строка трактуется как путь к файлу, который должен быть открыт при попытке обратиться к данной ссылке (файлу). Символьная ссылка занимает ровно столько места в файловой системе, сколько требуется для записи её содержимого (нормальный файл занимает как минимум один блок раздела).

Создать символьную ссылку очень просто и сейчас я вам это докажу. Открываем командную строку, нажимаем Win+R, вводим cmd и жмём ОК. Хотя если вы собираетесь работать с системными файлами, может понадобиться командная строка с правами администратора.

Создать символьную ссылку очень просто и сейчас я вам это докажу. Открываем командную строку, нажимаем Win+R, вводим cmd и жмём ОК.

Дальше нам нужно ввести команду для создания символьной ссылки, выглядит она следующем образом:

где /j — атрибут создания соединения для каталога. Если вы создаете ссылку на файл, атрибут ставить не надо.

К примеру, если я хочу создать символьную ссылку на папку mklink на локальном диске E, как папку mk на диске С, мне нужно ввести следующую команду (и да, символьная ссылка может называться не так, как исходный файл (папка):

002

В результате мы получим вот это.

003

Если же мы хотим создать символьную ссылку на файл, например на файл 1.txt, хранящийся в корне диска E. для использования в виде файла 2.txt. скажем в папке mslink на диске C, команда будет выглядеть вот так:

004

А на выходе получим вот это.

005

Резюмируя скажу, что знание возможностей данной функции, открывает большие возможности. С помощью неё я выходил из нескольких ситуаций, когда не хватало свободного пространства, на моем старом SSD, позволяя быстро перенести игру из папки origin на другой диск. Но вариантов использования её гораздо больше, к примеру перенос кэша браузеров, о котором мы поговорим в одной из будущих статей.

Вроде всё. Надеюсь эта статья оказалась вам полезной, обязательно нажмите одну из кнопок ниже, чтобы рассказать о ней друзьям. Также подпишитесь на обновления сайта, введя свой e-mail в поле справа или подписавшись на группу во Вконтакте и канал YouTube.
Спасибо за внимание

Читайте также: