АСН.1

АСН.1

Обозначение абстрактного синтаксиса один
Статус	Действующий; заменяет X.208 и X.209 (1988 г.)
Год начался	1984
Последняя версия	(02/21) февраль 2021 г.
Организация	ЭТО Т
комитет	17-я Исследовательская комиссия
Базовые стандарты	АСН.1
Сопутствующие стандарты	X.208 , X.209 , X.409 , X.509 , X.680 , X.681 , X.682 , X.683
Домен	криптография , телекоммуникации
Веб-сайт	https://www.itu.int/rec/T-REC-X.680/

Абстрактная синтаксическая нотация One ( ASN.1 ) — это стандартный язык описания интерфейса (IDL) для определения структур данных , которые можно сериализовать и десериализовать кросс-платформенным способом. Он широко используется в телекоммуникациях и компьютерных сетях , и особенно в криптографии .

Разработчики протоколов определяют структуры данных в модулях ASN.1, которые обычно представляют собой раздел более широкого стандартного документа, написанного на языке ASN.1. Преимущество состоит в том, что описание кодирования данных ASN.1 не зависит от конкретного компьютера или языка программирования. Поскольку ASN.1 является одновременно читаемым человеком и машиночитаемым , компилятор ASN.1 может компилировать модули в библиотеки кода, кодеки , которые декодируют или кодируют структуры данных. Некоторые компиляторы ASN.1 могут создавать код для кодирования или декодирования нескольких кодировок, например упакованных, BER или XML .

ASN.1 — это совместный стандарт сектора стандартизации электросвязи Международного союза электросвязи (ITU-T) в 17-й Исследовательской комиссии ITU-T и Международной организации по стандартизации / Международной электротехнической комиссии (ISO/IEC), первоначально определенный в 1984 году как часть CCITT. Х.409 :1984. В 1988 году ASN.1 перешел на собственный стандарт X.208 из-за широкой применимости. Существенно переработанная версия 1995 года относится к серии X.680 . Последней версией серии рекомендаций X.680 является версия 6.0, опубликованная в 2021 году.

Языковая поддержка

ASN.1 — это нотация объявления типа данных. Он не определяет, как манипулировать переменной такого типа. Манипулирование переменными определяется на других языках, таких как SDL (язык спецификации и описания) для исполняемого моделирования или TTCN-3 (нотация тестирования и контроля тестирования) для тестирования на соответствие. Оба этих языка изначально поддерживают объявления ASN.1. Можно импортировать модуль ASN.1 и объявить переменную любого из типов ASN.1, объявленных в модуле.

Приложения

ASN.1 используется для определения большого количества протоколов. Наиболее обширными сферами его применения по-прежнему остаются телекоммуникации, криптография и биометрия.

Протоколы, использующие ASN.1

