21个版本
| 0.7.2 | 2023年6月28日 |
|---|---|
| 0.7.1 | 2023年3月3日 |
| 0.7.0 | 2022年11月7日 |
| 0.6.7 | 2022年6月15日 |
| 0.1.2 | 2020年5月13日 |
#200 in 文本处理
83 每月下载量
在 4 个crates（3个直接） 中使用
47KB
1K SLoC
ARF字符串
ARF是替代文件名表示法，一种用于将NUL终止的非UTF-8字符串编码为有效的（且非NUL终止）UTF-8字符串的编码。它旨在用于需要一种方法来在UTF-8字符串类型中表示POSIX兼容和Windows兼容的路径名的环境中。
这是一个实验，Windows编码方案尤其实验性。
描述
ARF字符串具有以下形式
arf-string ::= U+FEFF lossy-portion U+0000 NUL-escaped-portion
U+FEFF是字节顺序标记（BOM）代码点。
lossy-portion由原始字符串数据（不包括终止的NUL）组成，任何无法编码的字节被U+FFFD（Unicode替换字符）替换。
U+0000是NULL（NUL）代码点。
ARF字符串的NUL-escaped-portion由原始字符串数据（再次，不包括终止的NUL）组成，任何无法编码的字节被U+0000替换，然后
- 在POSIX-like平台上，设置为0的最高有效位的无效字节。
- 在Windows上，一个在
U+0和U+7FF之间的Unicode标量值，表示代理代码点空间中的偏移量（从U+D800到U+DFFF）。
示例
在POSIX-like平台上，"foo\xffbar"的ARF编码是"\xef\xbb\xbffoo\xef\xbf\xbdbar\x00foo\x00\x7fbar"
"\xef\xbb\xbf"是U+FEFF的UTF-8编码。"foo\xef\xbf\xbdbar"是替换了无法编码的字节的字符串，其UTF-8编码为U+FFFD。"\x00"是U+0000的UTF-8编码。"foo\0\x7fbar"是替换了无法编码的字节的字符串，该字节后跟一个NUL，然后是一个最高有效位设置为0的无效字节。
理由
在实践中，无法编码的路径名非常罕见，因此这种设计并不试图使其效率高。在最坏的情况下，ARF字符串可能比相应的输入字符串大几倍（尽管它们仍然是O(n)）。这种冗余被用来防止不了解ARF字符串的代码意外误用。
C和POSIX代码将路径表示为以NUL结尾的字符串。当给定一个ARF字符串时，此类代码将只看到BOM和包含替换字符的损耗部分。在大多数情况下，尝试打开此类路径名将产生ENOENT错误，因为UTF-8的BOM和UTF-8替换字节序列不太可能出现在非UTF-8的文件名中。典型应用程序的错误消息将包括路径名，其中替换字符将作为问题性质的提示。
因此，默认情况下，不了解ARF的C和POSIX代码将无法打开无法编码的路径名。对于许多应用程序来说，这种限制值得能够假设所有路径名都是UTF-8的优势。希望与无法编码的路径名一起工作的应用程序可以通过明确了解ARF字符串来选择加入，可选地使用此存储库中的Rust和C库。
另一个棘手的情况是修改路径的代码。不了解ARF的代码可能会在不了解ARF编码的情况下修改ARF字符串。此类代码不知道要更新ARF字符串的NUL转义部分，因此生成的ARF字符串将被检测为无效，导致错误而不是意外行为。
依赖关系
~1.4–10MB
~106K SLoC