Rust 如何以与平台无关的方式将OsString转换为utf8编码的字符串

在阅读了大量的标准库文档和源代码后，我得出了以下结论.

• 在Unix上，OsString是Vec<u8>，可以是任意字节，预计为UTF-8.Windows OsString上当前的版本是WTF-8(source)，它是UTF-8的超集，允许您以特定格式的UTF-8表示格式错误的UTF-16.将其理解为也是类似UTF-8的任意字节就足够了，因为只有在恢复原始字节的情况下才使用WTF-8编码的属性(参见下面的encode_wide).如果操作系统中相同的Unicode信息在Unix上以有效的UTF-8编码，在Windows上以有效的UTF-16编码，OsString会将两者编码为相同的UTF-8.这些都是内部的和私有的，但有助于理解公共接口.
• 用户可见的特定于平台的行为只有在转换时才会出现.
• 在从操作系统接收时，Windows系统使用from_wide，这会将可能格式错误的UTF-16转换为OsString(WTF-8)编码.Unix系统使用from_vec，它只是包装了Vec<u8>.两者都是无损的，但from_wide确实改变了布局.我认为在Windows上创建&OsStr而不首先创建OsString的唯一方法是从str开始，而在Unix上也可以使用from_bytes从简单的&[u8]切片创建&OsStr.
• Windows允许您将OsStr转换为具有encode_wide的可能格式错误的UTF-16码点的迭代器，这将无损地undo撤消原始转换.在Unix上，您可以简单地用as_bytes或into_vec取回字节.在Windows上，似乎无法获得&[u8]字节，考虑到实现方式，这是有意义的.
• 在转换为String时，将判断所有Unicode无效的OsString值的有效性.但是，如果OsString运行在Windows上并且是有效的Unicode，则转换为String将跳过有效性判断，因为这是在最初转换为OsString并作为布尔值存储在OsString中时执行的.此布尔值只有在为真时才有意义，在这种情况下，可以确保OsString是有效的UTF-8.如果它是假的，可能是有效的，也可能是无效的.Unix没有这个布尔值.这意味着，如果你保留OsString，而且它是有效的，在Windows上多次转换为String将比在Unix上更便宜.然而，如果你从操作系统收到OsString个值，但从未将它们转换成String，由于Windows的预先转换，它在Unix上将比Windows便宜.

因此，从本质上讲，有三种 Select :

1. 操作系统为您提供了有效的字符串.OsString已经是有效的UTF-8，您可以使用into_string或to_str获得这些字节.
2. 操作系统给了您一个可能无效的字符串.您可以使用前面的方法进行判断，也可以拨打to_string_lossy进行自动替换.
3. 如果你想知道操作系统为你提供了什么，如果你想使用不同的替换策略，或者如果你想重新解释字节，你可以在Windows上使用encode_wide，或者在Unix上使用as_bytes或into_vec.