WikiDer > Канонические S-выражения

Canonical S-expressions

А Каноническое S-выражение (или же csexp) представляет собой форму двоичного кодирования подмножества общих S-выражение (или sexp). Он был разработан для использования в СПКИ сохранить силу S-выражений и обеспечить каноническая форма для таких приложений, как цифровые подписи при достижении компактности двоичной формы и максимальной скорости синтаксического анализа.

Частное подмножество общих S-выражений, применимых здесь, состоит из атомы, которые представляют собой байтовые строки и круглые скобки, используемые для разделения списков или подсписок. Эти S-выражения полностью рекурсивны.

Хотя S-выражения обычно кодируются как текст с пробелами, ограничивающими атомы, и кавычками, используемыми для окружения атомов, содержащих пробелы, при использовании канонической кодировки каждый атом кодируется как строка байтов с префиксом длины. Пробелы между соседними элементами в списке не допускаются. Длина атома выражается как ASCII десятичное число, за которым следует ":".

Пример

Секс

(это "каноническое S-выражение" состоит из 5 атомов)

становится csexp

(4: this22: каноническое S-выражение3: has1: 55: атомы)

Кавычки не требуются для экранирования символа пробела внутри атома "Каноническое S-выражение", потому что префикс длины явно указывает на конец атома. Нет пробелов, отделяющих атом от следующего элемента в списке.

Характеристики

  • Уникальность канонической кодировки: Запрещение пробелов между элементами списка и предоставление только одного способа кодирования атомов гарантирует, что каждое S-выражение имеет ровно одну закодированную форму. Таким образом, мы можем решить, эквивалентны ли два S-выражения, сравнив их кодировки.
  • Поддержка двоичных данных: Атомы могут быть любой двоичной строкой. Итак, криптографическое хеш-значение или модуль открытого ключа, которые в противном случае пришлось бы закодировать в base64 или какая-то другая печатаемая кодировка может быть выражена в csexp как его двоичные байты.
  • Поддержка кодированной информации с пометкой типа: Csexp включает конструкцию без S-выражения для указания кодировки строки, когда эта кодировка неочевидна. Любой атом в csexp может иметь префикс в виде одиночного атома в квадратных скобках, например, «[4: JPEG]» или «[24: text / plain; charset = utf-8]».

Толкование и ограничения

Хотя csexps обычно разрешает пустые списки, пустые атомы и т. Д., Некоторые способы использования csexps накладывают дополнительные ограничения. Например, csexps используется в СПКИ имеют одно ограничение по сравнению с csexps в целом: каждый список должен начинаться с атома, и поэтому не может быть пустых списков.

Обычно первый атом списка обрабатывается так же, как и имя элемента в XML.

Сравнения с другими кодировками

Есть и другие распространенные кодировки:

  1. XML
  2. ASN.1
  3. JSON (и YAML который включает «JSON как официальное подмножество» с надмножеством, предназначенным для большего человек читаемый.)

Как правило, csexp имеет синтаксический анализатор на один или два десятичных порядка меньше, чем у XML или ASN.1.[нужна цитата] Этот небольшой размер и соответствующая скорость[нужна цитата] дать csexp главное преимущество. Помимо преимущества парсинга, есть и другие отличия.

csexp против XML

csexp и XML отличаются тем, что csexp - это формат представления данных, тогда как XML включает в себя формат представления данных, а также механизм схемы. Таким образом, XML можно «сконфигурировать» для определенных типов данных, которые соответствуют некоторой грамматике (скажем, HTML, АТОМ, SVG, MathML, или новые по мере необходимости). В нем есть языки для определения грамматик документа: DTD определяется самим стандартом XML, а XSD, RelaxNG, и Схематрон обычно используются с XML для дополнительных функций, и XML также может работать без схемы. Данные csexp, конечно, могут управляться схемами, реализованными на более высоком уровне, но сами по себе такого механизма не предоставляют.

С точки зрения символов и байтов, «строка» csexp может иметь любую последовательность байтов (из-за префикса длины на каждом атоме), в то время как XML (например, регулярные S-выражения схемы, JSON и литералы в языках программирования) требует альтернативных представления нескольких символов (например, «<» и большинства управляющих символов). Однако это не влияет на диапазон структур и семантики, которые могут быть представлены. XML также предоставляет механизмы для определения того, как данная последовательность байтов предназначена для интерпретации: скажем, как Unicode UTF-8 строка, a JPEG файл или целое число; csexp оставляет такие различия внешним механизмам.

На самом базовом уровне и csexp, и XML представляют деревья (как и большинство других внешних представлений). Это неудивительно, поскольку XML можно описать как форму с другой пунктуацией для LISP-подобных S-выражений, или наоборот.[1]

