在 Windows 上，什么时候应该使用“\\\\?\\” 文件名前缀？
我遇到了 ac 库，用于打开给定 Unicode 文件名的文件。 在打开文件之前，它首先通过添加“\\?\”将文件名转换为路径。 除了增加路径中允许的最大字符数之外，是否还有任何理由这样做 这篇 msdn 文章？
看起来这些“\\?\”路径需要 Windows API 和标准库的 Unicode 版本。
I came across a c library for opening files given a Unicode filename. Before opening the file, it first converts the filename to a path by prepending "\\?\". Is there any reason to do this other than to increase the maximum number of characters allowed in the path, per this msdn article?
It looks like these "\\?\" paths require the Unicode versions of the Windows API and standard library.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，就是为了这个目的。 但是，如果您决定创建超过 MAX_PATH 长度的路径，您可能会遇到兼容性问题。 例如，资源管理器 shell 和命令提示符（至少在 XP 上，我不知道 Vista 上）无法处理超过该长度的路径，并且会返回错误。
Yes, it's just for that purpose. However, you will likely see compatibility problems if you decide to creating paths over MAX_PATH length. For example, the explorer shell and the command prompt (at least on XP, I don't know about Vista) can't handle paths over that length and will return errors.
此方法的最佳用途可能不是创建新文件，而是管理其他人可能已创建的现有文件。
我管理一个文件服务器，它通常会获取
path_length > 的文件。 MAX_PATH。 您会看到，用户看到的文件为H:\myfile.txt，但在服务器上它实际上是H:\users\username\myfile.txt。 因此，如果用户创建的文件恰好包含MAX_PATH字符，则在服务器上该文件为MAX_PATH+len("users\username")。（使用 MAX_PATH 字符创建文件并不罕见，因为当您在 Internet Explorer 上保存网页时，它会使用页面标题作为文件名，而对于某些页面来说，文件名可能会相当长）。
此外，与 Mac 或 Linux 计算机共享驱动器（通过网络或 USB）时，您可能会发现名称为 con、prn 或 lpt1 的文件。 同样，前缀允许您和您的脚本处理这些文件。
The best use for this method is probably not to create new files, but to manage existing files, which someone else may have created.
I managed a file server which routinely would get files with
path_length > MAX_PATH. You see, the users saw the files asH:\myfile.txt, but on the server it was actuallyH:\users\username\myfile.txt. So if a user created a file with exactlyMAX_PATHcharacters, on the server it wasMAX_PATH+len("users\username").(Creating a file with MAX_PATH characters is not so uncommon, since when you save a web page on Internet Explorer it uses the page title as the filename, which can be quite long for some pages).
Also, sharing a drive (via network or usb) with a Mac or a Linux machine, you can find yourself with files with names like con, prn or lpt1. And again, the prefix lets you and your scripts handle those files.
我认为首先要注意的是“\\?\”不会使路径成为UNC路径。 当您第二次将其称为 UNC-样式 路径时，您会更加准确。 但即便如此，相似之处也仅来自于开头有两个反斜杠。 确实和UNC没有任何关系。 这是因为您必须使用更多个字符来获取带有“\\?\”前缀的 UNC 路径。
我认为您已经了解使用该前缀的全部原因。 它提高了您引用的文章中所述的最大长度限制。 并且它仅适用于 Unicode 路径； 非 Unicode 路径无法通过使用该前缀来避免限制。
需要注意的一件事是，相对路径不允许使用前缀，只能用于绝对路径。 您可能需要仔细检查您的 C 库是否遵守该限制。
I think the first thing to note is that "\\?\" does not make the path a UNC path. You were more accurate the second time when you called it a UNC-style path. But even then, the similarity only comes from having two backslashes at the start. It really has nothing to do with UNC. That's backed up by the fact that you have to use even more characters to get a UNC path with the "\\?\" prefix.
I think you've got the entire reason for using that prefix. It lifts the maximum-length limit as described in the article you cited. And it only applies to Unicode paths; non-Unicode paths don't get to avoid the limit by using that prefix.
One thing to note is that the prefix is not allowed for relative paths, only for absolute ones. You might want to double-check that your C library honors that restriction.
除了允许更长的路径之外，“\\?\”前缀还允许您使用文件和目录名称，例如“con”和“aux”。 通常 Windows 会将它们解释为老式 DOS 设备。
As well as allowing longer paths, the "\\?\" prefix also lets you use files and directory names like "con" and "aux". Normally Windows would interpret those as old-fashioned DOS devices.
我自 1995 年以来一直在编写 Windows 代码，尽管我知道该前缀，但我从未找到任何使用它的理由。 将路径长度增加到超过 MAX_PATH 似乎是唯一的原因，据我所知，我和我的程序的任何客户都没有这样做过。
I've been writing Windows code since 1995, and although I'm aware of that prefix, I've never found any reason to use it. Increasing the path length beyond
MAX_PATHseems to be the only reason for it, and neither I nor any of my programs' customers have ever done so, to my knowledge.