为何GitHub仅为Zip文件提供x-ms-blob-content-md5响应头？

命令执行结果 #

> curl -IL https://github.com/pH200/sharp-layer/releases/latest/download/release-x64.zip | grep md5
x-ms-blob-content-md5: 1GjBkzlLBeHFFpHVMYME4g==
> curl -IL https://github.com/tailwindlabs/tailwindcss/releases/latest/download/tailwindcss-linux-x64 | grep md5
> curl -IL https://github.com/9001/copyparty/releases/download/v1.19.0/copyparty-1.19.0.zip | grep md5
x-ms-blob-content-md5: QMwF29uP7uag5gP2g8bAYw==
> curl -IL https://github.com/9001/copyparty/releases/download/v1.19.0/copypart32.exe | grep md5

问题说明 #

上述命令显示，GitHub发布资产中仅.zip等归档文件会返回x-ms-blob-content-md5响应头（Base64编码的MD5值），同一版本下的其他类型资产（如可执行文件）则没有该头。需要明确背后的原因，并找到不依赖文件修改时间或本地存储ETag头的脚本验证方案。

差异原因 #

GitHub的发布资产存储在Azure Blob Storage中，不同类型文件的处理逻辑存在差异：

• 归档类文件（如.zip、.tar.gz）在上传时，Azure Blob Storage会自动计算并写入x-ms-blob-content-md5头，这是这类文件的默认存储策略。
• 二进制可执行文件、单文件脚本等资产，若通过非标准化流程上传（比如直接手动上传而非CI/CD自动构建上传），或者不符合触发自动计算MD5的文件类型规则，就不会生成该响应头。
• 此外，GitHub的CDN缓存层可能会对部分文件的响应头进行裁剪，进一步导致md5字段的缺失。

脚本解决方案 #

方案1：本地计算文件哈希 #

直接下载资产到临时位置，本地计算哈希值，完全不依赖响应头。示例bash脚本：

# 目标资产URL
ASSET_URL="https://github.com/tailwindlabs/tailwindcss/releases/latest/download/tailwindcss-linux-x64"
# 创建临时文件
TEMP_FILE=$(mktemp)

# 下载资产
curl -L "$ASSET_URL" -o "$TEMP_FILE"

# 计算MD5哈希（Linux环境）
LOCAL_MD5=$(md5sum "$TEMP_FILE" | awk '{print $1}')
echo "本地计算的MD5值: $LOCAL_MD5"

# 清理临时文件
rm -f "$TEMP_FILE"

方案2：使用官方校验和文件 #

若仓库发布时附带了校验和文件（如SHA256SUMS、MD5SUMS），可先拉取该文件再对比本地哈希：

# 校验和文件URL
CHECKSUMS_URL="https://github.com/9001/copyparty/releases/download/v1.19.0/SHA256SUMS"
# 目标资产文件名
TARGET_FILE="copypart32.exe"

# 下载校验和文件并过滤目标资产的哈希
OFFICIAL_HASH=$(curl -L "$CHECKSUMS_URL" | grep "$TARGET_FILE" | awk '{print $1}')
echo "官方发布的SHA256哈希: $OFFICIAL_HASH"

# 下载目标资产并计算本地哈希
curl -L "https://github.com/9001/copyparty/releases/download/v1.19.0/$TARGET_FILE" -o "$TARGET_FILE"
LOCAL_HASH=$(sha256sum "$TARGET_FILE" | awk '{print $1}')

# 对比哈希
if [ "$LOCAL_HASH" = "$OFFICIAL_HASH" ]; then
    echo "哈希匹配，文件验证通过"
else
    echo "哈希不匹配，文件可能已损坏或被篡改"
fi

# 清理文件
rm -f "$TARGET_FILE"

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