摘要

本 PEP 讨论通过将 Unicode 文件名直接传递给系统的宽字符函数，来支持对 Windows NT 上所有可能文件的访问。

原理

在 Win32 平台上，Python 2.2 将传递给 open 和 os 模块中函数的 Unicode 文件名转换为 ‘mbcs’ 编码，然后将结果传递给操作系统。这在脚本操作的区域设置与创建文件时的区域设置相同的情况下通常是成功的。大多数机器都设置成一个区域设置，并且很少或从未改变过。对于一些用户来说，区域设置更改的频率更高，并且在服务器上，通常会有来自使用不同区域设置的用户保存的文件。

在 Windows NT 和后续操作系统（包括 Windows 2000 和 Windows XP）上，提供了宽字符 API，这些 API 可以直接访问所有文件名，包括那些使用当前区域设置无法表示的文件名。本提案的目的是通过标准 Python 文件对象和 posix 模块提供对这些宽字符 API 的访问，从而提供对 Windows NT 上所有文件的访问。

规范

在提供宽字符文件 API 的 Windows 平台上，当将 Unicode 参数提供给文件 API 时，会进行宽字符调用，而不是标准的 C 库和 posix 调用。

Python 文件对象被扩展为直接使用 Unicode 文件名参数，而不是将其转换。这会影响文件对象构造函数 file(filename[, mode[, bufsize]])，以及作为此构造函数别名的 open 函数。当在这里使用 Unicode 文件名参数时，文件对象的 name 属性将是 Unicode。文件对象的表示形式 repr(f) 将以类似于 Unicode 字符串表示的形式显示 Unicode 文件名作为转义字符串。

posix 模块包含接受文件或目录名称的函数：chdir、listdir、mkdir、open、remove、rename、rmdir、stat 和 _getfullpathname。这些函数将直接使用 Unicode 参数，而不是将其转换。对于 rename 函数，当两个参数之一为 Unicode，而另一个参数使用默认编码转换为 Unicode 时，就会触发此行为。

listdir 函数目前返回一个字符串列表。在本提案下，当其路径参数为 Unicode 时，它将返回一个 Unicode 字符串列表。

限制

在消费者 Windows 操作系统 Windows 95、Windows 98 和 Windows ME 上，没有宽字符文件 API，因此在本提案下，行为保持不变。将来可能可以将本提案扩展到涵盖这些操作系统，因为它们使用的 VFAT-32 文件系统确实支持 Unicode 文件名，但访问很困难，因此实现这一点需要大量工作。“Microsoft Layer for Unicode”可能是实现此功能的起点。

通过将 PY_UNICODE_TYPE 定义为 4 字节类型并将 Py_UNICODE_SIZE 定义为 4，Python 可以被编译为 Unicode 字符的大小为 4 字节，而不是 2 字节。由于 Windows API 不接受 4 字节字符，因此本提案中描述的功能在此模式下将不起作用，因此实现将回退到当前的 ‘mbcs’ 编码技术。此限制可以在将来通过使用 PyUnicode_AsWideChar 执行额外的转换来解除，但目前，这会为一个很少使用的功能增加太多复杂性。

参考实现

实现可以在 [2] 中找到。

参考资料

[1] Microsoft Windows API https://msdn.microsoft.com/

版权

本文档已进入公有领域。