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

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

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

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

Примечание:

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

Изменить:

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

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

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

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

Ответ 1

Пока символы ₩ и ¥ отображаются как символы разделителя каталогов в соответствующих корейских и японских версиях Windows, они являются только тем, что эти версии Windows представляют собой одну и ту же кодовую точку Юникода U+005c в качестве глифа. Основная кодовая точка для обратной косой черты по-прежнему сохраняется на английских 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).

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

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

Ответ 2

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

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

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

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

Ответ 3

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