АСН.1
в этой статье Использование внешних ссылок может не соответствовать политике и рекомендациям Википедии . ( Июль 2024 г. ) |
Обозначение абстрактного синтаксиса один | |
Статус | Действующий; заменяет 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) для определения структур данных , которые можно сериализовать и десериализовать кросс-платформенным способом. Он широко используется в телекоммуникациях и компьютерных сетях , и особенно в криптографии . [ 1 ]
Разработчики протоколов определяют структуры данных в модулях 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. [ 2 ] В 1988 году ASN.1 перешел на собственный стандарт X.208 из-за широкой применимости. Существенно переработанная версия 1995 года относится к серии X.680 . [ 3 ] Последней версией серии рекомендаций X.680 является версия 6.0, опубликованная в 2021 году. [ 4 ]
Языковая поддержка
[ редактировать ]ASN.1 — это нотация объявления типа данных. Он не определяет, как манипулировать переменной такого типа. Манипуляции с переменными определены на других языках, таких как SDL (язык спецификации и описания) для исполняемого моделирования или TTCN-3 (нотация тестирования и контроля тестирования) для тестирования на соответствие. Оба этих языка изначально поддерживают объявления 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 включают:
Правила кодирования
|
Идентификатор объекта | Значение дескриптора объекта | Спецификация
|
Единица сериализации
|
Закодированные элементы
различимый без предвидение спецификация |
Октет выровнен
|
Управление кодированием
определены правила обозначений |
Описание | |
---|---|---|---|---|---|---|---|---|---|
Пунктирный | ЭТО | ||||||||
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/ |
Каноническое кодирование одного типа ASN.1 | ЭТО X.690 | Октет | Да | Да | Нет | Ограниченное подмножество основных правил кодирования (BER). Использует почти все те же ограничения, что и Distinguished Encoding Rules (DER), но примечательное отличие состоит в том, что CER определяет, что многие большие значения (особенно строки) должны быть «разбиты» на отдельные элементы подстроки длиной 1000 байт или Знак длиной 1000 символов (в зависимости от типа данных). | |
2.1.3.0.0 | /ASN.1/ |
Упакованное кодирование одного типа ASN.1 (выровнено по базовому принципу) | ЭТО X.691 | Кусочек | Нет | Да | Нет | Кодирует значения в битах, но если закодированные биты не делятся на восемь без остатка, биты заполнения добавляются до тех пор, пока целое число октетов не закодирует значение. Способен создавать очень компактные кодировки, но за счет сложности, и PER сильно зависит от ограничений, налагаемых на типы данных. | |
2.1.3.0.1 | /ASN.1/ |
Упакованная кодировка одного типа ASN.1 (базовая без выравнивания) | ЭТО X.691 | Кусочек | Нет | Нет | Нет | Вариант базовых правил пакетного кодирования Aligned (PER), но он не дополняет значения данных битами для получения целого числа октетов. | |
2.1.3.1.0 | /ASN.1/ |
Упакованное кодирование одного типа ASN.1 (каноническое выравнивание) | ЭТО X.691 | Кусочек | Нет | Да | Нет | Вариант правил пакетного кодирования (PER), определяющий единый способ кодирования значений. Канонические правила пакетного кодирования имеют такое же отношение к правилам пакетного кодирования, как особые правила кодирования (DER) и канонические правила кодирования (CER) к основным правилам кодирования (BER). | |
2.1.3.1.1 | /ASN.1/ |
Упакованная кодировка одного типа ASN.1 (каноническая без выравнивания) | ЭТО X.691 | Кусочек | Нет | Нет | Нет | Вариант согласованных канонических правил пакетного кодирования (CPER), но он не дополняет значения данных битами для получения целого числа октетов. | |
2.1.5.0 | /ASN.1/XML‑Encoding/ |
Базовое XML-кодирование одного типа ASN.1. | ЭТО X.693 | Характер | Да | Да | Да | Кодирует данные ASN.1 в формате XML. | |
2.1.5.1 | /ASN.1/XML‑Encoding/ |
Каноническое XML-кодирование одного типа ASN.1 | ЭТО X.693 | Характер | Да | Да | Да | ||
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 | Октет | Нет | Да | ||||
ЭТО X.697 | Характер | Да | Да | Да | Кодирует данные ASN.1 в формате JSON. | ||||
1.2.36. |
Общие правила кодирования строк (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 включительно, а для вопросомNumbers — значением от 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 в качестве формата протокола.
Подробнее см. Сравнение форматов сериализации данных .
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ «Введение в АСН.1» . МСЭ . Архивировано из оригинала 9 апреля 2021 г. Проверено 9 апреля 2021 г.
- ^ «База данных рекомендаций МСЭ-Т» . МСЭ . Проверено 6 марта 2017 г.
- ^ ITU-T X.680 - Спецификация основных обозначений
- ^ Эта статья основана на материалах, взятых из ASN.1 в Бесплатном онлайн-словаре вычислительной техники до 1 ноября 2008 г. и включенных в соответствии с условиями «повторного лицензирования» GFDL версии 1.3 или более поздней.
- ^ ITU-T X.690 - Основные правила кодирования (BER)
- ^ ITU-T X.690 - Отличительные правила кодирования (DER)
- ^ ITU-T X.690 - Канонические правила кодирования (CER)
- ^ Jump up to: а б с д ITU-T X.691 — Правила пакетного кодирования (PER)
- ^ Jump up to: а б с ITU-T X.693 — Правила кодирования XML (XER)
- ^ Jump up to: а б ITU-T X.696 — Правила октетного кодирования (OER)
- ^ ITU-T X.697 - Правила кодирования нотации объектов JavaScript (JER)
- ^ RFC 3641 — Общие правила кодирования строк (GSER)
Внешние ссылки
[ редактировать ]- Руководство для непрофессионалов по подмножеству 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.