摘要

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

基本原理

Win32 平台上的 Python 2.2 在将传递给 open 和 os 模块中函数的 Unicode 文件名转换为“mbcs”编码后，再将结果传递给操作系统。在脚本操作时，当区域设置与文件创建时的区域设置相同时，这种方法通常会成功。大多数机器都被设置为一个区域设置，并且很少（如果曾有）更改过此区域设置。对于某些用户，区域设置会更频繁地更改，而在服务器上，通常有用户使用不同区域设置保存的文件。

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

规范

在提供宽字符文件 API 的 Windows 平台上，当向文件 API 提供 Unicode 参数时，将调用宽字符函数，而不是标准的 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”可能是一个实施此功能的起点。

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

参考实现

该实现可在 [2] 处获取。

参考资料

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

版权

本文档已置于公共领域。