使用 Protobuf-net，我突然遇到一个关于未知线路类型的异常

Question

（这是我在 RSS 中看到的一个问题的重新发布，但已被 OP 删除。我重新添加了它，因为我在不同的地方看到这个问题被问了好几次；wiki 上的“好” form")

突然，我在反序列化时收到 ProtoException ，消息是：unknownwire-type 6

• 什么是wire-type？
• 有哪些不同的电线类型值及其描述？
• 我怀疑是某个字段导致了问题，如何调试？

Answer 1

首先要检查：

输入数据是 PROTOBUF 数据吗？如果您尝试解析其他格式（json、xml、csv、二进制格式化程序），或者只是损坏数据（例如“内部服务器错误”html 占位符文本页面），那么它将无法工作。

---

什么是线型？

它是一个 3 位标志，告诉它（广义上讲；毕竟它只有 3 位）下一个数据是什么样的。

协议缓冲区中的每个字段都有一个标头作为前缀，该标头告诉它代表哪个字段（数字），
以及接下来会出现什么类型的数据；这个“什么类型的数据”对于支持以下情况至关重要
意外数据位于流中（例如，您在一端向数据类型添加了字段），如下所示
它让序列化器知道如何读取该数据（或在需要时存储它以进行往返）。

有哪些不同的电线类型值及其描述？

• 0：变长整数（最多 64 位） - 使用 MSB 进行 Base-128 编码，指示连续性（用作整数类型的默认值，包括枚举）
• 1：64 位 - 8 字节数据（用于 double，或选择性用于long/ulong）
• 2：长度前缀 - 首先使用变长编码读取整数；这告诉您后面有多少字节的数据（用于字符串、byte[]、“打包”数组，并作为子对象属性/列表的默认值）
• 3：“start group”-替代方案使用开始/结束标签对子对象进行编码的机制 - 很大程度上已被 Google 弃用，跳过整个子对象字段的成本更高，因为您不能只是“寻找”意外的对象
• 4：“结束组” - 孪生with 3
• 5：32 位 - 4 字节数据（用于float，或选择性用于int/uint 和其他小整数类型）

我怀疑某个字段导致了问题，如何调试？

您正在序列化到文件吗？ 最可能的原因（根据我的经验）是您覆盖了现有文件，但没有截断它；即是 200 字节；你已经重写了它，但只有 182 字节。现在，流的末尾有 18 字节的垃圾，导致流崩溃。重写协议缓冲区时必须截断文件。您可以使用 FileMode 来完成此操作：

using(var file = new FileStream(path, FileMode.Truncate)) {
    // write
}

或者在写入数据之后通过 SetLength 来完成此操作：

file.SetLength(file.Position);

其他可能的原因

您（意外地）将流反序列化为与序列化类型不同的类型。值得仔细检查对话双方以确保这种情况不会发生。

Answer 2

由于堆栈跟踪引用了此 StackOverflow 问题，因此我想我应该指出，如果您（意外地）将流反序列化为与序列化类型不同的类型，您也可能会收到此异常。因此，值得仔细检查对话双方，以确保这种情况不会发生。

Answer 3

这也可能是由于尝试将多个 protobuf 消息写入单个流而引起的。解决方案是使用 SerializeWithLengthPrefix 和 DeserializeWithLengthPrefix。

---

为什么会发生这种情况：

protobuf 规范支持相当少量的线路类型（二进制存储格式）和数据类型（.NET 等数据类型）。此外，这不是 1:1，也不是 1:many 或 Many:1 - 单个线类型可用于多种数据类型，并且单个数据类型可以通过多种线类型中的任何一种进行编码。因此，除非您已经了解场景，否则您无法完全理解 protobuf 片段，从而知道如何解释每个值。例如，当您读取 Int32 数据类型时，支持的线类型可能是“varint”、“fixed32”和“fixed64”，而读取 String< /code> 数据类型，唯一支持的连线类型是“string”。

如果数据类型和线路类型之间没有兼容的映射，则无法读取数据，并引发此错误。

现在让我们看看为什么会在此处的场景中发生这种情况

[ProtoContract]
public class Data1
{
    [ProtoMember(1, IsRequired=true)]
    public int A { get; set; }
}

[ProtoContract]
public class Data2
{
    [ProtoMember(1, IsRequired = true)]
    public string B { get; set; }
}

class Program
{
    static void Main(string[] args)
    {
        var d1 = new Data1 { A = 1};
        var d2 = new Data2 { B = "Hello" };
        var ms = new MemoryStream();
        Serializer.Serialize(ms, d1); 
        Serializer.Serialize(ms, d2);
        ms.Position = 0;
        var d3 = Serializer.Deserialize<Data1>(ms); // This will fail
        var d4 = Serializer.Deserialize<Data2>(ms);
        Console.WriteLine("{0} {1}", d3, d4);
    }
}

