Это, безусловно, не зависит от реализации. То есть, если разные реализации обрабатывают это по-разному, одна из них делает это неправильно. Если вы перейдете к декодированию неизвестных полей с помощью декодера, который не ожидает неизвестных полей, декодирование должно завершиться ошибкой. Он не будет пропускать неизвестные поля.
Однако есть способ предусмотреть дополнительные поля еще до того, как они станут известны. Он заключается в использовании маркера расширения ("..."). Допустим, мы разрабатываем различные версии спецификации ASN.1. Назовем их V1, V2, V3 и т. д. V1 — это исходная спецификация, но мы понимаем, что в то время, когда мы проектируем V1, нам, вероятно, придется изменить ее в какой-то момент. Чтобы разрешить это, вместо чего-то вроде
Z ::= SEQUENCE { a INTEGER,
b OCTET STRING,
c Message1
}
мы бы объявили Z расширяемым вот так
Z ::= SEQUENCE { a INTEGER,
b OCTET STRING,
c Message1,
...
}
Маркер расширения говорит, что после c могут быть другие поля, которые пока неизвестны. Декодер должен рассматривать сообщения, содержащие такие поля, если они следуют за c, как допустимые. Декодер не сможет их декодировать, поскольку он не знает, какими они должны быть, но знает, что они допустимы.
Допустим, мы обновляем V1 до V2, вставляя два новых поля примерно так:
Z ::= SEQUENCE { a INTEGER, -- V1
b OCTET STRING, -- V1
c Message1, -- V1
...,
[[ d PrintableString, -- V2
e BOOLEAN ]] -- V2
}
В этом случае версия V1 может взаимодействовать с версией V2. Кодировщик V1 не будет включать d или e, а кодировщик V2 будет включать их. С точки зрения декодера, декодер V1 будет принимать (но не декодировать) d и e, тогда как декодер V2 будет декодировать d и e, если они будут найдены. Таким образом, декодер V1 будет принимать кодировки как V1, так и V2, игнорируя d и e всякий раз, когда они будут найдены; декодер V2 также будет принимать кодировку как V1, так и V2, отметив, что кодировка V1 не будет включать d или e, но остается действительной.
Мы можем продолжить это через дополнительные версии, например,
Z ::= SEQUENCE { a INTEGER, -- V1
b OCTET STRING, -- V1
c Message1, -- V1
...,
[[ d PrintableString, -- V2
e BOOLEAN ]], -- V2
[[ f PrintableString, -- V3
g ExtensionMessage]] -- V3
}
где V1, V2 и V3 могут взаимодействовать.
Обратите внимание, однако, что, поскольку мы имеем дело с ПОСЛЕДОВАТЕЛЬНОСТЬЮ, порядок должен быть сохранен. У вас не может быть ни e без d, ни g без d, e и f.
Таким образом, можно сделать вывод, что если ваше определение типа включает маркеры расширения, вы можете добавлять новые поля, а если нет, то не можете.
person
Conrad Sigona
schedule
01.03.2010