Протокол	Спецификация	Заданные или общепринятые правила кодирования	Использование
Протокол Interledger	Спецификация ILPV4	Правила кодирования октетов
NTCIP 1103 — протоколы управления транспортом	НТЦИП 1103	Правила кодирования октетов	Управление дорожным движением, транспортом и инфраструктурой
Службы каталогов X.500	Серия рекомендаций ITU X.500	Основные правила кодирования, особые правила кодирования	Сертификаты LDAP, TLS ( X.509 ), аутентификация
Облегченный протокол доступа к каталогам (LDAP)	RFC   4511	Основные правила кодирования
Стандарты криптографии PKCS	PKCS Стандарты криптографии	Основные правила кодирования и особые правила кодирования	Асимметричные ключи, пакеты сертификатов
Обработка сообщений X.400	Серия рекомендаций ITU X.400		Ранний конкурент электронной почты
ЭМВ	Публикации EMVCo		Платежные карты
Мультимедийная конференц-связь T.120	Серия рекомендаций ITU T.120	Базовые правила кодирования, правила пакетного кодирования	Microsoft Протокол удаленного рабочего стола (RDP)
Простой протокол управления сетью (SNMP)	RFC   1157	Основные правила кодирования	Управление и мониторинг сетей и компьютеров, особенно характеристик, касающихся производительности и надежности.
Общий протокол управляющей информации (CMIP)	Рекомендация МСЭ X.711		Конкурент SNMP, но более функциональный и не такой популярный.
Система сигнализации №7 (СС7)	Серия рекомендаций ITU Q.700		Управление телефонными соединениями через коммутируемую телефонную сеть общего пользования (PSTN)
Мультимедийные протоколы серии H	Серия рекомендаций ITU H.200, H.300 и H.400		Голосовая связь по интернет-протоколу (VOIP)
BioAPI (BIP) Протокол взаимодействия	ИСО/МЭК 24708:2008
Общая структура форматов обмена биометрическими данными (CBEFF)	НИСТ ИР 6529-А	Основные правила кодирования
Контексты аутентификации для биометрии (ACBio)	ИСО/МЭК 24761:2019
Телекоммуникационные приложения с компьютерной поддержкой (CSTA)	[1]	Основные правила кодирования
Выделенная связь ближнего действия (DSRC)	САЭ Дж2735	Правила упакованного кодирования	Автомобильная связь
IEEE 802.11p (IEEE ВОЛНА)	ИЭЭЭ 1609.2		Автомобильная связь
Интеллектуальные транспортные системы (ETSI ITS)	ПОИСК EN 302 637 2 (CAM) ПОИСК EN 302 637 3 (DENM)	Невыровненные правила упакованного кодирования	Автомобильная связь
Глобальная система мобильной связи (GSM)	[2]		2G Мобильная связь
Служба пакетной радиосвязи общего назначения (GPRS) / Повышенная скорость передачи данных для эволюции GSM (EDGE)	[3]		2.5G Связь через мобильный телефон
Универсальная система мобильной связи (UMTS)	[4]		3G Мобильная связь
Долгосрочная эволюция (LTE)	[5]		4G Мобильная связь
5G	[6]		5G Мобильная связь
Общий протокол оповещения (CAP)	[7]	Правила кодирования XML	Обмен информацией о предупреждениях, например желтыми оповещениями
Связь диспетчер-пилот по каналу передачи данных (CPDLC)			Аэронавтика связи
Услуги расширения Space Link (SLE)			Космические системы связи
Спецификация производственного сообщения (MMS)	ИСО 9506-1:2003		Производство
Передача файлов, доступ и управление (FTAM)			Ранний и более мощный конкурент протокола передачи файлов, но он больше не используется.
Протокол элемента службы удаленных операций (ROSE)	Рекомендации МСЭ X.880, X.881 и X.882		Ранняя форма удаленного вызова процедур.
Элемент службы управления ассоциациями (ACSE)	Рекомендация МСЭ X.227
Протокол сетей автоматизации и управления зданиями (BACnet)	АШРАЭ 135-2020	Правила кодирования BACnet	Автоматизация и контроль зданий, например, с помощью пожарной сигнализации, лифтов, систем отопления, вентиляции и кондиционирования и т. д.
Керберос	RFC   4120	Основные правила кодирования	Безопасная аутентификация
WiMAX 2			Глобальные сети
Интеллектуальная сеть	Серия рекомендаций ITU Q.1200		Телекоммуникации и компьютерные сети
X2AP		Основные правила пакетного кодирования с выравниванием
Интерфейс передачи обслуживания законного перехвата (LI)	ЕТСИ ТС 102 232-1		Законный перехват

Кодировки

ASN.1 тесно связан с набором правил кодирования, которые определяют, как представлять структуру данных в виде последовательности байтов. Стандартные правила кодирования ASN.1 включают:

Правила кодирования ASN.1

Правила кодирования	Идентификатор объекта		Значение дескриптора объекта	Спецификация	Единица сериализации	Закодированные элементы различимый без предвидение спецификация	Октет выровнен	Управление кодированием определены правила обозначений	Описание
	Пунктирный	ЭТО
