数字文件的档案标识符

作为TNA(国家档案馆)欧米茄项目的一部分，我一直在思考数字文件的标识符应该如何构建。这篇博客文章延续了我之前的文章：档案目录记录标识符。

当考虑开发既能描述物理的、数字化的、又能描述出生的数字记录的新的档案目录时，我们很快意识到，与它的前身不同，这个目录还需要描述数字文件。

在这一点上，你可能会认为我把当前的问题混为一谈，档案馆通常认为是两个独立的系统，1)他们的档案目录，2)他们的数字保存系统。是的，我是，而且是故意的！然而，我认为这道汤已经煮了一段时间了；我已经看到，到目前为止，数字保存系统不得不包括编目(用于数字记录)的某些方面，因为已经到位的传统档案目录不足以描述新的数字世界。我相信可以在编目和(数字)保存活动之间建立一个干净和互惠互利的分离，但作为从业者，我们仍然在很大程度上撰写关于数字保存的书。

不管怎样，我离题了！数字文件的档案概念是一个复杂的概念，作为档案工作者，我们必须问一些棘手的问题，比如：

如果我更改文件名，它仍然是相同的数字文件吗？

所有这些都是在设计数字文件本地标识符方案时必须考虑的因素。在不写关于数字保存的各种原则的扩展文章的情况下，说文件的路径和/或名称在很大程度上不适合用作标识符，这在很大程度上是因为它们的暂时性，并且不能与可能引起命名冲突的来自其他系统的文件组合，这也许就足够了。

迄今为止，用于为数字文件生成标识符的数字保存中的主要方法一直是简单地为它们分配UUID(通用唯一标识符)；更具体地说，是版本4的UUID。此方法有几个很好的属性：

您可以只将一个UUID魔术般地存在，而不必关心它之前或之后的其他UUID。

发生冲突的可能性非常小--在103万亿版本4的UUID中找到副本的概率是十亿分之一。

UUID只是一个128位的正整数。这通常被格式化为表示为总共36个可打印字符的由五个组件组成的十六进制字符串，尽管它们不太人性化。

作为UUID的替代方案，我提出了一种新的方法来生成数字文件的标识符，该标识符是根据文件本身的内容计算得出的。

我应该清楚，这不是我的天才之举，类似的方法已经在其他领域广泛使用。例如，Git SCM(源代码管理)使用SHA1摘要来标识文件和更改。同样，IPFS(星际文件系统)使用其对CID(内容标识符)的定义，CID(内容标识符)是文件内容的散列函数摘要，用于寻址该文件。

为了避免IPFS CID和我们的内容标识符之间的任何混淆，在此我将使用缩写ACID(档案内容标识符)来指代我对标识符的建议。

ACID的主要部分通过经由散列函数计算数字文件的字节流(即内容)的摘要来生成。这就提出了一个问题，应该使用哪个散列函数？有大量不同的散列算法可用，它们具有不同的属性和不同的权衡。话虽如此，我还是建议我们使用BLAKE2b-256散列，原因如下：

例如，如果我们想要为Apache 2.0许可证文件生成BLAKE2b-256散列摘要，我们可以运行：

在提供数字文件的描述和标识符以及2)文件本身的情况下，我们可以通过重新计算文件的散列摘要并将结果与数字文件标识符进行比较来验证该描述确实是关于该文件的。

与上述类似，如果文件的散列摘要随时间变化，则我们可以断言其保存存在问题，例如数据损坏。

哈希摘要的计算成本比UUID高得多，而且要摘要的文件越大，成本就越高。

我相信散列摘要的缺点被其提供可验证性的优势所盖过。

出于保存和互操作性的目的，我们还没有考虑的一件事是如何确定使用哪个散列函数来生成标识符。当然，我说过我们将使用BLAKE2b-256，但是如果您想使用不同的散列函数呢？此外，从数字考古学的角度来看，给出一个标识符，如：

您也许能够推断它是一个散列摘要，并且所使用的字符的选择和数量将表明它可能是一个256位的散列……。但是使用的是哪个散列函数呢？

理想情况下，我们还需要一种机制来传达所使用的散列函数。事实上，IPF已经考虑到了这一点，并且它们使用一种称为Multihash的编码，该编码在其CID前面加上一个指示所使用的散列函数的代码。虽然我们可以在这里采用多哈希，但它比我们需要的要复杂得多(著名的结语？！？)。相反，我建议我们的ACID在开头有一个单一的ASCII字符来指示所使用的散列函数。单个ASCII字符具有固定长度的数字编码的优点，并且它使十六进制字符串表示中的字符数成为奇数，从而向数字考古学家提供提示，或许该酸类似于摘要，但具有额外的字符。我将更进一步，说这个字符应该在十六进制字母表之外(并且不区分大小写)，这应该使这样的数字考古学家非常明显地看到，前缀字符具有与字符串的其余部分不同的含义。

对于哈希函数类型，我将保留！用于指示BLAKE2b-256的字符。为什么？因为，我觉得它看起来很酷！这将意味着我们以前的数字文件标识符现在简单地变成：

当然，使用BLAKE2b-256生成数字文件标识符产生冲突的可能性非常小(即，两个具有相同标识符的不同文件)，但是如果.？

如果你检测到冲突，我会免费为你建立一个新的数字档案馆系统.。不要啊！开个玩笑！我们实际上已经有了一种机制来处理这个问题，即哈希函数类型；对于产生冲突的新文件，您可以切换到不同的哈希函数，也许是512位的哈希函数！这至少会为您提供一个不同的唯一标识符。但是.。如何处理冲突另一侧的原始文件，它现在可能已经深深地嵌入到您的存档中了！你可以重新编目，但也许你甚至不需要？

我的想法是写另一篇关于进一步编码这种酸的文章，以供紧凑型机器使用。好的，…。今天就到此为止吧！