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版本的Windows版本错误地允许不规范的UTF-16字符串。新版本不再执行此类转换，例如，在从UTF-16到UTF-8的转换中，它们将引发错误。

结论

由于WideCharToMultiByte现在已修复（从Vista开始）以生成有效的UTF-8，单独的代理代码点将导致失败，这是git 不关心的。

尽管如此，我们将解决这个问题，这意味着现在我们可以在Windows上直接转换为UTF-8，并在必要时向上冒泡错误，防止gitoxide意外地保存到磁盘上的不匹配的代理对。

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