Основные правила кодирования (до)	2.1.1	/ASN.1/Basic-Encoding	Базовая кодировка одного типа ASN.1	ЭТО X.690	Октет	Да	Да	Нет	Первые заданные правила кодирования. Кодирует элементы как последовательности значений длины тега (TLV). Обычно предоставляет несколько вариантов кодирования значений данных. Это одно из самых гибких правил кодирования.
Отличительные правила кодирования (ТО)	2.1.2.1	/ASN.1/BER‑Derived/ Выдающееся кодирование	Отличительная кодировка одного типа ASN.1.	ЭТО X.690	Октет	Да	Да	Нет	Ограниченное подмножество основных правил кодирования (BER). Обычно используется для вещей, имеющих цифровую подпись, поскольку, поскольку DER допускает меньше вариантов кодирования и поскольку значения, закодированные в DER, с большей вероятностью будут перекодированы в одних и тех же байтах, цифровые подписи, созданные данным абстрактным значением, будут быть одинаковыми для всех реализаций, а цифровые подписи, созданные на основе данных, закодированных в DER, будут менее подвержены атакам на основе коллизий.
Правила канонического кодирования (ЦЕР)	2.1.2.0	/ASN.1/ BER‑производный/ Каноническое кодирование	Каноническое кодирование одного типа ASN.1	ЭТО X.690	Октет	Да	Да	Нет	Ограниченное подмножество основных правил кодирования (BER). Использует почти все те же ограничения, что и Distinguished Encoding Rules (DER), но примечательное отличие состоит в том, что CER определяет, что многие большие значения (особенно строки) должны быть «разбиты» на отдельные элементы подстроки длиной 1000 байт или Знак длиной 1000 символов (в зависимости от типа данных).
Базовый упакованный Правила кодирования (PER) Выровнено	2.1.3.0.0	/ASN.1/ Упакованное кодирование/ Базовый/согласованный	Упакованное кодирование одного типа ASN.1 (выровнено по базовому принципу)	ЭТО X.691	Кусочек	Нет	Да	Нет	Кодирует значения в битах, но если закодированные биты не делятся на восемь без остатка, биты заполнения добавляются до тех пор, пока целое число октетов не закодирует значение. Способен создавать очень компактные кодировки, но за счет сложности, и PER сильно зависит от ограничений, налагаемых на типы данных.
Базовый упакованный Правила кодирования (PER)	2.1.3.0.1	/ASN.1/ Упакованное кодирование/ Базовый/без согласования	Упакованная кодировка одного типа ASN.1 (базовая без выравнивания)	ЭТО X.691	Кусочек	Нет	Нет	Нет	Вариант базовых правил пакетного кодирования Aligned (PER), но он не дополняет значения данных битами для получения целого числа октетов.
Канонический упакованный Правила кодирования (CPER) Согласовано	2.1.3.1.0	/ASN.1/ Упакованное кодирование/ Канонический/выровненный	Упакованное кодирование одного типа ASN.1 (каноническое выравнивание)	ЭТО X.691	Кусочек	Нет	Да	Нет	Вариант правил пакетного кодирования (PER), определяющий единый способ кодирования значений. Канонические правила пакетного кодирования имеют такое же отношение к правилам пакетного кодирования, как особые правила кодирования (DER) и канонические правила кодирования (CER) к основным правилам кодирования (BER).
Канонический упакованный Правила кодирования (CPER)	2.1.3.1.1	/ASN.1/ Упакованное кодирование/ Канонический/Несогласованный	Упакованная кодировка одного типа ASN.1 (каноническая без выравнивания)	ЭТО X.691	Кусочек	Нет	Нет	Нет	Вариант согласованных канонических правил пакетного кодирования (CPER), но он не дополняет значения данных битами для получения целого числа октетов.
Базовый XML Правила кодирования (ученик)	2.1.5.0	/ASN.1/XML‑Encoding/ Базовый	Базовое XML-кодирование одного типа ASN.1.	ЭТО X.693	Характер	Да	Да	Да	Кодирует данные ASN.1 в формате XML.
Канонический XML Правила кодирования (CXER)	2.1.5.1	/ASN.1/XML‑Encoding/ Канонический	Каноническое XML-кодирование одного типа ASN.1	ЭТО X.693	Характер	Да	Да	Да
Расширенный XML Правила кодирования (ЭКСЕР)	2.1.5.2	/ASN.1/XML‑Encoding/ Расширенный	Расширенное XML-кодирование одного типа ASN.1.	ЭТО X.693	Характер	Да	Да	Да
Октет Правила кодирования (НАД)	2.1.6.0		Базовое кодирование OER одного типа ASN.1	ЭТО X.696	Октет	Нет	Да		Набор правил кодирования, который кодирует значения в октетах, но не кодирует теги или определители длины, такие как базовые правила кодирования (BER). Значения данных, закодированные с использованием правил октетного кодирования, часто выглядят так же, как в протоколах, основанных на записях. Правила октетного кодирования (OER) были разработаны с учетом простоты реализации и создания более компактных кодировок, чем те, которые создаются с помощью основных правил кодирования (BER). Помимо сокращения усилий по разработке кодеров/декодеров, использование OER может снизить использование полосы пропускания (хотя и не так сильно, как правила пакетного кодирования), сэкономить циклы ЦП и снизить задержку кодирования/декодирования.
Канонический Правила кодирования (НАД)	2.1.6.1		Каноническое кодирование OER одного типа ASN.1	ЭТО X.696	Октет	Нет	Да
JSON Правила кодирования (ПОТОМУ ЧТО)				ЭТО X.697	Характер	Да	Да	Да	Кодирует данные ASN.1 в формате JSON.
Общая строка Правила кодирования (ГСЭР)	1.2.36. 79672281. 0.0		Общие правила кодирования строк (GSER)	RFC   3641	Характер		Да	Нет	Неполная спецификация правил кодирования, которые создают удобочитаемые значения. Целью GSER является представление пользователю закодированных данных или входных данных пользователя в очень простом формате. GSER изначально был разработан для облегченного протокола доступа к каталогам (LDAP) и редко используется за его пределами. Использование GSER в реальных протоколах не рекомендуется, поскольку не все кодировки символьных строк, поддерживаемые ASN.1, могут быть воспроизведены в нем.
BACnet Правила кодирования				АШРАЭ 135	Октет	Да	Да	Да	Кодирует элементы как последовательности значений длины тега (TLV), например, Базовые правила кодирования (BER).
Специальная сигнализация Правила кодирования (БЫТЬ)				Внутренний документ по исследованиям и разработкам France Telecom	Октет	Да	Да		Используется в основном в протоколах, связанных с телекоммуникациями, таких как GSM и SS7. Разработан для создания идентичной кодировки из ASN.1, которую создавали ранее существовавшие протоколы, не указанные в ASN.1.
Легкий Правила кодирования (ЛВЭР)				Внутренний документ INRIA.	Слово памяти		Да		Происходит из внутреннего документа, созданного INRIA, с подробным описанием «облегченного синтаксиса плоского дерева» (FTLWS). Отменено в 1997 году из-за превосходной производительности правил пакетного кодирования (PER). Опционально передача с прямым или прямым порядком байтов, а также 8-битные, 16-битные и 32-битные слова памяти. (Следовательно, существует шесть вариантов, поскольку существует шесть комбинаций этих вариантов.)
Минимальный бит Правила кодирования (МБЕР)					Кусочек				Предложено в 1980-е гг. Он должен быть максимально компактным, как правила пакетного кодирования (PER).
NEMA упакованный Правила кодирования					Кусочек				Неполная спецификация правил кодирования, созданная NEMA. Он неполный, поскольку не может кодировать и декодировать все типы данных ASN.1. Компактный, как правила пакетного кодирования (PER).
Высокоскоростной Правила кодирования				«Правила кодирования для высокоскоростных сетей»					Определение этих правил кодирования стало побочным продуктом работы INRIA над облегченным синтаксисом плоского дерева (FTLWS).

