Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску
ASN.1
Первая абстрактная синтаксическая нотация
СтатусДействующий; заменяет X.208 и X.209 (1988)
Год начался1995 г.
Последняя версия(08/15)
августа 2015
ОрганизацияITU-T
Базовые стандартыASN.1
Связанные стандартыX.208 , X.209 , X.680, X.681, X.682, X.683
Доменкриптография , телекоммуникации
Веб-сайтhttps://www.itu.int/rec/T-REC-X.680/en

Абстрактная синтаксическая нотация 1 ( ASN.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 X.409: 1984. [1] В 1988 году ASN.1 перешла на собственный стандарт X.208 из-за широкой применимости. Существенно переработанная версия 1995 года входит в серию X.680 . [2] Последней версией серии рекомендаций X.680 является версия 5.0, опубликованная в 2015 году.

Языковая поддержка [ править ]

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

Приложения [ править ]

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

Протоколы, использующие ASN.1
ПротоколСпецификацияУстановленные или обычные правила кодированияИспользует
Протокол Interledgerhttps://interledger.org/rfcs/asn1/index.htmlПравила кодирования октетов
NTCIP 1103 - Протоколы управления транспортомNTCIP 1103Правила кодирования октетовУправление дорожным движением, транспортом и инфраструктурой
Службы каталогов X.500Серия рекомендаций ITU X.500Основные правила кодирования, особые правила кодированияСертификаты LDAP, TLS ( X.509 ), аутентификация
Облегченный протокол доступа к каталогам (LDAP)RFC  4511Основные правила кодирования
Стандарты криптографии PKCSСтандарты криптографии PKCSОсновные правила кодирования и особые правила кодированияАсимметричные ключи, пакеты сертификатов
Обработка сообщений X.400Серия рекомендаций ITU X.400Один из первых конкурентов по электронной почте
EMVПубликации EMVCoПлатежные карты
Мультимедийная конференц-связь T.120Серия рекомендаций ITU T.120Основные правила кодирования, упакованные правила кодированияПротокол удаленного рабочего стола Microsoft (RDP)
Простой протокол управления сетью (SNMP)RFC  1157Основные правила кодированияУправление и мониторинг сетей и компьютеров, особенно характеристик, касающихся производительности и надежности.
Общий протокол управляющей информации (CMIP)Рекомендация МСЭ X.711Конкурент SNMP, но более мощный и не такой популярный
Система сигнализации № 7 (SS7)Серия рекомендаций ITU Q.700Управление телефонными соединениями через коммутируемую телефонную сеть общего пользования (PSTN)
Мультимедийные протоколы ITU серии HСерии рекомендаций ITU H.200, H.300 и H.400Передача голоса по Интернет-протоколу (VOIP)
Протокол взаимодействия BioAPI (BIP)ИСО / МЭК 24708: 2008
Общая структура форматов обмена биометрическими данными (CBEFF)NIST IR 6529-AОсновные правила кодирования
Контексты аутентификации для биометрии (ACBio)ИСО / МЭК 24761: 2019
Компьютерные телекоммуникационные приложения (CSTA)https://www.ecma-international.org/activities/Communications/TG11/cstaIII.htmОсновные правила кодирования
Выделенная связь малого радиуса действия (DSRC)SAE J2735Упакованные правила кодирования
Глобальная система мобильной связи (GSM)http://www.ttfn.net/techno/smartcards/gsm11-11.pdfСвязь по мобильному телефону
Общая услуга пакетной радиосвязи (GPRS) / Повышенная скорость передачи данных для глобального развития (EDGE)http://www.3gpp.org/technologies/keywords-acronyms/102-gprs-edgeСвязь по мобильному телефону
Универсальная система мобильной связи (UMTS)http://www.3gpp.org/DynaReport/25-series.htmСвязь по мобильному телефону
Долгосрочное развитие (LTE)http://www.3gpp.org/technologies/keywords-acronyms/98-lteСвязь по мобильному телефону
Общий протокол оповещения (CAP)http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.htmlПравила кодирования XMLОбмен предупреждающей информацией, например, янтарными предупреждениями
Связь между диспетчером и пилотом по линии передачи данных (CPDLC)Авиационная связь
Услуги расширения Space Link (SLE)Связь космических систем
Спецификация производственного сообщения (MMS)ISO 9506-1: 2003Производство
Передача, доступ и управление файлами (FTAM)Ранний и более эффективный конкурент File Transfer Protocol, но он уже редко используется.
Протокол элемента службы удаленных операций (ROSE)Рекомендации МСЭ X.880, X.881 и X.882Ранняя форма удаленного вызова процедур
Элемент службы управления ассоциациями (ACSE)Рекомендация МСЭ X.227
Протокол сетей автоматизации и управления зданиями (BACNet)ASHRAE 135-2016Правила кодирования BACNetАвтоматизация и управление зданиями, например, с пожарной сигнализацией, лифтами, системами HVAC и т. Д.
KerberosRFC  4120Основные правила кодированияБезопасная аутентификация
WiMAX 2Глобальные сети
Интеллектуальная сетьСерия рекомендаций ITU Q.1200Телекоммуникации и компьютерные сети

Кодировки [ править ]

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

Правила кодирования ASN.1
Правила кодированияИдентификатор объектаOID-IRI
Значение дескриптора объекта
Спецификация
Единица сериализации
Закодированные элементы,
различимые без предварительного знания спецификации
Октет выровнен
Определены правила нотации управления кодированием
Описание
Основные правила кодирования (BER) [3]2.1.1/ASN.1/Basic-EncodingБазовое кодирование одного типа ASN.1ITU X.690ОктетдадаНетПервые указанные правила кодирования. Кодирует элементы как последовательности значений длины тега (TLV). Обычно предоставляет несколько вариантов кодирования значений данных. Это одно из наиболее гибких правил кодирования.
Особые правила кодирования (DER) [4]2.1.2.1/ASN.1/BER-Derived/Distinguished-EncodingОтличительное кодирование одного типа ASN.1ITU X.690ОктетдадаНетОграниченное подмножество основных правил кодирования (BER). Обычно используется для объектов, имеющих цифровую подпись, потому что, поскольку DER допускает меньшее количество вариантов кодирования и поскольку значения, закодированные в DER, с большей вероятностью будут перекодированы в тех же самых байтах, цифровые подписи, созданные данным абстрактным значением, будут быть одинаковыми во всех реализациях, и цифровые подписи, созданные для данных, закодированных в формате DER, будут менее подвержены атакам на основе коллизий.
Канонические правила кодирования (CER) [5]2.1.2.0/ASN.1/BER-Derived/Canonical-EncodingКаноническое кодирование одного типа ASN.1ITU X.690ОктетдадаНетОграниченное подмножество основных правил кодирования (BER). Используются почти все те же ограничения, что и в правилах отличительного кодирования (DER), но примечательным отличием является то, что CER указывает, что многие большие значения (особенно строки) должны быть «разбиты» на отдельные элементы подстроки в 1000-байтовом или Метка из 1000 знаков (в зависимости от типа данных).
Базовые правила упакованного кодирования (PER) согласованы [6]2.1.3.0.0/ASN.1/Packed-Encoding/Basic/AlignedУпакованное кодирование одного типа ASN.1 (базовое выравнивание)ITU X.691НемногоНетдаНетКодирует значения в битах, но если закодированные биты не делятся равномерно на восемь, биты заполнения добавляются до тех пор, пока целое число октетов не закодирует значение. Способен создавать очень компактные кодировки, но за счет сложности, и PER сильно зависят от ограничений, накладываемых на типы данных.
Базовые правила пакетного кодирования (PER) без выравнивания [6]2.1.3.0.1/ASN.1/Packed-Encoding/Basic/UnalignedУпакованное кодирование одного типа ASN.1 (базовое невыровненное)ITU X.691НемногоНетНетНетВариант Aligned Basic Packed Encoding Rules (PER), но он не дополняет значения данных битами для получения целого числа октетов.
Согласованные канонические правила упакованного кодирования (CPER) [6]2.1.3.1.0/ASN.1/Packed-Encoding/Canonical/AlignedУпакованное кодирование одного типа ASN.1 (с каноническим выравниванием)ITU X.691НемногоНетдаНетВариант упакованных правил кодирования (PER), определяющий единственный способ кодирования значений. Канонические правила упакованного кодирования имеют сходные отношения с правилами упакованного кодирования, которые имеют отличительные правила кодирования (DER) и канонические правила кодирования (CER) с основными правилами кодирования (BER).
Канонические правила упакованного кодирования (CPER) без выравнивания [6]2.1.3.1.1/ASN.1/Packed-Encoding/Canonical/UnalignedУпакованное кодирование одного типа ASN.1 (канонический без выравнивания)ITU X.691НемногоНетНетНетВариант Согласованных канонических упакованных правил кодирования (CPER), но он не дополняет значения данных битами для получения целого числа октетов.
Основные правила кодирования XML (XER) [7]2.1.5.0/ASN.1/XML-Encoding/BasicБазовое XML-кодирование одного типа ASN.1ITU X.693ХарактердададаКодирует данные ASN.1 как XML.
Канонические правила кодирования XML (CXER) [7]2.1.5.1/ASN.1/XML-Encoding/CanonicalКаноническое XML-кодирование одного типа ASN.1ITU X.693Характердадада
Расширенные правила кодирования XML (EXER) [7]2.1.5.2/ASN.1/XML-Encoding/ExtendedРасширенное кодирование XML одного типа ASN.1ITU X.693Характердадада
Правила кодирования октетов (OER) [8]2.1.6.0Базовое кодирование OER одного типа ASN.1ITU X.696ОктетНетдаНабор правил кодирования, который кодирует значения в октетах, но не кодирует теги или детерминанты длины, такие как базовые правила кодирования (BER). Значения данных, закодированные с использованием правил кодирования октетов, часто выглядят так же, как и в протоколах, основанных на записях. Правила кодирования октетов (OER) были разработаны, чтобы их было легко реализовать и создавать более компактные кодировки, чем те, которые создаются с помощью основных правил кодирования (BER). Помимо уменьшения усилий по разработке кодировщиков / декодеров, использование OER может снизить использование полосы пропускания (хотя и не так сильно, как правила упакованного кодирования), сэкономить циклы ЦП и снизить задержку кодирования / декодирования.
Канонические правила кодирования (OER) [8]2.1.6.1Каноническое кодирование OER одного типа ASN.1ITU X.696ОктетНетда
Правила кодирования JSON (JER) [9]ITU X.697ХарактердададаКодирует данные ASN.1 как JSON.
Общие правила кодирования строк (GSER) [10]1.2.36.79672281.0.0Общие правила кодирования строк (GSER)RFC  3641ХарактердаНетНеполная спецификация правил кодирования, которые производят удобочитаемые значения. Цель GSER - представить закодированные данные пользователю или данные ввода от пользователя в очень простом формате. GSER изначально был разработан для облегченного протокола доступа к каталогам (LDAP) и редко используется вне его. Использование GSER в реальных протоколах не рекомендуется, поскольку не все кодировки символьных строк, поддерживаемые ASN.1, могут быть воспроизведены в нем.
Правила кодирования BACNetASHRAE 135ОктетдададаКодирует элементы как последовательности значений длины тега (TLV), такие как основные правила кодирования (BER).
Сигнализация конкретных правил кодирования (SER)Внутренний документ по исследованиям и разработкам France TelecomОктетдадаИспользуется в основном в телекоммуникационных протоколах, таких как GSM и SS7. Предназначен для создания идентичного кодирования из ASN.1, которое могли бы производить ранее существовавшие протоколы, не указанные в ASN.1.
Правила упрощенного кодирования (LWER)Внутренний документ INRIA.Слово памятидаПроисходит из внутреннего документа, подготовленного INRIA, в котором подробно описывается «упрощенный синтаксис плоского дерева» (FTLWS). Отказ от использования в 1997 году из-за превосходной производительности правил упакованного кодирования (PER). Необязательно передача Big-Endian или Little-Endian, а также 8-битные, 16-битные и 32-битные слова памяти. (Следовательно, существует шесть вариантов, поскольку существует шесть комбинаций этих вариантов.)
Минимальные правила битового кодирования (MBER)НемногоПредложен в 1980-х гг. Предполагается, что он должен быть как можно более компактным, как правила упакованного кодирования (PER).
Правила кодирования пакетов NEMAНемногоНеполная спецификация правила кодирования, разработанная NEMA. Он неполный, поскольку не может кодировать и декодировать все типы данных ASN.1. Компактный, как правила упакованного кодирования (PER).
Правила высокоскоростного кодирования«Правила кодирования для высокоскоростных сетей»Определение этих правил кодирования явилось побочным продуктом работы INRIA над упрощенным синтаксисом Flat Tree Light Weight Syntax (FTLWS).

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

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

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

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

Пример [ править ]

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

ОПРЕДЕЛЕНИЯ FooProtocol :: = НАЧАТЬ FooQuestion :: = ПОСЛЕДОВАТЕЛЬНОСТЬ { trackingNumber INTEGER, вопрос IA5String } FooAnswer :: = SEQUENCE { questionNumber INTEGER, ответ BOOLEAN }КОНЕЦ

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

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

myQuestion FooQuestion :: = { trackingNumber 5, вопрос "Есть кто-нибудь?"}

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

ОПРЕДЕЛЕНИЯ FooProtocol :: = НАЧАТЬ FooQuestion :: = ПОСЛЕДОВАТЕЛЬНОСТЬ { trackingNumber INTEGER (0..199), вопрос IA5String } FooAnswer :: = SEQUENCE { questionNumber INTEGER (10..20), ответ BOOLEAN } FooHistory :: = SEQUENCE { вопросы ПОСЛЕДОВАТЕЛЬНОСТЬ (РАЗМЕР (0..10)) FooQuestion, отвечает ПОСЛЕДОВАТЕЛЬНОСТЬ (РАЗМЕР (1..10)) FooAnswer, anArray SEQUENCE (SIZE (100)) OF INTEGER (0..1000), ... }КОНЕЦ

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

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

Пример, закодированный в DER [ править ]

Ниже представлена ​​структура данных, показанная выше как FooQuestion, закодированная в формате 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 - тип тега с указанием ПОСЛЕДОВАТЕЛЬНОСТИ13 - длина в октетах следующего значения 02 - тип тега, указывающий INTEGER 01 - длина в октетах следующего значения 05 - значение (5) 16 - тип тега с указанием IA5String  (IA5 означает полный 7-битный набор ISO 646, включая варианты,  но обычно это US-ASCII) 0e - длина в октетах следующего за ним значения 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f - значение («Кто-нибудь там?»)

Пример, закодированный в XER [ править ]

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

<FooQuestion>  <trackingNumber> 5 </trackingNumber>  <question> Есть кто-нибудь? </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 представляют собой, по сути, упорядоченный поток битов, а не упорядоченный поток байтов, как при выровненном 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 Tool .

Онлайн-инструменты [ править ]

  • Веб-инструмент ASN1

Сравнение с аналогичными схемами [ править ]

ASN.1 аналогичен по назначению и использованию буферам протокола и Apache Thrift , которые также являются языками описания интерфейсов для межплатформенной сериализации данных. Подобно этим языкам, он имеет схему (в 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, как правило, чаще используется для определения текстовых, удобочитаемых протоколов и обычно не используется для определения кодировок типа длина-значение.

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

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

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

Дополнительные сведения см. В разделе Сравнение форматов сериализации данных .

См. Также [ править ]

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

Ссылки [ править ]

  1. ^ "База данных рекомендаций ITU-T" . ITU . Проверено 6 марта 2017 .
  2. ^ ITU-T X.680 - Спецификация основных обозначений
  3. ^ ITU-T X.690 - Основные правила кодирования (BER)
  4. ^ ITU-T X.690 - Особые правила кодирования (DER)
  5. ^ ITU-T X.690 - Канонические правила кодирования (CER)
  6. ^ a b c d ITU-T X.691 - Правила упакованного кодирования (PER)
  7. ^ a b c ITU-T X.693 - Правила кодирования XML (XER)
  8. ^ a b ITU-T X.696 - Правила кодирования октетов (OER)
  9. ^ ITU-T X.697 - Правила кодирования обозначений объектов JavaScript (JER)
  10. ^ 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