Ограничения одного значения в кодировке PER
Насколько я понимаю, в следующем утверждении X.691 говорится, что типы INTEGER с ограничениями на одно значение ничего не будут кодировать.
13.2.1 Если ограничения, видимые для PER, ограничивают целочисленное значение одним значением, то не должно быть никаких дополнений к списку полей, завершающих эти процедуры.
Я также понимаю, что в ASN.1 ничего не закодировано, как показано ниже. и я протестировал его с помощью asn1tools в Python.
Num1 ::= INTEGER (40)
Input: Num1 = 40
Output: b'' (Empty bit string)
При использовании объединения для ограничений с одним значением нет гарантии, что закодированное значение всегда будет одинаковым. Однако с помощью asn1tools в Python ничего не кодируется.
Num2 ::= INTEGER (40 | 50 | 60)
Encoding:
Input: Num2 = 40
Output: b'' (Empty bit string)
Input: Num2 = 50
Output: b'' (Empty bit string)
Input: Num2 = 60
Output: b'' (Empty bit string)
Decoding:
Input: b'' (Empty bit string)
Output: 40
Я предполагал, что он будет следовать кодировке типа ENUMERATED, но не нашел для этого основы в X.691.
Мне интересно, правильно ли, что в приведенном выше случае ничего не кодируется, и не является ли это больше ограничением на одно значение при использовании объединения.
Любая помощь приветствуется.
Ответы 1
Это ограничение используемого вами инструмента...
Если вы попробуете https://asn1.io/, вы увидите следующие результаты.
Num2 ::= INTEGER (40 | 50 | 60)
Encoding:
Input: Num2 = 40
Output: b'00000000' (0x00 - No bits set)
Input: Num2 = 50
Output: b'01010000' (0x50)
Input: Num2 = 60
Output: b'10100000' (0xA0)
Спасибо Полу за объяснение в комментариях, как это получить из документа X691...
Диапазон INTEGER: 60-40=20.
«диапазон» меньше или равен 255 (случай битового поля), нам нужно 5 бит
Для этого необходимо создать битовое поле из 5 бит, содержащее значение («n» – «нижняя граница») в качестве кодирование неотрицательных двоичных целых чисел в битовом поле, как указано в 11.3.
Битовое поле будет содержать 0 для значения 40, 10 для значения 50 и 20 для значения 60.
Итак, вы получаете кодировку трех возможных значений Num2.
- 40: кодируем 0 на 5 битах: 00000
- 50: кодируем 10 по 5 бит: 01010
- 60: кодируем 20 по 5 бит: 10100
Вы обнаружите, что шестнадцатеричное значение выше дополнения 3 битами установлено в 0.
Я только что попробовал это на asn1.io, и кодировка значения 40 не b'', а 0x00, поскольку нижняя граница ограничения равна 40, которая кодируется как 0x00, поскольку нижняя граница вычитается перед кодированием значения. Обратите внимание, что диапазон ограничений требует только первых 5 бит для кодирования значений. Вот почему вы видите 0x50 для 50 и 0xA0 для 60.
Я отредактировал ответ ЯФреда, чтобы более точно отразить результат с сайта asn1.io.
упс, спасибо за исправление и спасибо за объяснение
Казалось бы, когда ограничения с одним значением объединяются, их следует кодировать как ограниченное целое число, где верхняя граница является наибольшим из ограничений, а нижняя граница — наименьшим. Я буду использовать asn1.io, который Прад любезно указал мне для дальнейшего изучения x.691. Я хотел бы выразить благодарность ЯФреду, Кевину и Полу за их ответы.
Да. Следует иметь в виду, что наличие ограничения не предполагает, что оно закодировано в PER. Таким образом, объединение используется для проверки значения INTEGER (40|50|60), но видимое ограничение PER на самом деле равно (40..60).
Я не особо внимательно читал X.691, поэтому не хочу однозначно утверждать, что инструмент выдает неправильные кодировки, но я так думаю. На первый взгляд, этот тип должен быть закодирован как ограниченное целое число в диапазоне 60-40+1=21, и тогда закодированное значение будет относиться к нижней границе (40). Я уверен, что кто-нибудь из OSS (создателя этого инструмента) прокомментирует.