Compression 无文件签名/头解压缩gzip

我设法截获了一个grpc请求，并使用protoc对其进行解码，但我似乎无法理解任何数据，因为请求头的原因，我知道它是使用gzip压缩的

        "content-type": "application/grpc; charset=utf-8",
        "grpc-accept-encoding": "identity,deflate,gzip",
        "accept-encoding":  "identity,gzip",

这是解码后的protcolbuffer

   "1": {
        "1": "¸z =PÞCw.\u001e}».*\u001f\u0011"
    },
    "2": some value,
    "3": {
        "1": {
            "1": {
                "1": "©ÄS¢ÄþP\f.½\fÑWÄK>"
            }
        }
    },
    "4": {
        "2": 1,
        "4": {
            "2": {
                "1": "other value"
            }
        },
        "7": 2
    }
}

---

我已经在cyberchef上尝试过gunzip，但是没有文件签名我无法解压任何东西，因此我应该如何将其他不可读的值解压为纯文本？？？

并且protcol缓冲区解码器是否可能将文件签名读取为protobuf本身？接受编码意味着接收器可以接收压缩内容，并不是说内容实际上是压缩的。既然你能解码那么远，我强烈怀疑它是压缩的。最有可能的解释是您对模式理解不够，因此那些“损坏”的字符串实际上不是字符串。@Eric Anderson什么模式？是的，虽然我不知道我在做什么xDD，但如果我错了，请纠正我，但你是说字符串已损坏而不是压缩？如果要反转grpc帧，我需要解码protobuf，然后使用指定的内容类型将其解压缩。我知道这些是字符串，因为如果我使用不同的变量（名称电子邮件…）执行相同的操作第二个文本更改，通过发布相同的请求，它将通过并执行预期的操作，因此它们必须是protobuf的stringschema==

.proto

文件。要完全解码协议缓冲区，您需要知道所涉及的数据类型；这不是自我描述。它只是自我描述，足以让您跳过部分。我并不是说那些字符串实际上已经损坏，而是说你对protobuf的解释可能是错误的。如果你有描述符，那么你可以让protobuf使用DynamicMessage精确地解码消息。这因语言而异，并非每种语言都有。在Java中，您可以使用