Lib.rs

研究

• Windows

• dirent.c 包含所有实现（似乎）打开目录和读取其条目，以及所有路径转换（Windows 的 UTF-16）。这是即时完成的，以便 git 可以使用 UTF-8。
• mingw 用于转换，并且它们在转换期间处理代理字符，可能是一种非严格 UTF-8 转换器？实际上，它使用 WideCharToMultiByte，如果 UTF-8 无效 Unicode（即 Unicode 对），则会失败。
• OsString 在 Windows 上已经将字符串存储为 WTF-8，它支持 代理对，这是 UTF-8 不允许的，毕竟它是 UTF-16 特定的，仅用于扩展可编码的代码点。
• 关于 WTF-8 的信息性阅读，这是 Rust 内部使用的编码，用于处理代理和非良好形成的代理（那些不在对中的）。

• Unix

• 它使用 opendir 和 readdir。没有指定编码，除了这些路径是空终止的。

学习经验

代理对是一种扩展UTF-16编码中可编码值范围的方法，主要用于Windows和JavaScript中。长期以来，这些用于代理的码点，总是成对使用，并未分配，直到它们用于罕见的表情符号等。Unicode标准并不要求代理必须成对出现，尽管如今在UTF-16中未成对的代理被认为是不规则的，这些不应该被转换为UTF-8等。

这就是我们必须处理to_string_lossy()的原因，这仅仅是为了这个怪癖。

这也意味着唯一有资格看到转换错误的平台是Windows，而在此平台上，只有较旧的预Vista版本不正确地允许不规则UTF-16字符串。新版本不再执行此类转换，例如，当从UTF-16转换为UTF-8时，将触发错误。

结论

由于现在WideCharToMultiByte（从Vista开始）已修复为产生有效的UTF-8，孤立的代理码点将导致失败，而git 不关心。

尽管如此，我们将这样做，这意味着从现在开始，我们可以在Windows上直接转换为UTF-8，并在必要时冒泡错误，防止潜在的不匹配代理对被gitoxide保存到磁盘上。

尽管错误仅存在于较旧的Windows版本中，但我们将通过可失败函数调用来在类型系统中表示它。调用者可以在结果上调用.expect()来表示他们不希望处理这个特殊且罕见的情况。请注意，服务器不应该进入会导致恐慌的代码路径。