1Тема от Лео

Соответствие формата стандарту RFC8259

  • Лео
  • Лео
  • Wialon fan club
  • Неактивен
  • Откуда: MSK RU
  • Зарегистрирован: 17/09/2019
  • Сообщений: 95
  • Продукты: Wialon Hosting
  • Карма: 27

Тема: Соответствие формата стандарту RFC8259

В документации заявлено, что формат обмена - JSON.
При этом имена параметров (name) не соответствуют описанию из стандарта:
"An object is an unordered collection of zero or more name/value pairs, where a name is a string ..."
Далеко не все парсеры согласны с корректностью текста:

{
"17296507" : [ ... ],
"17301757" : [ ... ],
"17302736" : [ ... ]
}

Это, конечно, хорошо, что вы число завернули в кавычки, но строкой оно от этого не стало (мы же понимаем, что значит JS в сокращении "JSON" и к какому стандарту отсылка).

Подскажите, стОит ли ожидать приведение вашего формата в соответствие с RFC8259?

0
2Ответ от rual

Соответствие формата стандарту RFC8259

  • rual
  • rual
  • Wialon fan club
  • Неактивен
  • Откуда: Minsk
  • Зарегистрирован: 14/12/2016
  • Сообщений: 274
  • Карма: 162

Re: Соответствие формата стандарту RFC8259

https://tools.ietf.org/html/rfc8259

Пункт 4. Object. Грамматика:

      object = begin-object [ member *( value-separator member ) ]
               end-object

      member = string name-separator value

Грамматика строк:

      string = quotation-mark *char quotation-mark

      char = unescaped /
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              %x75 4HEXDIG )  ; uXXXX                U+XXXX

      escape = %x5C              ; \

      quotation-mark = %x22      ; "

      unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

"17296507" по этой грамматике соответствует string, кавычка, затем последовательность диапазона %x23-5B, затем снова кавычка. Поэтому вполне законно является ключом объекта.

После ключа перед двоеточием так же может быть сколько угодно пробелов в соответствии с грамматикой name-separator:

name-separator  = ws %x3A ws  ; : colon

Приведённый JSON является полностью валидным согласно стандарту RFC8259 (если, конечно, вместо троеточий находятся валидные JSON-значения)

tata

+1
3Ответ от Лео

Соответствие формата стандарту RFC8259

(18/09/2019 10:09:34 отредактировано Лео)
  • Лео
  • Лео
  • Wialon fan club
  • Неактивен
  • Откуда: MSK RU
  • Зарегистрирован: 17/09/2019
  • Сообщений: 95
  • Продукты: Wialon Hosting
  • Карма: 27

Re: Соответствие формата стандарту RFC8259

Не смогу с вами согласиться.

* Любая конструкция, заключённая в кавычки по-вашему является строкой. Мне кажется, подавляющее большинство ваших клиентов преобразует полученные пакеты в объектную модель, где ваши так называемые"строковые имена" становятся именами свойств. И бОльшая часть библиотек (com.google.gson, com.fasterxml.jackson, io.restassured, groovy.json.*) не согласны с подобным правилом именования.

* Учебник по JS (https://learn.javascript.ru/variables#variable-naming):

В JavaScript есть два ограничения, касающиеся имён переменных:
1. Имя переменной должно содержать только буквы, цифры или символы $ и _.
2. Первый символ не должен быть цифрой.

Мне не кажется логичным, чтобы разработчики "JavaScript Object Notation", действующие в контексте JavaScript, вдруг решили нарушить его ограничения.

* 24% ваших клиентов используют 1С (согласно результатам голосования в другой вашей теме). Разработчики платформы 1С, уверен, тоже исследовали этот вопрос и трактуют его аналогично приведённым выше библиотекам. При этом в 1С есть очень полезная фича - применение схем XSD к JSON-пакетам. Это действует примерно как JSON schema. Это сразу позволяет проверить валидность пакета, преобразовать св-ва к нужным типам и многое другое. Конечно, на старте обработки полученного JSON-пакета лучше сразу убедиться в его валидности, поэтому и производится попытка его приведения к типу объекта схемы XSD. Наличие нарушающих правила именования свойств при попытке преобразования к объектной модели даёт ошибку. ( Пакет.17302736.trips...)

Более того, приведённый пример вообще ставит крест на описании формата пакета в XSD за счёт динамических свойств (имена ТСок). Мы все понимаем, как не сложно можно было бы сделать их значениями, а не свойствами и возвращать массив. Тогда бы проблемы не было:

{
[
"unitID": "17296507", "trips": ...,
"unitID": "17301757", "trips":  ... ,
"unitID": "17302736", "trips":  ... ,
...
]
}

Пример для ответа на запрос "events/check_updates". Писал от руки, мог ошибиться.
Подскажите, у меня есть шансы быть услышанным?

0
4Ответ от rual

Соответствие формата стандарту RFC8259

  • rual
  • rual
  • Wialon fan club
  • Неактивен
  • Откуда: Minsk
  • Зарегистрирован: 14/12/2016
  • Сообщений: 274
  • Карма: 162

Re: Соответствие формата стандарту RFC8259

В JavaScript такие объекты являются валидными:

let obj = {
    '1': 'a',
    '1234': 'b',
    '42': 'c',
};

console.log(obj['1234'], obj[42]); // b c

(более того, если бы нет, не работали бы массивы)

Относительно формального описания схемы. У JSON Schema есть pattern properties, позволяющие описать, что «объект содержит поля, ключи которых являются числами» — https://json-schema.org/understanding-j … properties . Скорее всего у XSD должно быть нечто подобное, чтобы валидировать произвольные узлы.

Лео пишет:

Мы все понимаем, как не сложно можно было бы сделать их значениями, а не свойствами и возвращать массив. Тогда бы проблемы не было


У JSON-объектов есть преимущество перед массивами, что туда не советуется (SHOULD) помещать несколько уникальных ключей. Но относительно формата сериализации оба варианта эквивалентны. В существующем API формат данных изменён быть не может.

0