Osstr的观点是它的表现形式是特定于操作系统的.由于技术原因(
@Shepmaster’s answer提供了更多详细信息),实现有些复杂,但您可以这样想：
>在POSIX系统上,Osstr归结为& [u8],因为POSIX函数接受并返回字节串;
>在Windows上,Osstr可以被认为是& [u16],因为Win32 Unicode函数接受并返回16位单元数组的字符串.
由于本机Windows API接受16位“宽字符”1的序列,因此Osstr旨在存储这些序列.虽然Osstr可以转换为字节,因为任何东西都可以转换为字节,但这种表示没有用,因为这些字节对用户和系统都没有意义.这就是为什么Osstr不提供在Windows上以字节形式检索内容的方法.但是,它确实提供了Osstr :: encode_wide(),它迭代在Win32中有用的底层u16值.在另一个方向,Osstring :: from_wide()可用于从u16值切片创建一个Osstring.
您可以决定持久层如何处理平台之间的这种差异. Rust的Osstr提供了实现往返的必要工具,但代码之间的代码必然不同.例如,serde将差异解析为effectively treating,作为枚举Osstring {Unix(Vec< u8>),Windows(Vec< u16>)}.
1 Windows宽字符串有时被描述为UTF-16,因为它是在更高级别解释它们的方式,但这对于所有OS字符串都不正确. Windows文件名可以包含无效UTF-16的u16值对,并且仍然可用.这就是为什么不可能通过例如将Windows字符串表示为字节的原因.将它们转换为UTF-8.
