说，我有一个包含有关对象信息的文件。我使用名称创建它，以便文件名本身包含有关对象的某些信息，例如对象 ID、对象父 ID、其他一些元 ID 信息和文件序列号。这样做是因为文件可用于不同的模块，并避免对文件的元信息进行多次数据库访问。
文件名 = "OB"+fileId+parentId+metaId+sequence+".txt"
序列从 00001 到 99999（也可能非常大）
因此，每个索引的每个数字都有特定的含义
现在，文件信息将提供给我们应用程序之外的程序，我不希望其他应用程序知道我使用的详细信息。所以，我正在考虑在发送文件之前使用文件名的加密或散列，文件中的响应文件名也被加密或散列，他们将根据文件的内容向我发送带有加密/散列响应文件名的响应
有2个挑战：
不涉及数据库的最快和最简单的方法
文件名长约 25 个字符（带有其他 id 和序列信息），所以我希望生成的文件名更小（尽可能小）和标准大小。
或者任何可以使用的替代机制？？？
选项 1 哈希
使用诸如 SHA-256 或 SHA-128 之类的加密哈希算法将使您的文件名更长，尽管可以很好地保证它是唯一的，但并不能保证这一点（所有哈希算法都受到生日悖论的影响）。
由于无法保证 SHA-256 或 SHA-128 会生成唯一的文件名，因此根据您需要的安全级别，您可能需要查看 Adler32。这个算法不会像 SHA 系列那样安全，主要是因为生成的哈希大小非常小，你可以很容易地暴力破解它。但是 Adler32 可以提供文件名的混淆。
因为 Alder32 生成的散列大小很小（32 位），所以发生冲突的机会也远高于 SHA 系列，因此您肯定需要保留某种表，其中包含您的文件名及其相应的散列值（以及在这种情况或 SHA 情况下推荐）。该表可以是存储在缓存中的简单列表，但主要原因是如果发生冲突，您将需要更改值来计算新的哈希值。
选项 2 加密
加密不会使您的数据变小，充其量只是相同的大小（如果您的数据大小可以被算法的块大小整除）。但是，它将保留所有数据，而无需保留加密值的表格。如果你决定使用加密而不是散列，我会使用 AES，因为这是当今的标准。加密文件名的数据量很小，您可能不会注意到算法之间的任何差异，但如果您足够偏执，您可以查看Intel CPU上的 AES 指令集。