：上面，两条消息是直接写在对方之后的。复杂的是：protobuf 是一种可追加的格式，append 的意思是“合并”。 protobuf消息不知道自己的长度，因此读取消息的默认方式是：读取直到EOF。但是，这里我们附加了两种不同类型。如果我们读回来，它不知道我们什么时候读完第一条消息，所以它会继续读。当它从第二条消息获取数据时，我们发现自己正在读取“字符串”线类型，但我们仍在尝试填充 Data1 实例，其中成员 1 是一个 Int32。 “string”和Int32之间没有映射，所以它爆炸了。

*WithLengthPrefix 方法允许序列化器知道每条消息的结束位置；因此，如果我们使用 *WithLengthPrefix 序列化 Data1 和 Data2，然后反序列化 Data1 和 >Data2 使用 *WithLengthPrefix 方法，然后它正确在两个实例之间分割传入数据，仅将正确的值读入正确的对象。

此外，当存储这样的异构数据时，您可能希望为每个类另外分配（通过*WithLengthPrefix）不同的字段编号；这可以更好地了解正在反序列化的类型。 Serializer.NonGeneric 中还有一个方法，可用于反序列化数据而无需提前知道我们要反序列化的内容：

// Data1 is "1", Data2 is "2"
Serializer.SerializeWithLengthPrefix(ms, d1, PrefixStyle.Base128, 1);
Serializer.SerializeWithLengthPrefix(ms, d2, PrefixStyle.Base128, 2);
ms.Position = 0;

var lookup = new Dictionary<int,Type> { {1, typeof(Data1)}, {2,typeof(Data2)}};
object obj;
while (Serializer.NonGeneric.TryDeserializeWithLengthPrefix(ms,
    PrefixStyle.Base128, fieldNum => lookup[fieldNum], out obj))
{
    Console.WriteLine(obj); // writes Data1 on the first iteration,
                            // and Data2 on the second iteration
}

Answer 4

之前的答案已经比我更好地解释了这个问题。我只是想添加一种更简单的方法来重现异常。

如果序列化的 ProtoMember 的类型与反序列化期间的预期类型不同，也会发生此错误。

例如，如果客户端发送以下消息：

public class DummyRequest
{
    [ProtoMember(1)]
    public int Foo{ get; set; }
}

但是服务器将消息反序列化为以下类：

public class DummyRequest
{
    [ProtoMember(1)]
    public string Foo{ get; set; }
}

那么这将导致在这种情况下略有误导性的错误消息

ProtoBuf.ProtoException：无效的线路类型；这通常意味着您已覆盖文件而没有截断或设置长度

。如果属性名称发生更改，甚至会发生这种情况。假设客户端发送了以下内容：

public class DummyRequest
{
    [ProtoMember(1)]
    public int Bar{ get; set; }
}

这仍然会导致服务器将 int Bar 反序列化为 string Foo 这会导致相同的 ProtoBuf.ProtoException。

我希望这可以帮助人们调试他们的应用程序。

Answer 5

还要检查所有子类是否都有 [ProtoContract] 属性。有时当你拥有丰富的DTO时你可能会错过它。

Answer 6

当使用不正确的 Encoding 类型将字节转入和转出字符串时，我发现了此问题。

需要使用 Encoding.Default 而不是 Encoding.UTF8。

using (var ms = new MemoryStream())
{
    Serializer.Serialize(ms, obj);
    var bytes = ms.ToArray();
    str = Encoding.Default.GetString(bytes);
}

Answer 7

如果您使用 SerializeWithLengthPrefix，请注意将实例转换为 object 类型会破坏反序列化代码并导致 ProtoBuf.ProtoException：无效的线型。

using (var ms = new MemoryStream())
{
    var msg = new Message();
    Serializer.SerializeWithLengthPrefix(ms, (object)msg, PrefixStyle.Base128); // Casting msg to object breaks the deserialization code.
    ms.Position = 0;
    Serializer.DeserializeWithLengthPrefix<Message>(ms, PrefixStyle.Base128)
}

Answer 8

这发生在我的例子中，因为我有这样的事情：

var ms = new MemoryStream();
Serializer.Serialize(ms, batch);

_queue.Add(Convert.ToBase64String(ms.ToArray()));

所以基本上我将一个base64放入队列中，然后，在消费者方面我有：

var stream = new MemoryStream(Encoding.UTF8.GetBytes(myQueueItem));
var batch = Serializer.Deserialize<List<EventData>>(stream);

所以虽然每个myQueueItem的类型是正确的，但我忘记我转换了一个字符串。解决方案是再次转换它：

var bytes = Convert.FromBase64String(myQueueItem);
var stream = new MemoryStream(bytes);
var batch = Serializer.Deserialize<List<EventData>>(stream);

Answer 9

当您序列化 ProtoContract 与 1 然后再序列化时，也会发生这种情况
使用另一个 ProtoContract 与 2 反序列化结果。

例如，您更改了 ProtoMember 的订单数量或类型。
不过，您可以使用新数字添加 ProtoMember，而不会破坏反序列化。

Answer 10

using (var fs = File.OpenRead(source))
using (var brotliStream = new BrotliStream(fs, CompressionMode.Fast))
 {
    var index = Serializer.Deserialize<List<Files>>(fs);  <--- Error
 }

就我而言，Brotli 流正在使用源流。反序列化后放置 Brotlistream 后，异常得到修复