如何在C#中使用GZip正确压缩NBT文件，确保Minecraft及NBT编辑器可正常识别

核心不兼容根因 #

用.NET自带GZipStream生成的压缩文件读不了，本质是输出的GZip流和Minecraft依赖的zlib标准输出不匹配，具体偏差：

• .NET Framework 内置GZipStream写GZip头的操作系统标识字段（文件偏移第9字节）时，固定写入0xFF。Minecraft的NBT解析器、主流独立NBT编辑器为了兼容早期存档格式，会严格校验这个字段——zlib默认生成的GZip流该字段值为0x03（Unix），遇到0xFF会直接判定文件损坏。
• 旧版.NET的GZipStream在Dispose时存在缓冲区flush不完整的问题，容易导致压缩流尾部的CRC校验、原始长度标记缺失，让解析器读到一半判定流截断。

落地修复方法 #

1. 调整GZipStream构造参数，显式设置leaveOpen: true，避免Dispose时意外关闭底层MemoryStream；写入完成后主动调用Flush()，确保所有缓冲区数据写入底层流。
2. 压缩完成后手动修正GZip头的不兼容字段，把第9字节的操作系统标识替换为0x03，完全匹配zlib的输出标准。
3. 修正代码里的路径逻辑bug：备份文件时用的相对路径level.dat，是进程工作目录下的文件，和后续拼接的程序目录下的目标路径完全不一致，很容易出现备份错文件、操作错目标的问题，所有文件操作要统一使用拼接好的绝对路径。

修正后的压缩实现代码 #

static byte[] CompressGZip(byte[] raw)
{
    using (MemoryStream memory = new MemoryStream())
    {
        using (GZipStream gzip = new GZipStream(memory, CompressionLevel.Optimal, leaveOpen: true))
        {
            gzip.Write(raw, 0, raw.Length);
            gzip.Flush();
        }
        var compressedBytes = memory.ToArray();
        // 替换不兼容的OS字段为zlib标准值
        if (compressedBytes.Length >= 10)
        {
            compressedBytes[9] = 0x03;
        }
        return compressedBytes;
    }
}

前置排查项 #

• 确认未压缩NBT源数据格式正确：合法的未压缩NBT文件首字节必须是NBT标签类型值（通常是代表Compound标签的0x0A），如果level.temp的首字节不符合这个特征，说明之前的解压步骤就已经出错，哪怕压缩逻辑修正了也无法被识别。
• 不要混用压缩格式：Minecraft顶层的level.dat必须用GZip格式压缩，.mca区域文件内部的NBT使用ZLib（RFC1950）格式压缩，两种格式的头结构、校验逻辑完全不同，不能通用。

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