Получить разделитель каталогов char в Windows? ('\', '/', так далее.)

Question

tl; dr: Как спросить Windows, какой символ разделителя каталогов в системе используется в текущий момент?

---

Кажется, что разные версии Windows ведут себя по-разному (например, \ и / обаработа над английскими версиями, ¥, по-видимому, на японской версии, apparently, по-видимому, на корейской версии и т. д. *

Есть ли способ избежать жесткого кодирования этого, ивместо этого спросите Windows во время выполнения?

Примечание:

В идеале решение должно не зависеть от высокоуровневой DLL, такой как ShlWAPI.dllпотому что библиотеки нижнего уровня также зависят от этого.Так что на самом деле это должно зависеть от kernel32.dll или ntdll.dll или тому подобного ... хотя у меня проблемы с поиском что-нибудь вообще, будь тона высоком уровне или на низком уровне.

Редактировать:

Небольшой эксперимент показал, что это подсистема Win32 (т.е. kernel32.dll ... или, возможно, RtlDosPathNameToNtPathName_U вntdll.dll? Не уверен, не проверял ...) который переводит косые черты в обратные, нот ядра.(Префикс \\?\ делает невозможным использование прямой косой черты позже в пути - и API собственного пользовательского режима NT также не работает с прямой косой чертой.)

Так что, очевидно, он не совсем «встроен» в Windows,а скорее просто функция совместимости - это означает, что вы не можете просто слепо заменять косые черты вместо обратных косых черт, потому что любая программа, которая произвольно ставит префиксы \\?\ к путям, автоматически ломается при прямом слеше.о том, какие выводы следует сделать по этому поводу, но я просто подумал, что упомяну это.

_{(я отметил это как «разделитель пути», хотя это технически неверно, поскольку разделитель пути используется для разделения путей , а не каталогов (; против \). Надеюсь, люди поймут, что я имел в виду.)}

Answer 1

Хотя символы ₩ и ¥ отображаются как символы разделителя каталогов в соответствующих версиях Windows для корейского и японского языков, они представляют собой только то, как эти версии Windows представляют ту же кодовую точку Unicode U+005c, что и глиф.Базовая кодовая точка для обратной косой черты остается неизменной во всех версиях Windows на английском и японском и корейском языках.

Дополнительное подтверждение этому можно найти на этой странице: http://msdn.microsoft.com/en-us/library/dd374047(v=vs.85).aspx

Вопросы безопасности для наборов символов в именах файлов

Кодовая страница Windows и наборы символов OEM, используемые в системах на японском языке, содержат символ иены (¥) вместо обратной косой черты (\).Таким образом, символ иены является запрещенным символом для файловых систем NTFS и FAT.При сопоставлении Юникода с кодовой страницей на японском языке функции преобразования отображают оба символа обратной косой черты (U + 005C) и обычный символ иены Юникода (U + 00A5) на этот же символ.В целях безопасности ваши приложения обычно не должны разрешать использование символа U + 00A5 в строке Unicode, которая может быть преобразована для использования в качестве имени файла FAT.

Кроме того, я не знаю ни одной WindowsФункция API, которая возвращает вам системный разделитель путей, но вы можете рассчитывать на то, что он будет \ при любых обстоятельствах.

http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#naming_conventions

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

...

Используйте обратную косую черту (\) для разделения компонентов пути.Обратная косая черта разделяет имя файла от пути к нему и одно имя каталога от другого имени каталога в пути.Вы не можете использовать обратную косую черту в имени для фактического файла или каталога, потому что это зарезервированный символ, который разделяет имена на компоненты.

...

О /

Windows должна поддерживать использование / в качестве разделителя каталогов в функциях API, но не обязательно в командной строке (command.com).

Примечание. Функции файлового ввода-вывода в Windows API преобразуют "/" в "\" как часть преобразования имени в имя в стиле NT, кроме случаев использования префикса "\? \"как подробно описано в следующих разделах.

Трудно выяснить правду всего этого, но это может быть действительно полезной ссылкой о / в путях Windows: http://bytes.com/topic/python/answers/23123-when-did-windows-start-accepting-forward-slash-path-separator

Answer 2

Автор оригинала добавил фразу «режим ядра» в комментарии к чьему-либо ответу.

Если исходный вопрос намеревался задать вопрос о режиме ядра, то, вероятно, не стоит полагаться на / являющуюся разделителем пути. Различные файловые системы допускают разные наборы символов на диске. Различные драйверы файловой системы в Windows также могут разрешать разные наборы символов, которые обычно не могут включать символы, которые базовые файловые системы не принимают на диске, но иногда они могут вести себя странно. Например, режим Posix позволяет имени компонента содержать несколько символов в имени пути в разделе NTFS, даже если NTFS обычно не допускает эти символы. (Но, очевидно, / не один из них, в Posix.)

В режиме ядра в Unicode U + 005C всегда является обратной косой чертой и всегда является разделителем пути. Кодовые точки Unicode для иены и побед не являются U + 005C и не являются разделителями пути.

В режиме ядра в ANSI возникают сложности в зависимости от того, какая кодовая страница ANSI. В кодовых страницах, достаточно похожих на ASCII, 0x5C является обратной косой чертой и разделителем пути. В кодовых страницах ANSI 932 и 949 0x5C не является обратной косой чертой, но 0x5C может быть разделителем пути, в зависимости от того, где это происходит. Если 0x5C - это первый байт многобайтового символа, то это знак иены или знак выигрыша и разделитель пути. Если 0x5C является вторым байтом многобайтового символа, то это не символ сам по себе, поэтому это не знак иены или знак выигрыша и не разделитель пути. Вы должны начать анализ с начала строки, чтобы выяснить, является ли конкретный символ целым символом или нет. Также в китайском и UTF-8 многобайтовые символы могут быть длиннее двух символов.

Answer 3

Стандартный слеш (/) всегда работал во всех версиях DOS и Windows. Если вы используете его, вам не нужно беспокоиться о проблемах с отображением обратной косой черты в японской и корейской версиях Windows, а также вам не нужно использовать специальный разделитель пути для Windows в отличие от POSIX (включая Mac). Просто используйте косую черту везде.