Обозначение управления кодированием

Рекомендации ASN.1 предоставляют ряд предопределенных правил кодирования. Если ни одно из существующих правил кодирования не подходит, нотация управления кодированием (ECN) предоставляет пользователю возможность определить свои собственные правила кодирования.

Связь с кодированием почты с улучшенной конфиденциальностью (PEM)

Кодирование почты с улучшенной конфиденциальностью (PEM) совершенно не связано с ASN.1 и его кодеками, но закодированные данные ASN.1, которые часто являются двоичными, часто кодируются с помощью PEM, чтобы их можно было передавать в виде текстовых данных, например, через ретрансляторы SMTP. или через буферы копирования/вставки.

Пример

Это пример модуля ASN.1, определяющего сообщения (структуры данных) вымышленного протокола Foo :

FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER,
        question       IA5String
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER,
        answer         BOOLEAN
    }

END

Это может быть спецификация, опубликованная создателями протокола Foo. Потоки диалога, обмен транзакциями и состояния не определены в ASN.1, но оставлены для других обозначений и текстового описания протокола.

Предполагая, что сообщение соответствует протоколу Foo и будет отправлено принимающей стороне, это конкретное сообщение ( блок данных протокола (PDU)) будет следующим:

myQuestion FooQuestion ::= {
    trackingNumber     5,
    question           "Anybody there?"
}

