C语言 在 Windows 上获取目录分隔符？（'\'， '/'， 等等。）

Get directory separator char on Windows? ('\', '/', etc.)

提问by user541686

tl;dr: How do I ask Windows what the current directory separator character on the system is?

tl; dr：我如何询问 Windows 系统上的当前目录分隔符是什么？

---

---

Different versions of Windows seem to behave differently (e.g. \and /both work on the English versions, ￥ is apparently on the Japanese version, ? is apparently on the Korean version, etc...

不同版本的 Windows 似乎表现不同（例如\，/两者都适用于英文版本，￥ 显然在日文版上，? 显然在韩文版上，等等......

Is there any way to avoid hard-coding this, and instead ask Windows at run time?

有什么办法可以避免对此进行硬编码，而是在运行时询问 Windows？

Note:

笔记：

Ideally, the solution should notdepend on a high-level DLL like ShlWAPI.dll, because lower-level libraries also depend on this. So it should really either depend on kernel32.dllor ntdll.dllor the like... although I'm having a trouble finding anythingat all, whether at a high level or at a low level.

理想情况下，解决方案应该不依赖于像高层次的DLL ShlWAPI.dll，因为下级库也取决于此。所以它真的应该依赖于kernel32.dll或ntdll.dll之类的......尽管我根本找不到任何东西，无论是在高级别还是低级别。

Edit:

编辑：

A little experimentation told me that it's the Win32 subsystem (i.e. kernel32.dll... or is it perhaps RtlDosPathNameToNtPathName_Uin ntdll.dll? not sure, didn't test...) which converts forward slashes to backslashes, not the kernel. (Prefixing \\?\makes it impossible to use forward slashes later in the path -- and the NT native user-mode API also fails with forward slashes.)

一些实验告诉我，它是 Win32 子系统（即kernel32.dll......或者它可能RtlDosPathNameToNtPathName_U在ntdll.dll？不确定，没有测试......）将正斜杠转换为反斜杠，而不是内核。（前缀\\?\使得无法在路径的后面使用正斜杠——并且 NT 本机用户模式 ​​API 也会因正斜杠而失败。）

So apparently it's not quite "built into" Windows, but rather just a compatibility feature -- which means you can't just blindly substitute slashes instead of backslashes, because any program which randomly prefixes \\?\to paths will automatically break on forward slashes.

所以显然它不是完全“内置”到 Windows 中，而只是一个兼容性功能——这意味着你不能盲目地替换斜杠而不是反斜杠，因为任何随机前缀\\?\到路径的程序都会自动在正斜杠上中断。

I have mixed feelings on what conclusions to make regarding this, but I just thought I'd mention it.

我对对此做出什么结论感到复杂，但我只是想我会提到它。

_{(I tagged this as "path separator" even though that's technically incorrect because the path separator is used for separating paths, not directories (;vs. \). Hopefully people get what I meant.)}

_{（我将其标记为“路径分隔符”，尽管这在技术上是不正确的，因为路径分隔符用于分隔路径，而不是目录（;vs。\）。希望人们明白我的意思。）}

回答by wkl

While the ?and ￥characters are shown as directory separator symbols in the respective Korean and Japanese windows versions, they are only how those versions of Windows represent the same Unicode code point U+005cas a glyph. The underlying code point for backslash is still the same across English Windows and the Japanese and Korean windows versions.

虽然?和￥字符在各自的韩文和日文 Windows 版本中显示为目录分隔符，但它们只是这些版本的 Windows 将相同的 Unicode 代码点表示U+005c为字形的方式。反斜杠的底层代码点在英语 Windows 以及日语和韩语 Windows 版本中仍然相同。

Extra confirmation for this can be found on this page: http://msdn.microsoft.com/en-us/library/dd374047(v=vs.85).aspx

可以在此页面上找到对此的额外确认：http: //msdn.microsoft.com/en-us/library/dd374047(v=vs.85).aspx

Security Considerations for Character Sets in File Names

Windows code page and OEM character sets used on Japanese-language systems contain the Yen symbol (￥) instead of a backslash (\). Thus, the Yen character is a prohibited character for NTFS and FAT file systems. When mapping Unicode to a Japanese-language code page, conversion functions map both backslash (U+005C) and the normal Unicode Yen symbol (U+00A5) to this same character. For security reasons, your applications should not typically allow the character U+00A5 in a Unicode string that might be converted for use as a FAT file name.

文件名中字符集的安全注意事项

日语系统上使用的 Windows 代码页和 OEM 字符集包含日元符号 ( ￥) 而不是反斜杠 ( \)。因此，日元字符是 NTFS 和 FAT 文件系统的禁止字符。将 Unicode 映射到日语代码页时，转换函数会将反斜杠 (U+005C) 和正常的 Unicode 日元符号 (U+00A5) 映射到同一个字符。出于安全原因，您的应用程序通常不应允许在可能被转换为用作 FAT 文件名的 Unicode 字符串中使用字符 U+00A5。

Also, I don't know of any Windows API function that gets you the system's path separator, but you can rely on it being \in all circumstances.

另外，我不知道有任何 Windows API 函数可以为您提供系统的路径分隔符，但是您可以\在所有情况下都依赖它。

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

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

The following fundamental rules enable applications to create and process valid names for files and directories, regardless of the file system:

...

Use a backslash (\) to separate the components of a path. The backslash divides the file name from the path to it, and one directory name from another directory name in a path. You cannot use a backslash in the name for the actual file or directory because it is a reserved character that separates the names into components.

...

以下基本规则使应用程序能够为文件和目录创建和处理有效名称，而不管文件系统如何：

...

使用反斜杠 ( \) 分隔路径的组成部分。反斜杠将文件名与其路径分开，并将一个目录名与路径中的另一个目录名分开。您不能在实际文件或目录的名称中使用反斜杠，因为它是将名称分隔为组件的保留字符。

...

About /

关于 /

Windows should support the use of /as a directory separator in the API functions, though not necessarily in the command prompt (command.com).

Windows 应该支持/在 API 函数中用作目录分隔符，但不一定在命令提示符 ( command.com) 中使用。

Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\?\" prefix as detailed in the following sections.

注意 Windows API 中的文件 I/O 函数将“/”转换为“\”，作为将名称转换为 NT 样式名称的一部分，除非使用“\?\”前缀，如以下部分所述。

It's 'tough' to figure out the truth of all this, but this might be a really helpful link about /in Windows paths: http://bytes.com/topic/python/answers/23123-when-did-windows-start-accepting-forward-slash-path-separator

弄清楚这一切的真相是“困难的”，但这可能是/Windows 路径中一个非常有用的链接：http: //bytes.com/topic/python/answers/23123-when-did-windows-start-接受正斜杠路径分隔符

回答by Windows programmer

The original poster added the phrase "kernel-mode" in a comment to someone else's answer.

原发帖者在对其他人回答的评论中添加了“内核模式”一词。

If the original question intended to ask about kernel mode, then it probably isn't a good idea to depend on / being a path separator. Different file systems allow different character sets on disk. Different file system drivers in Windows can also allow different characters sets, which normally cannot include characters which the underlying file systems don't accept on disk, but sometimes they can behave strangely. For example Posix mode allows a component name to contain some characters in a path name in an NTFS partition, even though NTFS ordinarily doesn't allow those characters. (But obviously / isn't one of them, in Posix.)

如果最初的问题旨在询问内核模式，那么依赖 / 作为路径分隔符可能不是一个好主意。不同的文件系统允许在磁盘上使用不同的字符集。Windows 中的不同文件系统驱动程序也可以允许不同的字符集，这些字符集通常不能包含底层文件系统在磁盘上不接受的字符，但有时它们的行为会很奇怪。例如，Posix 模式允许组件名称在 NTFS 分区的路径名中包含某些字符，即使 NTFS 通常不允许这些字符。（但显然 / 不是其中之一，在 Posix 中。）

In kernel mode in Unicode, U+005C is always a backslash and it is always the path separator. Unicode code points for yen and won are not U+005C and are not path separators.

在 Unicode 的内核模式下， U+005C 始终是反斜杠，并且始终是路径分隔符。日元和韩元的 Unicode 代码点不是 U+005C，也不是路径分隔符。

In kernel mode in ANSI, complications arise depending on which ANSI code page. In code pages that are sufficiently similar to ASCII, 0x5C is a backslash and it is the path separator. In ANSI code pages 932 and 949, 0x5C is not a backslash but 0x5C might be a path separator depending on where it occurs. If 0x5C is the first byte of a multibyte character, then it's a yen sign or won sign and it is a path separator. If 0x5C is the second byte of a multibyte character, then it's not a character by itself, so it's not a yen sign or won sign and it's not a path separator. You have to start parsing from the beginning of the string to figure out if a particular char is actually a whole character or not. Also in Chinese and UTF-8, multibyte characters can be longer than two chars.

在 ANSI 的内核模式中，复杂性取决于哪个 ANSI 代码页。在与 ASCII 非常相似的代码页中，0x5C 是一个反斜杠，它是路径分隔符。在 ANSI 代码页 932 和 949 中，0x5C 不是反斜杠，但 0x5C 可能是路径分隔符，具体取决于它出现的位置。如果 0x5C 是多字节字符的第一个字节，则它是日元符号或韩元符号，并且是路径分隔符。如果 0x5C 是多字节字符的第二个字节，则它本身不是一个字符，因此它不是日元符号或韩元符号，也不是路径分隔符。您必须从字符串的开头开始解析，以确定特定字符是否实际上是一个完整字符。同样在中文和 UTF-8 中，多字节字符可以长于两个字符。

回答by R.. GitHub STOP HELPING ICE

The standard forward slash (/) has always worked in all versions of DOS and Windows. If you use it, you don't have to worry about issues with how the backslash is displayed on Japanese and Korean versions of Windows, and you also don't have to special-case the path separator for Windows as opposed to POSIX (including Mac). Just use forward slash everywhere.

标准的正斜杠 ( /) 一直适用于所有版本的 DOS 和 Windows。如果您使用它，您就不必担心在日文和韩文版本的 Windows 上如何显示反斜杠的问题，并且您也不必将 Windows 的路径分隔符与 POSIX（包括苹果电脑）。只需在任何地方使用正斜杠。