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

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


Различные версии Windows, похоже, ведут себя по-другому (например, \ и / оба работают на английских версиях, ¥, по-видимому, на японской версии, ₩, по-видимому, находится на корейской версии и т. Д. …

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

Замечания:

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

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

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

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

У меня смешанные чувства по поводу того, какие выводы делать по этому поводу, но я просто подумал, что я упоминал об этом.

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

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

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

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

Кодовая страница Windows и OEM-наборы символов, используемые в системах на японском языке, содержат символ Йены ( ¥ ) вместо обратного слэша ( \ ). Таким образом, символ йены является запрещенным символом для файловых систем NTFS и FAT. При сопоставлении Unicode с кодовой страницей на японском языке функции преобразования отображают как обратную косую черту (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 вперед-слэш-путь-сепаратор

Оригинальный плакат добавил фразу «kernel-mode» в комментарии к чужому ответу.

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

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

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

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