ASN.1 поддерживает ограничения на значения и размеры, а также расширяемость. Приведенную выше спецификацию можно изменить на

FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER(0..199),
        question       IA5String
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER(10..20),
        answer         BOOLEAN
    }

    FooHistory ::= SEQUENCE {
        questions SEQUENCE(SIZE(0..10)) OF FooQuestion,
        answers   SEQUENCE(SIZE(1..10)) OF FooAnswer,
        anArray   SEQUENCE(SIZE(100))  OF INTEGER(0..1000),
        ...
    }

END

Это изменение ограничивает TrackNumbers значениями от 0 до 199 включительно, а для вопросов вопросов — значениями от 10 до 20 включительно. Размер массива вопросов может составлять от 0 до 10 элементов, а массив ответов — от 1 до 10 элементов. Поле anArray представляет собой массив целых чисел фиксированной длины из 100 элементов, которые должны находиться в диапазоне от 0 до 1000. Маркер расширяемости '...' означает, что спецификация сообщения FooHistory может иметь дополнительные поля в будущих версиях спецификации; системы, совместимые с одной версией, должны иметь возможность получать и передавать транзакции из более поздней версии, но при этом обрабатывать только поля, указанные в более ранней версии. Хорошие компиляторы ASN.1 генерируют (на C, C++, Java и т. д.) исходный код, который автоматически проверяет, подпадают ли транзакции под эти ограничения. Транзакции, нарушающие ограничения, не должны приниматься или представляться приложению. Управление ограничениями на этом уровне значительно упрощает спецификацию протокола, поскольку приложения будут защищены от нарушений ограничений, что снижает риск и затраты.

Чтобы отправить сообщение myQuestion через сеть, сообщение сериализуется (кодируется) как последовательность байтов с использованием одного из правил кодирования . Спецификация протокола Foo должна явно указывать один набор правил кодирования, который следует использовать, чтобы пользователи протокола Foo знали, какой из них им следует использовать и чего ожидать.

Пример, закодированный в DER

Ниже приведена структура данных, показанная выше в виде myQuestion, закодированная в формате DER (все числа указаны в шестнадцатеричном формате):

30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

DER — это кодировка тип-длина-значение , поэтому приведенную выше последовательность можно интерпретировать со ссылкой на стандартные типы SEQUENCE, INTEGER и IA5String следующим образом:

30 — type tag indicating SEQUENCE
13 — length in octets of value that follows
  02 — type tag indicating INTEGER
  01 — length in octets of value that follows
    05 — value (5)
  16 — type tag indicating IA5String 
     (IA5 means the full 7-bit ISO 646 set, including variants, 
      but is generally US-ASCII)
  0e — length in octets of value that follows
    41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — value ("Anybody there?")

Пример, закодированный в XER

В качестве альтернативы можно закодировать ту же самую структуру данных ASN.1 с помощью правил кодирования XML (XER), чтобы добиться большей читабельности для человека «по сети». Тогда он будет выглядеть следующим образом: 108 октетов (в число пробелов входят пробелы, используемые для отступов):

<FooQuestion>
    <trackingNumber>5</trackingNumber>
    <question>Anybody there?</question>
</FooQuestion>

Пример, закодированный в PER (без выравнивания)

Альтернативно, если правила пакетного кодирования используются , будут созданы следующие 122 бита (16 октетов составляют 128 бит, но здесь только 122 бита несут информацию, а последние 6 бит являются просто дополнением):

01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0

