36 个字符的 UUID 非常棒。但我的直觉是，在我个人、家庭使用中，我不需要 36 个字符提供的所有唯一性。但我可能没有考虑到它们发挥作用的所有情况。
我想删除版本 4 UUID 中的几个字符，用我能理解的字符替换它们。例如，将 UUID 中的 4 个字符替换为cafe。这将有助于我编写脚本。例如，由于 crypto-LUKS 容器不接受标签（据我所知），我只能处理它们的 UUID（除非我写 udev 规则）
这会增加发生碰撞的风险。但如果我的个人领域在未来 5 年内涉及 10,000 个 UUID，我认为风险似乎可以忽略不计。但我可能错了。
有谁有这方面的经验吗？
答案1
概括：
我建议您不要尝试以这种方式“破解” UUID，而是使用文件系统标签、分区标签、逻辑卷名称或脚本变量，因为这些工具都是为您建议的那种东西而设计的。哪种方法最有效取决于您的特定需求，而您的问题并不能 100% 清楚地说明这一点。
延伸推荐：
A通用唯一标识符 (UUID)是 128 位（16 字节）数字，通常以十六进制字符串表示，其中某些元素之间有“-”字符，总共有 36 个字符。不过，这些不是任何字母数字字符；它们是十六进制数字。因此，您不能输入任何您喜欢的字母，只能输入十六进制值。即使您按照您的建议去做会违背 UUID 的精神，仅使用拉丁字母表的前六个字母的限制也是您的想法的一个大问题。
全局唯一标识符 (GUID) 本质上与 UUID 相同，但不同的标准使用不同的名称，并且两者都有变体。您对udev规则的引用让我认为您正在使用 Linux，其中 UUID 通常分配给文件系统，而 GUID 与分区相关联（使用 GPT 分区方案时）。在 Linux 中，分区 GUID 通常/etc/fstab使用标识符来引用（在 等中）PARTUUID。
文件系统和 GPT 分区除了 UUID/GUID 之外还可以有标签。听起来您希望让人类能够理解您的标识符，因此我建议您使用标签而不是 UUID/GUID。在许多 Linux 工具中，文件系统标签使用标识符来引用LABEL，而分区标签使用PARTLABEL标识符。
从您的问题中无法准确看出您想要在何处使用标识符（您在脚本中暗示了这一点，但没有说明该脚本的作用），所以我不知道使用或是否LABEL适合PARTLABEL您，但您可能需要研究一下。此外，udev如果有必要，我不会排除编写规则以获取使用标签的设备的符号链接；udev规则并不难编写，如果它们解决了您的问题，那么编写此类规则将比违反相关标准破解 UUID/GUID 值要好。
但请注意，分区标签是 GPT 的功能，而不是 MBR 的功能。因此，如果您使用 MBR，则分区标签将不是一种选择。不过，如果这有帮助，您可以切换到 GPT（即使不重新安装操作系统，尽管您需要重新安装引导加载程序）。
另一种可能性是重新配置您的系统以使用 LVM。例如，我在我的一台计算机上使用 LVM，并且在我的 LVM 中加密了特定的 LV。在此配置中，加密的 LV 可能是 ，/dev/mapper/myvg-home而解密的版本是/dev/mapper/myvg-home_crypt。由于 LV 的命名和通常引用方式都是这样的，因此您将获得更易于理解的“免费”引用。
另一种选择：引用脚本。如果您编写的脚本通过 UUID/GUID 值引用分区，则可以将这些值分配给变量，如下所示：
HOME_PART="c5424f69-5016-48bd-adf4-76bd95b1f6bc"
语法细节显然取决于您的脚本语言，但这是该想法的核心。然后，您将能够HOME_PART在脚本的其他地方引用。如果脚本要在多个系统上运行，您可能能够找到一种方法来识别特定分区并映射它们的 UUID/GUID 值 - 例如，通过解析以/etc/fstab按挂载点提取相关数据。这可能是一种非常灵活的方法，具体取决于您的特定需求。
无论您使用文件系统标签、分区标签、LV 名称还是脚本变量，您都可以从（或多或少）全套字母数字字符中获益，而且您甚至不需要处理部分十六进制 UUID/GUID 值。由于相关标准的实际限制，某些字符可能不被允许，但至少您可以使用您喜欢的任何 ASCII 数字和字母。