.NET Core 6.0中GZipStream解压大文本数据时截断的原因

核心原因 #

.NET Core/.NET 5+ 中GZipStream.Read的实现和.NET Framework存在差异，它不会保证一次性读取完请求的所有字节。在.NET Framework中，当流内有足够数据时，Read可能一次性返回全部请求长度，但.NET Core的实现更严格遵循流设计规范——Stream.Read的官方文档明确说明，返回字节数可能小于请求长度（即使流未到末尾）。对于较大的压缩数据，单次调用Read就停止，必然会导致数据截断。

另外你的压缩代码未写入原始数据长度到头部，但解压代码却从gzBuffer前4字节读取msgLength，这本身逻辑不匹配。如果压缩时没额外写入长度，解压时读取的这个值是无效的，可能导致buffer大小错误，不过你提到.NET Framework正常，大概率是巧合或压缩时的完整代码包含头部写入逻辑未贴出，但核心问题还是Read的行为差异。

解决方法 #

1. 修复解压读取逻辑，确保完整读取 #

不能依赖单次Read获取全部数据，推荐用CopyTo自动处理循环读取：

byte[] gzBuffer = Convert.FromBase64String(compressedText);
// 直接初始化内存流并跳过前4字节的长度头部
using (MemoryStream ms = new MemoryStream(gzBuffer, 4, gzBuffer.Length - 4))
using (GZipStream zip = new GZipStream(ms, CompressionMode.Decompress))
using (MemoryStream decompressedMs = new MemoryStream())
{
    zip.CopyTo(decompressedMs);
    return Encoding.UTF8.GetString(decompressedMs.ToArray());
}

如果要手动循环读取，代码示例如下：

byte[] gzBuffer = Convert.FromBase64String(compressedText);
using (MemoryStream ms = new MemoryStream(gzBuffer, 4, gzBuffer.Length - 4))
using (GZipStream zip = new GZipStream(ms, CompressionMode.Decompress))
{
    int msgLength = BitConverter.ToInt32(gzBuffer, 0);
    byte[] buffer = new byte[msgLength];
    int totalRead = 0;
    int readBytes;
    // 循环读取直到获取全部数据
    while ((readBytes = zip.Read(buffer, totalRead, buffer.Length - totalRead)) > 0)
    {
        totalRead += readBytes;
    }
    return Encoding.UTF8.GetString(buffer);
}

2. 确保压缩和解压的头部逻辑一致 #

如果要通过头部存储原始数据长度，压缩时必须先写入该长度：

byte[] buffer = Encoding.UTF8.GetBytes(originalText);
using (MemoryStream ms = new MemoryStream())
{
    // 先写入原始数据长度到头部
    ms.Write(BitConverter.GetBytes(buffer.Length), 0, 4);
    using (GZipStream zip = new GZipStream(ms, CompressionMode.Compress, true))
    {
        zip.Write(buffer, 0, buffer.Length);
    }
    byte[] compressedData = ms.ToArray();
    string compressedText = Convert.ToBase64String(compressedData);
}

这样解压时读取的msgLength才是有效的，配合完整读取逻辑就能得到正确结果。

为什么.NET Framework能正常工作？ #

.NET Framework的GZipStream.Read旧实现对较大数据可能会尝试一次性填充请求缓冲区，这种行为不符合流设计规范，.NET Core/.NET 5+ 修正了这个问题，严格遵循规范，因此依赖单次Read的旧代码就会出现截断问题。

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