В этом формате теги типов для необходимых элементов не кодируются, поэтому его невозможно проанализировать, не зная ожидаемых схем, используемых для кодирования. Кроме того, байты значения IA5String упаковываются с использованием 7-битных единиц вместо 8-битных, поскольку кодер знает, что для кодирования значения байта IA5String требуется только 7 бит. Однако байты длины здесь по-прежнему закодированы, даже для первого целочисленного тега 01 (но упаковщик PER может также опустить его, если он знает, что допустимый диапазон значений умещается в 8 битах, и он может даже сжать байт с одним значением 05 с меньшими затратами). чем 8 бит, если он знает, что разрешенные значения могут помещаться только в меньший диапазон).

Последние 6 бит закодированного PER дополняются нулевыми битами в 6 младших битах последнего байта c0: эти дополнительные биты не могут быть переданы или использованы для кодирования чего-либо еще, если эта последовательность вставлена ​​как часть более длинной невыровненной последовательности. Последовательность ПЕР.

Это означает, что невыровненные данные PER по сути представляют собой упорядоченный поток битов, а не упорядоченный поток байтов, как в случае с выровненным PER, и что их будет немного сложнее декодировать программно на обычных процессорах, поскольку для этого потребуются дополнительные контекстные битовые данные. сдвиг и маскирование, а не прямая адресация байтов (но то же самое замечание справедливо и для современных процессоров и модулей памяти/памяти, минимальная адресуемая единица которых превышает 1 октет). Однако современные процессоры и процессоры обработки сигналов включают в себя аппаратную поддержку быстрого внутреннего декодирования битовых потоков с автоматической обработкой вычислительных единиц, выходящих за границы адресных единиц хранения (это необходимо для эффективной обработки в кодеках данных для сжатия/декомпрессии или с некоторым шифрованием). алгоритмы дешифрования).

Если бы требовалось выравнивание по границам октетов, выровненный кодер PER выдал бы:

01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

(в этом случае каждый октет дополняется индивидуально нулевыми битами в неиспользуемых старших битах).

Инструменты

Большинство инструментов, поддерживающих ASN.1, выполняют следующие действия:

• проанализировать файлы ASN.1,
• генерирует эквивалентное объявление на языке программирования (например, C или C++),
• генерирует функции кодирования и декодирования на основе предыдущих объявлений.

Список инструментов, поддерживающих ASN.1, можно найти на веб-странице инструментов ITU-T .

Онлайн-инструменты

• АСН1 Играть
• Веб-инструмент ASN1 (очень ограниченный)
• Детская площадка ASN1 (песочница)
• Декодер JavaScript ASN.1

Сравнение с аналогичными схемами

ASN.1 по назначению и использованию аналогичен буферам протоколов Google и Apache Thrift , которые также являются языками описания интерфейса для кросс-платформенной сериализации данных. Как и эти языки, он имеет схему (в ASN.1 называемую «модулем») и набор кодировок, обычно кодировок тип-длина-значение. В отличие от них, ASN.1 не предоставляет единой и удобной для использования реализации с открытым исходным кодом и публикуется как спецификация для реализации сторонними поставщиками. Однако ASN.1, определенный в 1984 году, на много лет старше их. Он также включает более широкий спектр базовых типов данных, некоторые из которых устарели, и имеет больше возможностей для расширения. Одно сообщение ASN.1 может включать данные из нескольких модулей, определенных в нескольких стандартах, даже в стандартах, определенных с разницей в годы.

ASN.1 также включает встроенную поддержку ограничений на значения и размеры. Например, модуль может указать целочисленное поле, которое должно находиться в диапазоне от 0 до 100. Также можно указать длину последовательности значений (массива) либо в виде фиксированной длины, либо в виде диапазона разрешенных длин. Ограничения также могут быть определены как логические комбинации наборов базовых ограничений.

Значения, используемые в качестве ограничений, могут быть либо литералами, используемыми в спецификации PDU, либо значениями ASN.1, указанными в другом месте файла схемы. Некоторые инструменты ASN.1 делают эти значения ASN.1 доступными для программистов в сгенерированном исходном коде. Используемые в качестве констант для определяемого протокола, разработчики могут использовать их в реализации логики протокола. Таким образом, все PDU и константы протокола могут быть определены в схеме, и все реализации протокола на любом поддерживаемом языке основаны на этих значениях. Это избавляет разработчиков от необходимости передавать константы протокола кода в исходный код своей реализации. Это существенно облегчает разработку протокола; константы протокола могут быть изменены в схеме ASN.1, и все реализации обновляются просто путем перекомпиляции, что способствует быстрому циклу разработки с низким уровнем риска.

