Традиционные пути DOS Traditional DOS paths
Стандартный путь DOS может состоять из трех компонентов: A standard DOS path can consist of three components:
Если присутствуют все три компонента, путь является абсолютным. If all three components are present, the path is absolute. Если буква тома или диска не указана и имя каталога начинается с символа разделителя каталогов, такой путь задан относительно корня текущего диска. If no volume or drive letter is specified and the directory name begins with the directory separator character, the path is relative from the root of the current drive. В противном случае путь задан относительно текущего каталога. Otherwise, the path is relative to the current directory. В следующей таблице показаны некоторые возможные пути к каталогам и файлам. The following table shows some possible directory and file paths.
В приведенном ниже примере показано различие между абсолютными и относительными путями. The following example illustrates the difference between absolute and relative paths. Предполагается, что каталог D:\FY2018\ существует и вы не установили какой-либо текущий каталог для диска D:\ из командной строки перед запуском этого примера. It assumes that the directory D:\FY2018\ exists, and that you haven’t set any current directory for D:\ from the command prompt before running the example.
Если вы хотите увидеть комментарии к коду, переведенные на языки, отличные от английского, сообщите нам на странице обсуждения этой проблемы на сайте GitHub. If you would like to see code comments translated to languages other than English, let us know in this GitHub discussion issue.
Как в Windows 10 включить поддержку пути к файлам длиной более 260 символов
Благодаря Anniversary Update для Windows 10 вы можете, наконец, отказаться от ограничения максимального пути в 260 символов в Windows. Вам просто нужно внести небольшие изменения в реестр Windows или групповую политику. Далее рассказано, как это сделать.
До Windows 95, операционная система Windows допускала только имена файлов длиной восемь символов с расширением файла из трёх символов, обычно называемое именем файла 8.3. Windows 95 отказалась от этого, чтобы разрешить длинные имена файлов, но по-прежнему ограничивала максимальную длину пути (которая включает полный путь к папке и имя файла) не более 260 символами. Этот предел был установлен тогда и действует до сих пор. Если вы когда-либо сталкивались с этим ограничением, скорее всего, это было, когда вы пытались скопировать папки с глубоким вложением в другие папки, например, при копировании содержимого жёсткого диска в папку на другом диске. В Windows 10 Anniversary Update наконец добавлена возможность отказаться от этой максимальной длины пути.
Есть одна оговорка. Этот новый параметр не обязательно будет работать с каждым приложением, но он будет работать с большинством. В частности, любые современные приложения должны быть в порядке, как и все 64-битные приложения. Более старые 32-битные приложения должны быть подготовлены специальным образом, что на самом деле означает, что разработчик указал в файле манифеста приложения, что приложение поддерживает более длинные пути. У большинства популярных 32-битных приложений проблем не должно быть. Тем не менее вы ничем не рискуете если выполните эту настройку. Если приложение не работает, единственное, что произойдёт, это то, что оно не сможет открывать или сохранять файлы, сохранённые в местах, где полный путь превышает 260 символов.
Как временно исправить проблему с файлами?
Легкое Исправление
Если вам повезет, вы получите ошибку и точно знаете, какое имя файла вызывает проблему. Или, по крайней мере, где найти файл. Может быть, у вас есть имя файла, которое выглядит примерно так:
C:\User\guymc\Documents\My Resumesresumewithanamesolongthatitcausesproblemsandbecomespartofsomeguysarticleonthewebhowdoyoulikemenow.docx
Понятно, кто в этом случае виновник. Найдите файл в проводнике Windows или в проводнике, как он называется в Windows 10, нажмите один раз на него, нажмите F2, чтобы переименовать его, и измените это глупое имя файла на более разумное. Задача решена.
Менее простые исправления
Не всегда легко решить эту проблему. Иногда вы не можете изменить имена файлов или каталогов по любой причине.
Следующие решения помогут вам. Их несложно сделать.
Перемещение, удаление или копирование файлов или каталогов с помощью PowerShell Иногда вы получаете сообщение об ошибке при попытке переместить, удалить или скопировать каталоги, где количество символов для пути к файлу превышает 260.
Обратите внимание, что слова каталог и папка являются взаимозаменяемыми. Мы будем использовать «каталог» в будущем
Следующие командлеты PowerShell также можно использовать для файлов.
Возможно, путь к файлу выглядит примерно так:
C:\Users\guymc\Documents\This\Is\Exactly\The\Precise\Directory\Path\That\I\Need\To\Have\To\Keep\My\Files\Sorted\In\A\Manner\That\Makes\Sense\To\Me\So\Lets\Pretend\This\Is\An\Actual\Filepath\That\You\Might\Also\Have\On\Your\Windows\Computer\And\Not\Over\Think\It\Document.docx
Этот путь к файлу составляет 280 символов. Поэтому мы не можем скопировать каталог оттуда куда-либо еще с помощью обычного метода копирования-вставки. Мы получаем ошибку Destination Path Too Long.
Давайте предположим, что по какой-то причине мы не можем переименовать каталоги, в которые вложен файл. Что мы делаем?
Когда откроется PowerShell, вы окажетесь в корне своего пользовательского каталога. Продолжайте, предполагая, что C:\Users\guymc — ваш пользовательский каталог.
Каталог с именем This находится в каталоге Documents. Чтобы перейти в каталог Documents, мы используем команду .
Вы увидите быстрое изменение текущего каталога на C:\Users\guymc\Documents. Это хорошо. Мы работаем ближе к каталогам, которые облегчат жизнь.
Копирование каталога с использованием Copy-Item
Мы хотим скопировать каталог This и его содержимое в ThatNewFolder. Давайте используем команду PowerShell Copy-Item с параметрами -Destination и -Recurse.
-Destination сообщает PowerShell, где мы хотим, чтобы копия находилась. -Recurse говорит PowerShell скопировать все элементы внутри к месту назначения. Копирование оставляет оригиналы там, где они есть, и делает все новые в месте назначения.
Copy-Item This -Destination ThatNewFolder -Recurse
Переместить каталог с помощью Move-Item
Допустим, мы хотим переместить каталог This, а также все каталоги и файлы в нем, в ThatNewFolder. Перемещение не оставляет оригинал на месте.
Мы можем использовать команду PowerShell Move-Item с параметрами -Path и -Destination. -Path определяет элемент, который мы хотим переместить, и -Destination сообщает PowerShell, где мы хотим его получить.
Команда поместит это в ThatNewFolder. Он также будет перемещать все, что находится внутри этого каталога. Move-Item может использоваться для перемещения файлов или каталогов, и он работает независимо от пути к файлу или длины имени файла.
Move-Item -Path This -Destination ThatNewFolder
Чтобы убедиться, что это работает, используйте команду , чтобы войти в ThatNewFolder. Затем используйте команду для вывода списка каталогов в ThatNewFolder. Вы увидите, что этот каталог находится там.
Удалить каталог с помощью Remove-Item
Если мы хотим удалить этот каталог и все в нем, мы используем команду Remove-Item.
Командлет Remove-Item обладает некоторой встроенной безопасностью, которая затрудняет удаление каталога с содержимым внутри него. В нашем примере мы знаем, что хотим удалить все, поэтому мы будем использовать параметры -Recurse, чтобы заставить его удалять все внутри, и -Force, чтобы он делал это, не спрашивая нас, уверены ли мы в каждом элементе внутри.
Имейте в виду! Восстановить что-либо удаленное таким образом было бы чрезвычайно сложно.
Remove-Item This -Recurse -Force
Вы можете снова использовать команду dir, чтобы убедиться, что она пропала.
Вот и все
Существуют и другие способы обхода длинных имен файлов и путей к файлам, но то, что мы здесь рассмотрели, — это самые простые и эффективные методы.
Ответы:
Вместо того, чтобы явно включать все возможные символы, вы можете использовать регулярное выражение, чтобы проверить наличие недопустимых символов и затем сообщить об ошибке. В идеале ваше приложение должно называть файлы точно так, как хочет пользователь, и кричать только о том, что обнаруживает ошибку.
ConroyP, 15 сентября 2008 г., 17:19
Вот список недопустимых символов из MSDN:
Mark, 15 сентября 2008 г., 17:20
Решено
Вы можете получить список недопустимых символов из и .
UPD: См. о том, как использовать их в регулярном выражении.
UPD2: Обратите внимание, что согласно разделу «Примечания» в MSDN «Массив, возвращаемый этим методом, не гарантирует, что он будет содержать полный набор символов, которые недопустимы в именах файлов и каталогов». входит в более подробную информацию
Eugene, 15 сентября 2008 г., 17:22
Имена файлов Windows довольно неограниченны, так что на самом деле это может даже не быть проблемой который. В Windows запрещены следующие символы:
Вы можете легко написать выражение, чтобы проверить, присутствуют ли эти символы. Однако лучшим решением было бы попытаться называть файлы так, как хочет пользователь, и предупреждать их, когда имя файла не сохраняется.
Justin, 15 сентября 2008 г., 17:23
Также CON, PRN, AUX, NUL, COM # и некоторые другие никогда не являются допустимыми именами файлов в любом каталоге с любым расширением.
Roland, 15 сентября 2008 г., 17:24
Для .Net Frameworks до 3.5 это должно работать:
Сопоставление регулярных выражений должно помочь вам. Вот фрагмент с использованием константы ;
Для .Net Frameworks после 3.0 это должно работать:
Сопоставление регулярных выражений должно помочь вам. Вот фрагмент с использованием константы ;
Как только вы это узнаете, вам также следует проверить наличие различных форматов, например и .
Steve, 15 сентября 2008 г., 17:26
Вопрос в том, пытаетесь ли вы определить, является ли имя пути допустимым путем Windows или разрешено в системе, в которой выполняется код.? Я думаю, что последнее более важно, поэтому лично я бы, вероятно, разложил полный путь и попытался использовать _mkdir для создания каталога, в котором находится файл, а затем попытаться создать файл. Таким образом, вы узнаете не только то, содержит ли путь только допустимые символы Windows, но и действительно ли он представляет путь, который может быть записан этим процессом
Таким образом, вы узнаете не только то, содержит ли путь только допустимые символы Windows, но и действительно ли он представляет путь, который может быть записан этим процессом.
kfh, 15 сентября 2008 г., 17:27
Из MSDN «Присвоение имени файлу или каталогу» здесь приведены общие соглашения о том, что такое допустимое имя файла в Windows:
Вы можете использовать любой символ в текущей кодовой странице (Unicode / ANSI выше 127), за исключением:
- Символы, целочисленные представления которых от 0 до 31 (меньше, чем пространство ASCII)
- Любой другой символ, запрещенный целевой файловой системой (например, конечные точки или пробелы).
- Любое из имен DOS: CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 (и избегайте AUX.txt и т. д.)
- Имя файла — все точки
Некоторые необязательные вещи для проверки:
Пути к файлам (включая имя файла) не могут содержать более 260 символов (без префикса ).
Пути к файлам Unicode (включая имя файла) с более чем 32000 символов при использовании (обратите внимание, что префикс может расширить компоненты каталога и привести к превышению лимита в 32000)
user7116, 15 сентября 2008 г., 17:30
Попробуйте использовать это и ловите ошибку. Разрешенный набор может меняться в зависимости от файловой системы или разных версий Windows. Другими словами, если вы хотите знать, нравится ли Windows это имя, передайте ему имя и позвольте ему сказать вам.
Dewayne, 15 сентября 2008 г., 18:00
Регистр символов и файловая система Windows Case and the Windows file system
Особенность файловой системы Windows заключается в том, что пользователи и разработчики, имеющие дело с другими операционными системами, могут сталкиваться с проблемами из-за того, что в именах каталогов и путях не учитывается регистр символов. A peculiarity of the Windows file system that non-Windows users and developers find confusing is that path and directory names are case-insensitive. Это значит, что в именах каталогов и файлов сохраняется регистр строк, используемый в момент их создания. That is, directory and file names reflect the casing of the strings used when they are created. Например, вызов метода For example, the method call
Обход ограничений длинных путей через 7zFM
Наверняка многие знают архиватор 7Zip, но мало кто пользуется его файловым менеджером 7zFM.exe, а зря именно он может вам помочь в ситуации с сообщением «Слишком длинный целевой путь» или «Слишком длинный конечный путь». Вот у меня есть тестовая директория, у которой уже есть 260 символов в пути, и я не могу там создавать новую папку.
Откройте 7zFM.exe и перейдите в нем в конечную папку вашего пути.
Для создания новой папки нажмите клавишу F7.
Задайте необходимое вам имя, в моем примере это будет «БОльше 260 Microsot«.
В результате у нас создалась новая папка и заметьте 7zFM не ругнулся на наличие длинных путей, он их игнорирует просто и все.
Проверяем, что директория доступна через проводник Windows.
Все прекрасно отображается. Теперь я думаю вы легко сможете переносить, копировать, удалять файлы через 7zFM, когда вам проводник Windows ругается на наличие длинных путей.
Пропуск нормализации Skip normalization
Как правило, любой путь, передаваемый в API Windows передается в функцию GetFullPathName и нормализуется. Normally, any path passed to a Windows API is (effectively) passed to the GetFullPathName function and normalized
Существует одно важное исключение: путь к устройству, который начинается со знака вопроса, а не с точки. There is one important exception: a device path that begins with a question mark instead of a period
Если путь не начинается с последовательности \\?\ (обратите внимание на использование канонической формы с обратной косой чертой), он нормализуется. Unless the path starts exactly with \\?\ (note the use of the canonical backslash), it is normalized
Зачем нужно пропускать нормализацию? Why would you want to skip normalization? Существует три основных причины: There are three major reasons:
Повышение производительности за счет пропуска нормализации в тех случаях, когда нормализация уже выполнена. To improve performance by skipping normalization if you’ve already normalized.
Пропуск нормализации и проверки максимальной длины пути является единственным отличием между двумя видами синтаксиса путей к устройствам. В остальных аспектах они идентичны. Skipping normalization and max path checks is the only difference between the two device path syntaxes; they are otherwise identical
Пропуск нормализации следует использовать с осторожностью, поскольку в этом случае легко получить пути, при работе с которыми в обычных приложениях будут возникать трудности. Be careful with skipping normalization, since you can easily create paths that are difficult for «normal» applications to deal with
Настройка Windows 10 на обработку длинных путей к файлам
Если вы знаете, что будете часто использовать длинные пути к файлам и длинные имена файлов, вам будет проще заставить Windows работать. Нет смысла использовать PowerShell для выполнения работы каждый день.
Есть два способа сделать это. Один предназначен для пользователей Windows 10 Home, а другой — для пользователей Windows 10 Pro или Enterprise. Эти методы могут работать для Windows 8.1 или более ранней версии, но мы не можем гарантировать это.
Параметры для Windows 10 Home
Чтобы Windows 10 Home принимала длинные пути к файлам, нам нужно открыть редактор реестра . Если вы раньше не работали в редакторе реестра, будьте осторожны. Случайное удаление или изменение здесь может помешать работе Windows полностью.
Всегда делайте резервную копию вашего реестра, прежде чем вносить какие-либо изменения. Узнайте все, что вам нужно знать об этом, в нашем окончательном руководстве по резервному копированию и восстановлению реестра Windows.
Открыв редактор реестра и сделав резервную копию, перейдите в папку и найдите ключ LongPathsEnabled.
Дважды щелкните LongPathsEnabled. Убедитесь, что в поле Значение данные: номер 1 указан. Нажмите OK, чтобы подтвердить изменения.
Выйдите из редактора реестра, и теперь вы сможете работать с безумными длинными путями к файлам.
Параметры для Windows 10 Pro или Enterprise
Чтобы позволить Windows 10 Pro или Enterprise использовать длинные пути к файлам, мы будем использовать редактор локальной групповой политики. Это инструмент, который позволяет нам устанавливать политики в отношении работы Windows на компьютере и на уровне пользователей.
Откройте редактор групповой политики, перейдя в меню «Пуск» и набрав . Лучший результат должен быть Изменить групповую политику. Дважды щелкните по этому.
После открытия редактора групповой политики перейдите к Конфигурация компьютера → Административные шаблоны → Система → Файловая система. Там вы увидите политику включения длинных путей Win32.
Дважды щелкните по нему, чтобы изменить параметр политики. Измените его с «Отключено» на «Включено», затем нажмите кнопку «ОК», чтобы зафиксировать изменение.
Политика может не вступить в силу сразу. Вы можете принудительно обновить групповую политику.
[Ошибка установки Jdk] IllegalArgumentException: недопустимые символы в имени хоста
http-equiv=»Content-Type» content=»text/html;charset=UTF-8″>style=»clear:both;»>
Ошибка «IllegalArgumentException: недопустимые символы в имени хоста» при повторной установке jdk8 после переустановки компьютера
Установщик не может быть закрыт после этой ошибки, для закрытия может быть вызван только диспетчер задач
Затем я проверил множество методов, сказав, что в пути установки есть китайские или недопустимые символы / пробелы.
После попытки:
1. Изменить путь (неверно)
2. Создать путь вручную (неверно)
Наконец найдено в https://bugs.openjdk.java.net/browse/JDK-8130836
CUSTOMER SUBMITTED WORKAROUND : Disconnect from internet.
Избегайте этой проблемы при отключении от Интернета.
Проверено, чтобы решить проблему успешно
Интеллектуальная рекомендация
19.03.21 Я загрузил комплексные обучающие видеоуроки Photoshop CC 2015 и обучающие видеоуроки по новым функциям PS CC 2015. Я просмотрел несколько видео, но мне кажется, что они в основном объясняют н…
…
проверка данных весеннего mvc Два способа проверки данных Spring MVC: 1.JSR303 2.Hibernate Validator Второй метод является дополнением к первому методу Шаги для проверки данных с использованием Hibern…
Существует два способа вызова между сервисами Springcloud: RestTemplate и Feign. Здесь мы представляем сервисы вызова RestTemplate. 1. Что такое RestTemplate RestTemplate — это структура веб-запросов …
1. Понимать предварительный, средний, последующий порядок и иерархическую последовательность бинарных деревьев; Свяжите язык C со структурой данных двоичного дерева; Освойте с…
Вам также может понравиться
Последнее обучение, как использовать Kaldi, чтобы проснуться без использования WSTF, поэтому вам нужно глубоко пойти в Kaldi для обучения. Временное состояние обучения. Три изображения представляют со…
Во время простоя некоторые веб-страницы, которые мы создали, не были завершены, но не хотят, чтобы другие видели, вы можете создать простой эффект шифрования страницы на странице этой веб-страницы, ан…
Расширенные статьи серии Zookeeper 1. NIO, ZAB соглашение, 2PC представления концепции 2. Лидер выборов 3. Рукописный распределенный замок, центр настройки ==================================== 1. NIO,…
Посмотрите на конечный эффект первым DemoPreview.gif SETP1 эффект капли воды Первая реакция на эффект капли воды — нарисовать замкнутую кривую. С помощью события MotionEvent измените радиус во время п…
…
Как удалять, копировать, переносить файлы и папки при ошибке с длинными путями
Разобравшись с тем, как отключить проверку MAX_PATH в приложениях, давайте теперь поймем и научимся решать проблему длинных путей на файловых шарах и просто в проводнике. Классическая ситуация, когда пользователь попытался перенести свой файл или удалить его, создать папку и так далее, и он получает ошибку с пресловутыми длинными путями. Он просит разобраться вас и тут начинаются танцы с бубнами, вы просите его либо переименовать часть пути, или попросить его произвести действия в другом расположении, или просто забить, сказав, что виновата Windows со своими ограничениями, но мы же с вами профессионалы и инженеры, поэтому должны уметь выходить из таких ситуаций.