Однако XML включает дополнительную семантику, которая обычно достигается в csexp с помощью различных соглашений, а не как часть языка. Во-первых, каждый элемент XML имеет имя (приложения csexp обычно используют для этого первый дочерний элемент каждого выражения). Во-вторых, XML обеспечивает типирование данных, во-первых, через грамматику схемы. Однако схема также может различать целые числа, строки, объекты данных с типами (например, JPEG) и (особенно с XSD) другие виды).

Элемент XML также может иметь атрибуты, конструкция, которую csexp не разделяет. Чтобы представить данные XML в csexp, необходимо выбрать представление для таких атрибутов; очевидным является резервирование второго элемента в каждом S-выражении для списка пар (имя-значение), аналогично LISP список ассоциаций. XML Я БЫ и IDREF Атрибуты не имеют эквивалента в csexp, но могут быть легко реализованы прикладной программой csexp.

Наконец, элемент XML может содержать комментарии и / или инструкции по обработке. У csexp нет конкретных эквивалентов, но их легко представить, просто зарезервировав имя для каждого. Например, присвоение им имен «* COM» и «* PI» («*» предотвращает столкновение с именами типов элементов XML):

 (4: * COM15: текст комментария) (3: * PI6: target11: font = "helv")

И csexp, и XML полностью рекурсивны.

Первый атом в списке csexp по соглашению примерно соответствует имени типа элемента XML при идентификации «типа» списка. Однако в csexp это может быть любой атом в любой кодировке (например, JPEG, строка Unicode, WAV file,…), в то время как имена элементов XML являются идентификаторами, ограниченными определенными символами, например идентификаторами языка программирования. Очевидно, что метод csexp более общий; с другой стороны, определение того, в какой кодировке находится такой элемент, и, следовательно, как его интерпретировать, определяется только соглашениями конкретного пользователя, а это означает, что приложение csexp должно создавать такие соглашения для себя, в коде, документации и т. д. .

Аналогично, атомы csexp являются двоичными (состоящими из префикса длины, за которым следует совершенно произвольный байты), в то время как XML предназначен для чтения человеком (хотя, возможно, в меньшей степени, чем JSON или же YAML) - поэтому произвольные байты в XML должны быть как-то закодированы (например, растровое изображение может быть включено с помощью base64). Это означает, что для хранения больших объемов нечитаемой информации в несжатом XML требуется больше места; с другой стороны, он переживет перевод между альтернативными наборы символов (включая передачу через сетевые узлы, которые могут применять разные наборы символов, соглашения о конце строки и т. д.).

Было высказано предположение, что XML «объединяет» последовательность строк в одном элементе в одну строку, в то время как csexp допускает последовательность атомов в списке, и эти атомы остаются отдельными друг от друга; но это неверно.[2] Точно так же, как S-выражения и csexp, XML имеет понятие «последовательность строк» ​​только в том случае, если «строки» каким-то образом разделены:

 <s>String A</s><s>String B</s>   versus <s>String AString B</s>
 («Строка A» «Строка B») по сравнению с («Строка AString B»)
 (8: строка A8: строка B) по сравнению с (16: строка AString B)

csexp против ASN.1

ASN.1 - популярная форма двоичного кодирования. Однако он выражает только синтаксис (типы данных), но не семантику. Две разные структуры, каждая из которых представляет собой ПОСЛЕДОВАТЕЛЬНОСТЬ из двух ЦЕЛОГО ЧИСЛА, имеют идентичные представления на проводе (за исключением специального выбора тегов для их различения). Чтобы проанализировать структуру ASN.1, необходимо сообщить синтаксическому анализатору, какой набор структур он ожидает, и синтаксический анализатор должен сопоставить тип данных, анализируемый с параметрами структуры. Это добавляет сложности парсеру ASN.1.

Структура csexp несет некоторое указание на ее собственную семантику (закодированную в именах элементов), и синтаксическому анализатору структуры csexp все равно, какая структура анализируется. После того, как выражение проводного формата было преобразовано во внутреннюю древовидную форму (подобную XML DOM), потребитель этой структуры может проверить его на соответствие тому, что ожидалось. XML-документ без схемы в этом отношении работает так же, как csexp, тогда как XML-документ с ними может работать больше как ASN.1.

внешняя ссылка

Примечания и ссылки

  1. ^ Это сходство было известно создателям XML. Например, Стивен ДеРоуз обсуждал это в Книга часто задаваемых вопросов SGML: понимание взаимосвязи SGML и XML, Kluwer Academic Publishers, 1997. ISBN 978-0-7923-9943-8.
  2. ^ В SAX интерфейс к XML позволяет XML парсер разбивать (отдельные) текстовые строки как угодно. Некоторые реализации[нужна цитата] (неправильно) вернуть несколько линии как отдельные текстовые узлы, что могло привести к этому распространенному недоразумению.