无Nix安装环境下如何生成与nix-prefetch-url输出一致的文件哈希

首先明确核心逻辑：nix-prefetch-url --unpack <URL>输出的哈希，不是zip源文件本身的哈希，是Nix按照固定规则，对zip解压后的完整文件树做NAR（Nix Archive）格式序列化后，计算得到的sha256哈希值，最终用Nix专用的base32编码输出。整个计算逻辑完全固定，不需要安装整套Nix发行版就能复现。

具体操作步骤 #

• 第一步：拉取目标zip文件到本地，不要对文件做任何修改，直接用curl/wget下载即可，不要用会自动修改文件内容、附加元数据的下载工具。
• 第二步：创建干净的临时工作目录，把zip完整解压到目录下的root子目录里：

  mkdir -p /tmp/nix-hash-work
  cd /tmp/nix-hash-work
  unzip -q /path/to/your/downloaded.zip -d ./root
  

  解压完成后手动清理无关垃圾文件：比如macOS压缩包自带的__MACOSX目录、.DS_Store文件，Windows生成的Thumbs.db文件，这些文件Nix解压时会自动忽略，不清理会导致哈希偏差。
• 第三步：计算该root目录的NAR格式sha256哈希，输出用Nix base32编码。
  这一步不需要完整Nix环境，你可以用静态编译的独立nix-hash单文件二进制（无额外依赖，拷贝就能跑），任意严格遵循NAR格式规范的独立哈希计算工具也可以替代，执行等价于如下逻辑的计算即可：

  nix-hash --type sha256 --base32 ./root
  

  命令输出的字符串，和正常Nix环境执行nix-prefetch-url --unpack <目标URL>得到的结果完全一致。

常见踩坑说明 #

• 不要直接计算原始zip文件的哈希，结果必然不匹配
• 不要用普通递归哈希命令（比如sha256sum递归遍历文件）计算目录哈希：普通哈希计算会受文件遍历顺序、文件时间戳/属主等元数据、空目录处理逻辑影响，和NAR序列化规则不兼容，结果不可能一致
• 解压过程不要修改任何文件的内容、权限、文件名，不要自动转换换行符格式，哪怕一个字节的改动都会导致哈希完全变化
• 如果压缩包解压后存在顶层嵌套目录（比如很多开源源码zip解压后是xxx-project-v1.0/子目录），不要手动调整目录结构，保持解压后的原始结构即可，nix-prefetch-url --unpack不会改动解压后的目录层级

内容的提问来源于stack exchange，提问作者vitvly