Они на самом деле оба действительны ... иш.
Это сводится к "упакованным" полям;без «упакованного» ваши два целых числа кодируются как
- [header, varint] [value] [header, varint] [value]
- [10] [AE-F7-81-80-9F-03] [10] [D4-E4-82-F0-D2-01]
, где, как и в случае с "упакованным", оно становится
- [заголовок, строка] [длина] [значение] [значение]
- [12] [0C] [F9-F6-C3-9D-FA-02] [AE-F7-81-80-9F-03]
примечание: фактические значения выглядят очень разными в двух прогонах ... Я предполагаю, что это случайно.
Чтобы процитировать из спецификации :
Парсеры буферов протокола должны быть в состоянии анализировать повторяющиеся поля, которые были скомпилированы как упакованные, как если бы они не были упакованы, и наоборот.Это позволяет добавлять [pack = true] к существующим полям совместимым образом и обратно.
Итак: сериализаторы должны написать макет, который определяется тем, соответствуют ли ваши данные«упакован» или нет, но декодеры должны справиться с этим в любом случае.В некоторых библиотеках при обнаружении данных, которые должны быть "упакованными": определите, какой макет будет на самом деле короче, и на основании этого принимайте окончательное решение.На самом деле, это может быть приближено к «использованию упакованного кодирования, когда есть хотя бы два элемента».