Получить разделитель каталогов char на Windows? ('', '/', п.)
tl; dr: как спросить Windows, какой текущий символ разделителя каталогов в системе?
различные версии Windows, похоже, ведут себя по-разному (например, и / оба работают на английской версии, ¥, видимо, на японской версии, ₩, видимо, от корейской версии, etc...
есть ли способ избежать жесткого кодирования этого и вместо этого спросить Windows при запуске время?
Примечание:
в идеале, решение должно не зависит от DLL высокого уровня, как ShlWAPI.dll, потому что библиотеки нижнего уровня также зависят от этого. Так что это действительно должно зависеть от kernel32.dll или ntdll.dll или тому подобное... хотя у меня проблемы с поиском что-нибудь на всех, будь то на высоком уровне или на низком уровне.
Edit:
небольшой эксперимент сказал мне, что это Win32 подсистема (т. е. kernel32.dll... или это возможно RtlDosPathNameToNtPathName_U на ntdll.dll? не уверен, не проверял...) который преобразует прямые косые черты в обратные, а не ядро. (Приставка ? делает невозможным использование прямых косых черт позже в пути - и API NT native user-mode также терпит неудачу с прямыми косыми чертами.)
таким образом, по-видимому, это не совсем "встроенный" Windows, а скорее просто функция совместимости , что означает, что вы не можете просто слепо заменять косые черты вместо обратных косых черт, потому что любая программа, которая случайным образом префиксы ? на пути автоматически перерыва на Слэш.
у меня смешанные чувства по поводу того, какие выводы делать по этому поводу, но я просто подумал, что упомяну об этом.
(я пометил это как "разделитель пути", хотя это технически неверно, потому что разделитель пути используется для разделения пути, а не каталоги (; и ). Надеюсь, люди получат то, что я означало.)
3 ответов
С ₩ и ¥ символы отображаются как символы разделителя каталогов в соответствующих корейских и японских версиях windows, они только так, как эти версии Windows представляют одну и ту же кодовую точку Unicode U+005c как глиф. Базовая кодовая точка для обратной косой черты по-прежнему одинакова для английских окон и японских и корейских версий windows.
дополнительное подтверждение этому можно найти на этой странице: http://msdn.microsoft.com/en-us/library/dd374047 (v=против 85).aspx
соображения безопасности для наборов символов в именах файлов
кодовая страница Windows и наборы символов OEM, используемые в системах японского языка, содержат символ иены (
¥) вместо обратной косой черты (\). Таким образом, символ иены является запрещенным символом для файловых систем NTFS и FAT. При сопоставлении Юникода с кодовой страницей японского языка, функции преобразования map как обратная косая черта (U+005C), так и обычный символ иены Юникода (U+00A5) к этому же символу. По соображениям безопасности приложения обычно не должны разрешать символ U + 00A5 в строке Юникода, который может быть преобразован для использования в качестве имени файла FAT.
кроме того, я не знаю ни одной функции Windows API, которая получает разделитель пути системы, но вы можете положиться на то, что это \ во всех обстоятельства.
http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#naming_conventions
следующие основные правила позволяют приложениям создавать и обрабатывать допустимые имена файлов и каталогов, независимо от файловой системы:
...
используйте обратную косую черту (
\) для разделения компонентов пути. Обратная косая черта разделяет имя файла из пути к нему, и один имя каталога из другого имени каталога в пути. Нельзя использовать обратную косую черту в имени файла или каталога, потому что это зарезервированный символ, который разделяет имена на составляющие....
о /
Windows должна поддерживать использование / в качестве разделителя каталогов в функциях API, хотя и не обязательно в командной строке (command.com).
Примечание функции ввода-вывода файлов в API Windows преобразуйте " / " в " \ "как часть преобразования имени в имя стиля NT, за исключением случаев использования"\?\" префикс как описано в следующих разделах.
"трудно" выяснить правду обо всем этом, но это может быть действительно полезной ссылкой о / в путях Windows: http://bytes.com/topic/python/answers/23123-when-did-windows-start-accepting-forward-slash-path-separator
оригинальный плакат добавил фразу "режим ядра" в комментарии к чужому ответу.
Если исходный вопрос предназначался для вопроса о режиме ядра, то, вероятно, не стоит зависеть от / быть разделителем пути. Различные файловые системы позволяют использовать различные наборы символов на диске. Различные драйверы файловых систем в Windows также могут разрешать разные наборы символов, которые обычно не могут включать символы, которые базовые файловые системы не принимают на диске, но иногда они ведут себя странно. Например, режим Posix позволяет имени компонента содержать некоторые символы в имени пути в разделе NTFS, хотя NTFS обычно не разрешает эти символы. (Но, очевидно, я не один из них, в Posix.)
в режиме ядра в Unicode U + 005C всегда является обратной косой чертой и всегда является разделителем пути. Кодовые точки Юникода для иен и вон не являются U + 005C и не являются разделителями путей.
в режиме ядра в ANSI, осложнения возникают в зависимости от того, какая кодовая страница ANSI. На кодовых страницах, достаточно похожих на ASCII, 0x5C является обратной косой чертой и разделителем пути. В кодовых страницах ANSI 932 и 949 0x5C не является обратной косой чертой, но 0x5C может быть разделителем путей в зависимости от того, где это происходит. Если 0x5C является первым байтом многобайтового символа, то это знак иены или знак победы, и это разделитель пути. Если 0x5C является вторым байтом многобайтового символа, то это не символ сам по себе, поэтому это не знак йены или знак победы, и это не разделитель пути. Вы должны начать разбор с начала строки, чтобы выяснить, является ли конкретный символ на самом деле целым символом или нет. Также в китайском языке и UTF-8 многобайтовые символы могут быть длиннее двух символов.
стандартная косая черта (/) всегда работал во всех версиях DOS и Windows. Если вы используете его, вам не нужно беспокоиться о проблемах с тем, как обратная косая черта отображается в японской и корейской версиях Windows, а также вам не нужно специально использовать разделитель пути для Windows, в отличие от POSIX (включая Mac). Просто используйте косую черту везде.