Если инструменты ASN.1 правильно реализуют проверку ограничений в сгенерированном исходном коде, это позволяет автоматически проверять данные протокола во время работы программы. Обычно инструменты ASN.1 включают проверку ограничений в сгенерированные процедуры сериализации/десериализации, выдачу ошибок или исключений в случае обнаружения данных, выходящих за пределы допустимого диапазона. Сложно реализовать все аспекты ограничений ASN.1 в компиляторе ASN.1. Не все инструменты поддерживают весь спектр возможных выражений ограничений. Схема XML и схема JSON поддерживают схожие концепции ограничений. Инструментальная поддержка ограничений варьируется. Компилятор Microsoft xsd.exe игнорирует их.

ASN.1 визуально похож на расширенную форму Бэкуса-Наура (ABNF), которая используется для определения многих интернет-протоколов, таких как HTTP и SMTP . Однако на практике они совершенно разные: ASN.1 определяет структуру данных, которая может быть закодирована различными способами (например, JSON, XML, двоичный код). ABNF, с другой стороны, определяет кодировку («синтаксис») одновременно с определением структуры данных («семантика»). ABNF, как правило, используется чаще для определения текстовых, удобочитаемых протоколов и обычно не используется для определения кодировок тип-длина-значение.

Многие языки программирования определяют форматы сериализации, специфичные для языка. Например, модуль «pickle» Python и модуль «Marshal» Ruby. Эти форматы обычно зависят от языка. Им также не требуется схема, что упрощает их использование в сценариях специального хранения, но они не подходят для протоколов связи.

JSON и XML также не требуют схемы, что упрощает их использование. Они также являются кросс-платформенными стандартами, которые широко популярны для протоколов связи, особенно в сочетании со схемой JSON или схемой XML .

Некоторые инструменты ASN.1 могут выполнять преобразование между ASN.1 и схемой XML (XSD). Перевод стандартизирован ITU. Это позволяет определить протокол в ASN.1, а также автоматически в XSD. Таким образом, возможно (хотя, возможно, и опрометчиво) иметь в проекте схему XSD, компилируемую инструментами ASN.1, создающими исходный код, который сериализует объекты в/из проводного формата JSON. Более практичное использование — разрешить другим подпроектам использовать схему XSD вместо схемы ASN.1, что, возможно, соответствует доступности инструментов для выбранного языка подпроектов, с использованием XER в качестве формата протокола.

Подробнее см. Сравнение форматов сериализации данных .

См. также

• Х.690
• Класс информационного объекта (ASN.1)
• Уровень представления

Внешние ссылки

• Руководство для непрофессионалов по подмножеству ASN.1, BER и DER. Хорошее введение для новичков.
• Веб-сайт МСЭ-Т — Введение в ASN.1
• Видео-знакомство с ASN.1
• Учебное пособие по ASN.1 Учебное пособие по основным концепциям ASN.1
• Учебное пособие по ASN.1 Учебное пособие по ASN.1
• Компилятор ASN.1->C++ с открытым исходным кодом; Включает некоторые спецификации ASN.1. , Онлайн-компилятор ASN.1->C++.
• Декодер ASN.1 Позволяет декодировать сообщения, закодированные ASN.1, в выходные данные XML.
• Средство проверки синтаксиса ASN.1 и кодер/декодер. Проверяет синтаксис схемы ASN.1 и кодирует/декодирует сообщения.
• Кодер/декодер ASN.1 сообщений 3GPP Кодирует/декодирует сообщения ASN.1 3GPP и позволяет легко редактировать эти сообщения.
• Бесплатные книги об ASN.1
• Список инструментов ASN.1 в проекте IvmaiAsn
• Обзор правил октетного кодирования (OER)
• Обзор правил кодирования JSON (JER)
• Утилита узла Typescript для анализа и проверки сообщений ASN.1.