Можно ли в названии файла использовать пробел
Мне нужно создать файл с именем файла, например :>? , возможно ли это как-то? 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 .
отсюда вы можете найти альтернативные символы, которые выглядят одинаково, например:
(скопируйте и вставьте их, вы увидите, что они разные)
Вместо косой черты / - вы можете использовать символ деления ∕
Вместо двоеточия : - вы можете использовать модификатор буквы двоеточия ꞉
@Arjan - только через командную строку .. даже тогда вы можете использовать клавишу табуляции для автозаполнения.
Я использовал этот трюк для определенных ситуаций, например, когда мне нужно поставить вопрос в имени файла ( почему Microsoft оставил вопросительный знак зарезервированным? ఠ_ఠ) К сожалению, мне пришлось прекратить использовать любые символы не ASCII, потому что они вызывают проблемы с такими вещами, как программы дефрагментации, которые по какой-то причине кажутся неспособными перемещать файлы с символами Unicode в именах. ಠ ~ ಠ
Если подумать, этот ответ на самом деле тоже не отвечает на вопрос. Есть ответы ниже , что делать , так что это тоже должно быть просто комментарий.
Вы можете загрузиться с диска 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
, период разрешен, но последнее вхождение будет интерпретироваться как разделитель расширений в VMS, MS-DOS и Windows. В других ОС, обычно рассматриваемых как часть имени файла, допускается более одной полной остановки.
Все файловые системы, поддерживаемые Windows, используют концепцию файлов и каталогов для доступа к данным, хранящимся на диске или устройстве. Windows разработчики, работающие с API-интерфейсами Windows для операций ввода-вывода файлов и устройств, должны понимать различные правила, соглашения и ограничения имен файлов и каталогов.
Доступ к данным можно получить с дисков, устройств и сетевых ресурсов с помощью API-интерфейсов ввода-вывода файлов. Файлы и каталоги, наряду с пространствами имен, являются частью концепции пути, который представляет собой строковое представление места для получения данных независимо от того, находится ли он с диска или устройства или сетевого подключения для определенной операции.
Некоторые файловые системы, такие как NTFS, поддерживают связанные файлы и каталоги, которые также соответствуют соглашениям об именовании файлов и правилам так же, как обычный файл или каталог. Дополнительные сведения см. в разделе "Жесткие ссылки" и "Соединения" , " Точки повторного анализа" и "Операции с файлами".
Дополнительные сведения см. в следующих подразделах:
Дополнительные сведения о настройке Windows 10 для поддержки длинных путей к файлам см. в разделе "Ограничение максимальной длины пути".
4. Осмысленные названия на английском языке
Указывайте для файлов осмысленные названия на английском языке, избегайте названий «по умолчанию» (Новая папка 2) и использования транслита.
Когда пользователь собирается перейти по ссылке, он нередко обращает внимание на её адрес. Если имя страницы или файла описывает содержимое, пользователь охотнее перейдёт по ссылке.
Поисковые системы также учитывают название файла. Ссылка на ваш сайт, содержащая в названии ключевое слово, даёт поисковым системам понять, о чем ваша страница.
В этой статье описывается поддержка символов белого пространства в именах файлов и папок.
Применяется к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 2829981
Объект-менеджер
Символы ASCII Space (0x20) в начале или конце имени файла или папки удаляются объектным менеджером при создании.
Символы периода ASCII (0x2E) в конце файла или имени папки удаляются объектным менеджером при создании.
Все остальные ведущие или следящее символы белого пространства сохраняются объектным менеджером.
Пространства имен устройств Win32
Префикс "\\.\" будет обращаться к пространству имен устройства Win32 вместо пространства имен файлов Win32. Таким образом, доступ к физическим дискам и томам осуществляется напрямую без прохождения файловой системы, если API поддерживает этот тип доступа. Таким образом можно получить доступ к нескольким устройствам, кроме дисков (например, с помощью функций CreateFile и DefineDosDevice ).
Например, если вы хотите открыть последовательный порт связи системы 1, можно использовать com1 в вызове функции CreateFile . Это работает потому, что COM1–COM9 является частью зарезервированных имен в пространстве имен NT, хотя при использовании префикса "\\.\" также будут работать с этими именами устройств. Для сравнения, если установлена 100-последовательная плата расширения портов и вы хотите открыть COM56, ее нельзя открыть с помощью COM56, так как для COM56 нет предопределенного пространства имен NT. Его необходимо открыть с помощью "\\.\COM56", так как "\\\.\" переходит непосредственно в пространство имен устройства, не пытаясь найти предопределенный псевдоним.
Еще одним примером использования пространства имен устройства Win32 является использование функции CreateFile с "\\.\PhysicalDriveX" (где X является допустимым целым числом) или "\\.\CdRomX". Это позволяет обращаться к этим устройствам напрямую, обходя файловую систему. Это работает потому, что эти имена устройств создаются системой по мере перечисления этих устройств, а некоторые драйверы также создают другие псевдонимы в системе. Например, драйвер устройства, реализующий имя C:\. имеет собственное пространство имен, которое также может быть файловой системой.
ИНТЕРФЕЙСы API, которые проходят через функцию CreateFile , обычно работают с префиксом "\\.\", так как CreateFile — это функция, используемая для открытия файлов и устройств в зависимости от используемых параметров.
При работе с функциями API Windows следует использовать префикс "\\.\" для доступа только к устройствам, а не к файлам.
Большинство API не поддерживают "\\.\"; Распознаются только те, которые предназначены для работы с пространством имен устройства. Всегда проверяйте справочный раздел для каждого API, чтобы убедиться.
Переумерия API
Win32 API
API Win32(CreateFile, FindFirstFileи т. д.) использует прямой метод для переумерия файлов и папок в локальной или удаленной файловой системе. Все файлы и папки можно обнаружить независимо от включения или расположения символов whitespace.
WinRT API
API WinRT предназначен для поддержки нескольких поставщиков данных (Physical Drives, OneDrive, Facebook и т.д.). Для этого API WinRT использует поисковую машинку для переумерия файлов и папок. Из-за подхода к поиску к списку API WinRT(StorageFile, StorageFolderи т. д.) не обрабатывает имена файлов и папок с символами, относящемся к белому пространству, кроме ASCII Space (0x20) и ASCII Period (0x2E), проживающих в локальной или удаленной файловой системе. Он обрабатывает ведущие символы белого пространства, не относимые к ASCII.
Имена файлов и каталогов
Все файловые системы соответствуют одинаковым общим соглашениям об именовании для отдельного файла: базовому имени файла и необязательному расширению, разделенному точкой. Однако каждая файловая система, например NTFS, CDFS, exFAT, UDFS, FAT и FAT32, может иметь определенные и различные правила формирования отдельных компонентов в пути к каталогу или файлу. Обратите внимание, что каталог — это просто файл с особым атрибутом, назначающим его в качестве каталога, но в противном случае должен соответствовать всем тем же правилам именования, что и обычный файл. Так как каталог терминов просто относится к специальному типу файла, насколько это касается файловой системы, некоторые справочные материалы будут использовать общий файл терминов для охвата как концепций каталогов, так и файлов данных. Из-за этого, если не указано иное, любые правила именования или использования или примеры для файла также должны применяться к каталогу. Путь к термину относится к одному или нескольким каталогам, обратным косикам и, возможно, имени тома. Дополнительные сведения см. в разделе "Пути ".
Ограничения количества символов могут отличаться и могут отличаться в зависимости от используемого формата префикса имени файловой системы и пути. Это еще больше усложняется поддержкой механизмов обратной совместимости. Например, более старая файловая система MS-DOS FAT поддерживает не более 8 символов для имени базового файла и 3 символа для расширения в общей сложности 12 символов, включая разделитель точек. Это обычно называется именем файла 8.3. Windows файловых систем FAT и NTFS не ограничиваются именами файлов 8.3, так как они поддерживают длинные имена файлов, но по-прежнему поддерживают версию 8.3 длинных имен файлов.
Пространства имен
В api-интерфейсах Windows используются две основные категории соглашений о пространстве имен, которые обычно называются пространствами имен NT и пространствами имен Win32. Пространство имен NT было разработано для самого низкого уровня пространства имен, в котором могут существовать другие подсистемы и пространства имен, включая подсистему Win32 и, по расширению, пространства имен Win32. POSIX — это еще один пример подсистемы в Windows, построенной на основе пространства имен NT. Ранние версии Windows также определили несколько предопределенных или зарезервированных имен для определенных специальных устройств, таких как последовательные и параллельные порты, и консоль отображения по умолчанию в рамках того, что теперь называется пространством имен устройств NT, и по-прежнему поддерживаются в текущих версиях Windows для обратной совместимости.
Символы Whitespace
Существуют различные символы белого пространства, представляющие различные ширины пространства (глифы). Только символы asCII Space (0x20) и ASCII (0x24) обрабатываются специально объектным менеджером. Хотя символ Ideographic Space (0x3000) также создается с помощью пробела (когда включен IME), он не обрабатывается специально.
- 0x0020 SPACE
- 0x00A0 ПРОСТРАНСТВА БЕЗ ПЕРЕРЫВА
- 0x1680 OGHAM SPACE MARK
- 0x180E СЕПАРАТОР МОНГОЛЬСКИХ ГЛАСНЫХ
- 0x2000 EN QUAD
- 0x2001 EM QUAD
- 0x2002 EN SPACE
- 0x2003 EM SPACE
- 0x2004 ПРОСТРАНСТВА THREE-PER-EM
- 0x2005 ПРОСТРАНСТВА FOUR-PER-EM
- 0x2006 ПРОСТРАНСТВА SIX-PER-EM
- 0x2007 РИС ПРОСТРАНСТВА
- 0x2008 ПУНКТУАЦИИ
- 0x2009 ТОНКОЕ ПРОСТРАНСТВО
- 0x200A ПРОСТРАНСТВА ДЛЯ ВОЛОС
- 0x200B ПРОСТРАНСТВА НУЛЕВОЙ ШИРИНЫ
- 0X202F УЗКОЕ ПРОСТРАНСТВО БЕЗ ПЕРЕРЫВА
- 0X205F МАТЕМАТИЧЕСКОЕ ПРОСТРАНСТВО
- 0x3000 ИДЕОГРАФИЧЕСКОЕ ПРОСТРАНСТВО
- 0XFEFF НУЛЕВОЙ ШИРИНЫ БЕЗ ПЕРЕРЫВА ПРОСТРАНСТВА
Наблюдаемое поведение
Обозреватель файлов и настольные приложения
Все файлы и папки видны в приложениях File Explorer и Desktop независимо от включения или расположения символов белого пространства.
Microsoft Store приложения
При использовании выборщика файлов не отображаются файлы с символом, не относимым к белому пространству asCII. Содержимое подсобных ведомостей с символами, не относясь к белому пространству, не отображается в файлоподбирателье. Отображаются файлы или папки, содержащие ведущий символ белого пространства, не относящееся к ASCII.
Говорят, что в Unix и Linux в целом вы должны избегать пробелов в имени файла (обычный файл, dir, ссылка, файл устройства, . ).
Но я делаю это все время. Для имени файла с пробелом внутри
- В Nautilus символ пробела отображается как пробел.
- В терминале Bash я либо использую \ для представления пробела, либо заключаю имя файла в пару двойных кавычек.
- в файлах некоторых приложений (Наутилус, не уверен, будет ли это делать и ОС), имя файла записывается с заменой пробела на %20 .
Действительно ли пробел в имени файла не разрешен?
Как правильно использовать пробел в имени файла?
Вы также можете создать файлы с именем -rf ~ (использовать touch -- "-rf ~" ), но я бы не рекомендовал это делать.
Вы можете сделать это, это разрешено, как создание сценария самоуничтожения с именем "cd", но вы не должны этого делать. Ваш файл уже выглядит по-разному в 3 разных инструментах, не так ли плохо?
Не все разделяют мнение, что это действительно очень раздражает. И «Нет причин для этого» настолько очевидно ложно, что не нуждается в опровержении. Я сдался и узнал, как правильно обращаться с пространствами много лет назад, и по большей части это действительно не имеет большого значения.
@snailboat Пробелы являются признаком реальной проблемы, которая заключается в отсутствии стандартизации. Файловые системы Unix позволяют именам файлов практически неограниченные двоичные двоичные объекты. Единственными недопустимыми байтами являются 0 и 47 ( / разделитель). Использование всех 254 оставшихся байтов открывает дверь ко всем способам неописуемых «имен». Очевидно, это безумие, но не все согласны с тем, что такое «вменяемый», и разные персонажи сломают разные инструменты. Пересечение здравомыслия каждого довольно мало .
Пробелы, и действительно каждый символ, кроме / и NUL, разрешены в именах файлов. Рекомендация не использовать пробелы в именах файлов исходит из опасности того, что они могут быть неправильно истолкованы программным обеспечением, которое их плохо поддерживает. Возможно, такое программное обеспечение глючит. Но также возможно, что языки программирования, такие как сценарии оболочки, делают слишком легким написание программного обеспечения, которое ломается при представлении имен файлов с пробелами в них, и эти ошибки имеют тенденцию проскальзывать, потому что сценарии оболочки не часто тестируются их разработчиками, использующими имена файлов с пробелами в их.
Замены пробелов %20 не часто встречаются в именах файлов. Это в основном используется для (веб) URL. Хотя это правда, что% -кодирование из URL иногда попадает в имена файлов, часто случайно.
@ Я не знаю, что вы можете указать NUL-символ в любом аргументе командной строки в bash . Я попробовал несколько вещей, таких как цитирование с помощью Ctrl-V и что-то вроде этого, $(echo -e \\0) но это не сработало. Дело в том, что NUL не может использоваться в именах файлов, потому что он не может использоваться в строках C (потому что это терминатор строк), и все базовые API, а также практически все строки, обрабатываемые программами C, используют этот формат , Поскольку bash он написан на C, он может вообще не иметь поддержки для любых строк с NUL в них. Я могу ошибаться, может быть какой-то непонятный путь .
Вроде как зависит от контекста. Строковые функции обычно не считают окончательный ноль (или, скорее, первый ноль - это конец строки, даже если после него есть что-то), поэтому в этом смысле он имеет нулевую длину и поэтому считается пустым.
@Celada, конечно, вы можете использовать NUL и bash, вам нужно $'\0' . Например: find . -print0 | while read -d $'\0' f; do echo "$f"; done
Пространства будут разрешены в именах файлов, как вы заметили.
Если вы посмотрите на запись «большинство файловых систем UNIX» в этой таблице в википедии , вы заметите:
Единственными запрещенными символами являются / и «ноль». «Нуль» относится к нулевому байту, но они все равно не разрешены в текстовых данных.
Однако , если вы используете какую-либо оболочку, вы, возможно, поймете, что есть некоторые символы, которые, в первую очередь * , создадут неприятности, а именно оператор глобализации POSIX.
В зависимости от того, как вы хотите определить «хлопот», вы можете включить туда пробелы (пробелы, табуляции, новые строки и т. Д.), Так как это создает необходимость в кавычках "" . Но это неизбежно, так как пробелы разрешены, так что .
Как правильно использовать пробел в имени файла?
В контексте оболочки / командной строки, оберните имя файла в одинарные или двойные кавычки (но обратите внимание, что они не совпадают с другими проблемами WRT) или экранируйте пробелы \ , например:
Ты не можешь «Семантика execve» относится к тому факту, что в C (и любом другом языке, который я знаю) текстовые строки заканчиваются нулем. Оболочка реализована на языке C. Самая хитрая вещь, о которой я могу подумать, touch $(echo -e "foo\00bar") - это -e процесс \0N как восьмеричное значение, но он все равно где-то теряется, так как он просто создает файл с именем foobar . Конечно, NULL не может быть напечатан, но я гарантирую, что он пропал оттуда из-за ограничения строки C.
"текстовые строки заканчиваются нулем" -> Чтобы объяснить далее: строки всегда хранятся с нулевым байтом в конце, поэтому это "не разрешено" в тексте: если вы вставите один, вы фактически прервали строку в таком случае. Например, foo[NULL]bar в конечном итоге, как foo для большинства намерений и целей. Тот факт, что этого не происходит, echo -e показывает, что NULL где-то был удален.
Подавляющее большинство языков программирования допускают нулевые символы в строках. Просто так получается, что основным языком, который не является C, является язык, на котором построен Unix - и большинство оболочек Unix также не допускают нулевые символы в строках. В любом случае, @Tim, все интерфейсы Unix используют строки с нулевым символом в конце, поэтому нулевой байт - это то, что вы никогда не можете иметь в имени файла (плюс, / который является разделителем каталогов и не может быть заключен в кавычки, поэтому может быть в пути но не в имени файла).
. но [уже неважно]. Во всяком случае, не то, что я бы делал слишком часто. На мой взгляд, нет причин для них в текстовых данных. Я бы исправил это, но это комментарий.
Причина в значительной степени историческая - WAY назад в тумане пространств времени не было разрешено в именах файлов, поэтому пробелы использовались в качестве разделителей ключевых слов / имен файлов. Будущие интерпретаторы оболочки должны были быть обратно совместимы со старыми сценариями, и поэтому мы застряли на головной боли, которую мы испытываем сегодня.
Разработчики процессов, которым не нужно иметь дело с людьми, могут многое сделать намного проще, просто отбросив пробелы. Apple делает это, содержимое / System / Library / CoreServices / содержит очень мало пробелов, программы с пробелами открываются от имени пользователя иWouldLookStrangeIfCamelCased. Подобные пути только для Unix также избегают пробелов.
(отчасти связанный анекдот: в середине 90-х беспилотник Windows сказал «Назовите одну вещь, которую вы можете сделать на Mac, которую я не могу сделать в Windows» -> «Использовать 12 символов в имени файла». -> Тишина. Пробелы были также возможно в этих 12 символов)
Раньше я использовал V6 Unix (c. 1978). Пространства были разрешены тогда. Одна из моих задач заключалась в написании программы для анализа файловой системы (с использованием прямого дискового ввода-вывода) и поиска файла, в названии которого были пробелы и символы возврата.
Так что да, как уже много раз говорилось в другом месте, имя файла может содержать практически любой символ. Но нужно сказать , что имя файла является не файл. Он имеет некоторый вес в качестве атрибута файла, поскольку для открытия файла обычно требуется имя файла, но имя файла указывает только на фактический файл. Это ссылка, которая хранится в каталоге, в котором она была записана, вместе с номером инода, что намного ближе к реальному файлу .
Итак, вы знаете, называйте это как хотите. Ядру все равно - все ссылки на файлы, которые оно будет обрабатывать, будут иметь дело с реальными номерами инодов. Имя файла предназначено для потребления человеком - если вы хотите сделать его сумасшедшим, это ваша файловая система. Здесь я сделаю некоторые сумасшедшие вещи:
Сначала я создам 20 файлов и назову их только пробелами, каждое имя файла будет на один пробел больше, чем последнее:
Это довольно забавно. Посмотри на мои ls :
Теперь я собираюсь отразить этот каталог:
Вот ../mirror/ содержание:
Хорошо, но, может быть, вы спрашиваете - но что в этом хорошего? Как вы можете сказать, что есть что? Как вы можете быть уверены, что связали правильный номер инода с правильным именем файла?
2. Только строчные буквы
Используйте только строчные буквы для названий файлов. В Windows название «Новый Документ.docx» значит то же самое, что и «новый документ.docx», но это относится не ко всем операционным системам. Например, некоторые Unix-системы проявляют чувствительность к регистру.
Короткие и длинные имена
Длинное имя файла считается любым именем файла, превышающим короткое соглашение об именовании стилей MS-DOS (также называемое 8.3). При создании длинного имени файла Windows также может создать короткую форму имени 8.3, которая называется псевдонимом 8.3 или коротким именем, а также хранить его на диске. Этот псевдоним версии 8.3 можно отключить по соображениям производительности по всей системе или для указанного тома в зависимости от конкретной файловой системы.
Windows Server 2008, Windows Vista, Windows Server 2003 и Windows XP: псевдоним 8.3 нельзя отключить для указанных томов до Windows 7 и Windows Server 2008 R2.
Во многих файловых системах имя файла будет содержать тильду (~) в каждом компоненте имени, которое слишком долго соответствует правилам именования 8.3.
Не все файловые системы соответствуют соглашению о замене тильды, и системы можно настроить для отключения создания псевдонима 8.3, даже если они обычно поддерживают его. Поэтому не следует предполагать, что псевдоним 8.3 уже существует на диске.
Чтобы запросить имена файлов 8.3, длинные имена файлов или полный путь к файлу из системы, рассмотрите следующие параметры:
- Чтобы получить форму 8.3 длинного имени файла, используйте функцию GetShortPathName .
- Чтобы получить длинную версию имени файла короткого имени, используйте функцию GetLongPathName .
- Чтобы получить полный путь к файлу, используйте функцию GetFullPathName .
В более новых файловых системах, таких как NTFS, exFAT, UDFS и FAT32, Windows сохраняет длинные имена файлов на диске в Юникоде, что означает, что исходное длинное имя файла всегда сохраняется. Это верно, даже если длинное имя файла содержит расширенные символы, независимо от кодовой страницы, активной во время операции чтения или записи диска.
Файлы с длинными именами файлов можно копировать между секциями файловой системы NTFS и Windows секциями файловой системы FAT, не теряя никаких сведений об имени файла. Это может быть не так для старых файловых систем MS-DOS FAT и некоторых типов CDFS (CD-ROM) в зависимости от фактического имени файла. В этом случае короткое имя файла будет заменено, если это возможно.
Путь к указанному файлу состоит из одного или нескольких компонентов, разделенных специальным символом (обратная косая черта), при этом каждый компонент обычно является именем каталога или именем файла, но с некоторыми заметными исключениями, рассмотренными ниже. Зачастую крайне важно интерпретировать системой путь, как выглядит начало или префикс пути. Этот префикс определяет пространство имен , используемое путем, а также специальные символы, используемые в какой позиции в пути, включая последний символ.
Если компонент пути является именем файла, он должен быть последним компонентом.
Каждый компонент пути также будет ограничен максимальной длиной, указанной для конкретной файловой системы. Как правило, эти правила делятся на две категории: короткие и длинные. Обратите внимание, что имена каталогов хранятся файловой системой как особый тип файла, но правила именования файлов также применяются к именам каталогов. Чтобы подвести итог, путь — это просто строковое представление иерархии между всеми каталогами, которые существуют для определенного файла или имени каталога.
Полные и относительные пути
Для функций API Windows, которые управляют файлами, имена файлов часто могут быть относительными к текущему каталогу, а некоторые API требуют полного пути. Имя файла относительно текущего каталога, если оно не начинается со следующего:
- UNC-имя любого формата, которое всегда начинается с двух символов обратной косой черты ("\\"). Дополнительные сведения см. в следующем разделе.
- Конструктор дисков с обратной косой чертой, например "C:\" или "d:\".
- Одна обратная косая черта, например "\directory" или "\file.txt". Это также называется абсолютным путем.
Если имя файла начинается только с конструктора дисков, но не обратной косой черты после двоеточия, он интерпретируется как относительный путь к текущему каталогу на диске с указанной буквой. Обратите внимание, что текущий каталог может быть корневым каталогом в зависимости от того, что он был установлен во время последней операции изменения каталога на этом диске. Ниже приведены примеры этого формата:
- "C:tmp.txt" ссылается на файл с именем "tmp.txt" в текущем каталоге на диске C.
- "C:tempdir\tmp.txt" относится к файлу в подкаталоге к текущему каталогу на диске C.
Путь также считается относительным, если он содержит "двойные точки"; то есть два периода вместе в одном компоненте пути. Этот специальный описатель используется для обозначения каталога над текущим каталогом, который иначе называется родительским каталогом. Ниже приведены примеры этого формата:
- ".. \tmp.txt" указывает файл с именем tmp.txt, расположенный в родительском каталоге текущего каталога.
- ".. \.. \tmp.txt" указывает файл, который является двумя каталогами над текущим каталогом.
- ".. \tempdir\tmp.txt" указывает файл с именем tmp.txt, расположенный в каталоге с именем tempdir, который является одноранговым каталогом текущего каталога.
Относительные пути могут объединять оба примера типов, например "C. \tmp.txt". Это полезно, так как система отслеживает текущий диск вместе с текущим каталогом этого диска, он также отслеживает текущие каталоги в каждой из разных букв дисков (если в вашей системе несколько), независимо от того, какой диктор диска установлен в качестве текущего диска.
Сводка
Имена файлов и папок, которые начинаются или заканчиваются с пробелом ASCII (0x20), будут сохранены без этих символов. Имена файлов и папок, которые заканчиваются символом периода ASCII (0x2E), также будут сохранены без этого символа. Все остальные символы сохраняемого или ведущего белого пространства сохраняются.
- Если файл сохранен как 'Foo.txt', где ведущим персонажем (s) является пробел ASCII (0x20), он будет сохранен в файловую систему как "Foo.txt".
- Если файл сохранен как "Foo.txt", где следячий символ (s) является пробелом ASCII (0x20), он будет сохранен в файловой системе как "Foo.txt".
- Если файл сохранен как ".Foo.txt", где ведущим персонажем (s) является период ASCII (0x2E), он будет сохранен в файловой системе как ".Foo.txt".
- Если файл сохранен как "Foo.txt.", где следячий символ (ы) является периодом ASCII (0x2E), он будет сохранен в файловой системе как "Foo.txt".
- Если файл сохранен как 'Foo.txt', где главный символ (s) — это альтернативный символ пробела, например идеографическое пространство (0x3000), он будет сохранен в файловой системе как 'Foo.txt'. Ведущие символы белого пространства не удаляются.
- Если файл сохранен как "Foo.txt", в котором следяющий символ (s) является альтернативным белым пространством, например идеографическим пространством (0x3000), он будет сохранен в файловой системе как "Foo.txt". Следяющие символы белого пространства не удаляются. Имена файлов и папок, которые начинаются или заканчиваются с символом whitespace, по-разному оговарены API Win32 и WinRT из-за требований экосистемы.
Пространства имен NT
Существуют также API, которые позволяют использовать соглашение о пространстве имен NT, но диспетчер объектов Windows делает это ненужным в большинстве случаев. Чтобы проиллюстрировать, полезно просмотреть пространства имен Windows в браузере системных объектов с помощью средства winObj Windows Sysinternals. При запуске этого средства отображается пространство имен NT, начинающееся с корневого каталога, или "\". Вложенная папка с именем "Global??" — это место расположения пространства имен Win32. Именованные объекты устройства находятся в пространстве имен NT в подкаталоге Device. Здесь также можно найти Serial0 и Serial1, объекты устройства, представляющие первые два COM-порта, если они присутствуют в системе. Объект устройства, представляющий том, будет примерно таким, как HarddiskVolume1, хотя числовой суффикс может отличаться. Имя DR0 в подкаталоге "Harddisk0" является примером объекта устройства, представляющего диск и т. д.
Чтобы сделать эти объекты устройств доступными Windows приложениями, драйверы устройств создают символьную ссылку (символьную ссылку) в пространстве имен Win32 "Global??", к соответствующим объектам устройства. Например, COM0 и COM1 в подкаталоге "Global??" — это просто символьные ссылки на Serial0 и Serial1, "C:" — это символьная ссылка на HarddiskVolume1, "Physicaldrive0" — это символьная ссылка на DR0 и т. д. Без символьного канала указанное устройство Xxx не будет доступно ни одному приложению Windows с помощью соглашений о пространстве имен Win32, как описано выше. Однако дескриптор можно открыть на этом устройстве с помощью любых API, поддерживающих абсолютный путь к пространству имен NT формата \Device\Xxx.
Благодаря добавлению поддержки нескольких пользователей через службы терминалов и виртуальные машины стало еще больше необходимо виртуализировать корневое устройство на уровне системы в пространстве имен Win32. Для этого добавьте символьную ссылку с именем GLOBALROOT в пространство имен Win32, которое можно увидеть в подкаталоге "Global??" средства браузера WinObj, описанного ранее, и сможете получить доступ через путь "\\?\GLOBALROOT". Этот префикс гарантирует, что следующий путь выглядит в истинном корневом пути диспетчера системных объектов, а не в зависимом от сеанса пути.
При подборе названий для файлов используйте только латинские буквы, цифры, символы «-» и «_».
Из-за того, что для русского языка существует множество различных кодировок, многие программы могут некорректно работать с файлами, имеющими кириллические символы в названии. При использовании русских символов в названии могут возникнуть такие проблемы:
- Файл корректно отображается при просмотре через FTP-клиент, но не открывается на сайте;
- Имя файла может «побиться» (стать нечитабельным) при загрузке с локального компьютера на сервер или при копировании файла с сервера на сервер;
- Файл некорректно индексируется поисковыми системами;
- Файл не открывается на компьютере пользователя и т.д.
Пространства имен файлов Win32
Префикс пространства имен Win32 и соглашения приведены в этом разделе и в следующем разделе с описанием их использования. Обратите внимание, что эти примеры предназначены для использования с функциями API Windows и не все обязательно работают с приложениями оболочки Windows, такими как Windows Explorer. По этой причине существует более широкий спектр возможных путей, чем обычно доступны в приложениях оболочки Windows, и Windows приложения, которые используют преимущества этого, можно разработать с помощью этих соглашений о пространстве имен.
Так как он отключает автоматическое расширение строки пути, префикс "\\?\" также позволяет использовать ".." и "." в именах путей, которые могут быть полезны при попытке выполнить операции с файлом с этими зарезервированными относительными описателями пути в рамках полного пути.
Многие, но не все API-интерфейсы ввода-вывода файлов поддерживают "\\?\"; Необходимо ознакомиться со справочной темой для каждого API, чтобы убедиться.
Обратите внимание, что API Юникода должны использоваться для проверки того, что префикс "\?\" позволяет превысить MAX_PATH
Дополнительная информация
Ограничение максимальной длины пути
В выпусках Windows до Windows 10 версии 1607 максимальная длина пути равна MAX_PATH, которая определяется как 260 символов. В более поздних версиях Windows изменение раздела реестра или использование средства групповая политика требуется для удаления ограничения. Полные сведения см. в разделе об ограничении максимальной длины пути .
ВЫХОД
Смотрите, и номер индекса, содержащийся в нем, ../mirror/"$" и номер ссылки, на который ссылается ссылка, ./' ' относятся к одному и тому же файлу Они описывают один и тот же файл. Они называют это, но не более того. На самом деле в этом нет ничего загадочного, только некоторые неудобства, которые вы могли бы причинить себе, но в конечном итоге это практически не повлияет на работу вашей файловой системы unix.
3. Не используйте пробел
Если название файла состоит больше, чем из одного слова, никогда не используйте пробел для отделения слов. Используйте в качестве разделителя символ «-» или «_».
Хорошо icon-skype.jpg Плохо image 1.jpg
Соглашения об именах
Следующие фундаментальные правила позволяют приложениям создавать и обрабатывать допустимые имена файлов и каталогов независимо от файловой системы:
Используйте точку, чтобы отделить имя базового файла от расширения в имени каталога или файла.
Используйте обратную косую черту (\) для разделения компонентовпути. Обратная косая черта делит имя файла на путь к нему и одно имя каталога из другого имени каталога в пути. Обратную косую черту нельзя использовать в имени фактического файла или каталога, так как это зарезервированный символ, разделяющий имена на компоненты.
Используйте обратную косую черту в качестве части имен томов, например "C:\". в папке "C:\path\file" или "\\server\share" в "\server\share\path\file" для имен UNC. Дополнительные сведения об именах UNC см. в разделе ограничения максимальной длины пути .
Не предполагайте конфиденциальность регистра. Например, рассмотрим имена ОСКАРа, Оскара и оскара, хотя некоторые файловые системы (например, файловая система, совместимая с POSIX), могут рассматривать их как разные. Обратите внимание, что NTFS поддерживает семантику POSIX для учета регистра, но это не поведение по умолчанию. Дополнительные сведения см. в разделе CreateFile.
Конструкторы томов (буквы диска) точно так же не учитывают регистр. Например, "D:\" и "d:\" ссылаться на тот же том.
Используйте любой символ в текущей кодовой странице для имени, включая символы и символы Юникода в расширенном наборе символов (128–255), за исключением следующих:
Следующие зарезервированные символы:
- < (меньше чем);
- > (больше чем);
- : (двоеточие)
- " (двойная кавычка)
- / (косая черта)
- \ (обратная косая черта)
- | (вертикальная полоса или канал)
- ? (вопросительный знак)
- * (звездочка)
Целочисленное значение ноль, иногда называемое символом NUL ASCII.
Символы, целочисленные представления которых находятся в диапазоне от 1 до 31, за исключением альтернативных потоков данных, в которых разрешены эти символы. Дополнительные сведения о потоках файлов см. в разделе "Файл Потоки".
Любой другой символ, который не допускает целевая файловая система.
Используйте точку в качестве компонента каталога в пути для представления текущего каталога, например ".\temp.txt". Дополнительные сведения см. в разделе "Пути".
Используйте два последовательных периода (.).) в качестве компонента каталога в пути для представления родительского элемента текущего каталога, например ".. \temp.txt". Дополнительные сведения см. в разделе "Пути".
Не используйте следующие зарезервированные имена для имени файла:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 и LPT9. Кроме того, избегайте этих имен, за которым следует немедленное расширение; Например, NUL.txt не рекомендуется. Дополнительные сведения см. в разделе Пространства имен.
Не заканчивайте имя файла или каталога пробелом или точкой. Хотя базовая файловая система может поддерживать такие имена, оболочка Windows и пользовательский интерфейс не поддерживаются. Однако можно указать точку в качестве первого символа имени. Например, ".temp".
Читайте также: