sanitise-file-name：一个非常灵活和高效的文件名净化器

在撰写本文时，我认为这是目前最好的文件名净化器之一（与现有的 Rust 选项如 sanitize-filename 和 sanitize-filename-reader-friendly，以及我在 Node.js 和 Python 等环境中发现的其他实现进行比较；我没有查看 C/C++ 等内容）。

• 它更快：虽然其灵活性可能在某些情况下对其不利（取决于优化器），但它有一个巨大的优势，即只进行一次分配，而其他选项（即使是 Rust 的 sanitize-filename 和 sanitize-filename-reader-friendly）至少进行三次或四次，通常更多。（注意，我没有进行任何基准测试比较。）更重要的是，它允许你持续重用一个足够大的缓冲区，从而实现摊销的 零 分配。

• 它有更好的文档：每个选项都明确声明了它做什么，为什么你可能会关心，有时还提供额外建议（例如，“如果你想支持 HFS+，先将其规范化为 NFD，以确保长度限制正确”）。

• 它更灵活：你可以选择是否需要诸如 Windows 安全性和 URL 安全性等功能，还有更多选项可以产生更可能更美观的结果（主要受到 sanitize-filename-reader-friendly 的启发）。

• 它更正确：它不会删除不必要的字符，并且确实删除了所有必要的字符（这是一个罕见但肯定不是未知的组合）；并且长度限制（正确实现为 UTF-8 代码单元而不是 UTF-16 代码单元或 Unicode 代码点或标量值）尽可能在基本名称而不是扩展名处截断（现在 这 是我在任何其他库中都没有找到的功能；如果你更喜欢之后添加扩展名，我也为你准备了，包括调整长度限制，这也是我在任何其他库中都没有找到的功能）。

• 它以平台和文件系统中立的方式运行，因为匹配本地平台的行为只是自找麻烦，尤其是在无法准确检测使用的文件系统的情况下。相反，它默认支持所有甚至稍微流行的文件系统（只关心 ␀ 和 /），并且你可以选择退出 Windows 支持，因为它是唯一一个具有甚至轻微繁琐规则的系统。

  • 但是ext3cow不支持@，因此不被支持。
  • 并且，在HFS+环境中，:被预留的情况下，只能通过Windows安全机制偶然支持；但我相信（尽管没有明确确认这一点）这几乎已经是很久以前的事情了，大约是Mac OS 9或更早。

• 它甚至不需要std或alloc（尽管它们默认是启用的）：它可以支持tinyvec_string::ArrayString，在默认选项下不超过510个字节（仅因为扩展的巧妙性才需要这么多的字节）。

• 它使用的是原始的、最好的™英语。（也就是说：使用sanitise而不是sanitize，以及使用file name而不是filename。）——尽管作为对美式英语的让步，函数也以sanitize的拼写导出；但您仍需在crate名称中使用sanitise的拼写。

use sanitise_file_name::sanitise;

fn main() {
	// Examples of some of the things it can do:
	// whitespace is collapsed to one space,
	// various ASCII puntuation gets replaced by underscores,
	// outer whitespace is trimmed.
	// (There are reasons for each of these things,
	// and they can all be turned off or customised with options.)
    assert_eq!(
		sanitise("   https://example.com/Some\tfile \u{a0}  name .exe "),
		"https___example.com_Some file name.exe",
	);

	// The windows_safe option leads to the addition of the underscore.
    assert_eq!(sanitise("aux.h"), "aux_.h");
}