Здравствуйте, vsb, Вы писали:

Pzz>>Не понимаю. В XML можно изобразить массив, просто повторяя элемент (с одинаковым именем) несколько раз. Некоторые протоколы так и делают.

vsb>Без дополнительной информации вроде XML Schema — нельзя. Т.к. нельзя отличить null от массива нулевой длины и нельзя отличить массив единичной длины от объекта.

<Array name="foo">
  <ArrayElement>0</ArrayElement>
  <ArrayElement>1</ArrayElement>
  <ArrayElement>2</ArrayElement>
</Array>

Null — отсутствие массива.

В JSON-е, кстати, тоже, null можно передать только или отсутствием, ну или впихнуть туда null, но мне кажется как-то скользко, что у некоторого элемента значением может быть или null, или нормальные данные.

Pzz>>Сам спросил, сам ответил. 2^52 же. Числа в JSON — это 64-битный float в формате IEEE 754, и это от JS так пошло.

vsb>Нет, числа в JSON вообще никак не специфицированы. В каждой реализации они по-своему работают. В Java без проблем я могу сделать 54-битное число в JSON, сформировать и прочитать. И это число в JS будет читаться неправильно.

RFC 8259, раздел 7 (https://datatracker.ietf.org/doc/html/rfc8259#page-7) прямо об этом и пишет, что числа, вообще-то, имеются ввиду IEEE 754 binary64, и что, хотя некоторые реализации делают не так, лучше бы всё же иметь это ввиду.

Pzz>>UTF-8 же.

vsb>Нет, не специфицировано, ну или я не видел.

RFC 8259, секция 8.1. (https://datatracker.ietf.org/doc/html/rfc8259#section-8.1)

Раньше "подразумевалось", но для мира RFC это нормально. Есть "священное писание" — сами RFC, а есть "священное предание" — то, что все, кому надо, знают, но оно нигде не написано.

Например, то, как в TCP передаётся urgent pointer, в RFC 793 было написано неправильно, а в ядре BSD UNIX — правильно, и все это знали (кроме Microsoft, они сделали, как в RFC, хе-хе).

Pzz>>Раздражает, что нет синтаксиса для передачи бинарных данных (массива байт).

vsb>Обычно в base64 передают.

Непонятно, получив такое, это надо буквально применять или из base64 сначала декодировать. Схемы/метаданных-то нету...

Здравствуйте, Maniacal, Вы писали:

S>>https://stackoverflow.com/questions/6032137/how-to-visualize-data-from-google-protocol-buffer

M>Тогда и в ASN.1 можно хранить, для него есть визуализаторы.

sqlite3 — неплохой вариант, кстати. Это, вроде, портабельный формат, при этом довольно удобный и компактный, и открыть его можно везде.

ASN.1 — это для любителей садо-мазо.

Здравствуйте, vsb, Вы писали:

vsb>Что значит "человеко-читаемый" я не очень понимаю. По-мне всё, что ASCII — одинаково человеко-читаемо. По этому критерию и XML и JSON и YAML человеко-читаемы.

base64?

Здравствуйте, Shmj, Вы писали:

S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?

Ещё из популярных есть protobuf/flatbuffers. И байты умеют экономить, и в скорость, и умеют сериализовываться в тот же json, если хочется почитать глазами.

Здравствуйте, Maniacal, Вы писали:

S>>Есть визуализаторы
S>>https://stackoverflow.com/questions/6032137/how-to-visualize-data-from-google-protocol-buffer

M>Тогда и в ASN.1 можно хранить, для него есть визуализаторы.
В любом формате если есть визуализатор.
Никто же не будет делать БД на JSON. Хотя и поддерживают его для хранения документов и поиска.
Для просмотра JSON тоже нужен визуализатор в виде редактора текста

Здравствуйте, Pzz, Вы писали:

Pzz>ASN.1 — это для любителей садо-мазо.

Да, стандарт принятый, как официальный, например, у телекоммуникационных компаний. Столкнулся с ним, когда генератор роуминговых файлов для МТС поддерживал. Там одно неверное движение и придётся человекочитанием человеконечитаемый hex-код парсить на соответствие схеме, искать ошибку. А так там и деревья и массивы и всё что угодно есть.

Здравствуйте, Maniacal, Вы писали:

Pzz>>ASN.1 — это для любителей садо-мазо.

M>Да, стандарт принятый, как официальный, например, у телекоммуникационных компаний. Столкнулся с ним, когда генератор роуминговых файлов для МТС поддерживал. Там одно неверное движение и придётся человекочитанием человеконечитаемый hex-код парсить на соответствие схеме, искать ошибку. А так там и деревья и массивы и всё что угодно есть.

Я знаю. Телефонисты немного этого ASN-а в интернет принесли. Это TLS (SSL), X.509, SNMP, LDAP...

X.509 — даже и название-то такое, телефонистское

Здравствуйте, Pzz, Вы писали:

Pzz>sqlite3 — неплохой вариант, кстати. Это, вроде, портабельный формат, при этом довольно удобный и компактный, и открыть его можно везде.
Pzz>ASN.1 — это для любителей садо-мазо.

Слишком много инструментов заточено на человеко-читаемый текст. Вот даже сетевой трафик смотрите — передается XML или JSON. Сразу видно и сразу можно что-то поиском найти. А sqlite3 как будете копировать и потом смотреть? Каждый раз копировать?

Далее — тот же GIT — ведь удобно в DIFF-ах смотреть что поменялось.

Здравствуйте, Shmj, Вы писали:

S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?

Суперобучение с помощью карточек (07.11.2024)

Здравствуйте, Shmj, Вы писали:

S>Потом все более и более JSON.

Из всех мною испробованных, самый человеко-ориентированный это TOML. На втором месте — XML. JSON это вообще формат сериализации, руками его править можно, но это неудобно.

Еще один хороший вариант — это JavaScript/TypeScript в качестве языка конфигурации. Преимущество в том, что если нужно обьявить, например, переменную, а затем её использовать несколько раз в разных местах конфигурации, то это делается штатными средствами языка:

const myVar = "Top$ecret";

const config = {
   password: myVar,
   database: {
       password: myVar
   }
};

export default config;

Здравствуйте, Shmj, Вы писали:

S>Слишком много инструментов заточено на человеко-читаемый текст. Вот даже сетевой трафик смотрите — передается XML или JSON. Сразу видно и сразу можно что-то поиском найти. А sqlite3 как будете копировать и потом смотреть? Каждый раз копировать?

В сетевом трафике чего только не передаётся. И я, заметим, нигде не утверждал, что sqlite3 — удобный формат для сетевого протокола. Скорее, он удобен для хранения/передачи достаточно большого объема структурированных данных.

S>Далее — тот же GIT — ведь удобно в DIFF-ах смотреть что поменялось.

Если, к примеру, в миллионе строк кода переименовать какую-нибудь популярную переменную или изменить стиль форматирования, такой diff смотреть будет люто неудобно.

Здравствуйте, Pzz, Вы писали:

Pzz>В сетевом трафике чего только не передаётся. И я, заметим, нигде не утверждал, что sqlite3 — удобный формат для сетевого протокола. Скорее, он удобен для хранения/передачи достаточно большого объема структурированных данных.

А мы речь ведем о человек-читаемости, когда нужно мало.

Вот взять Excel тот же. Внутри там XML. Почему? Потому что разработчикам проще искать баги.

S>>Далее — тот же GIT — ведь удобно в DIFF-ах смотреть что поменялось.
Pzz>Если, к примеру, в миллионе строк кода переименовать какую-нибудь популярную переменную или изменить стиль форматирования, такой diff смотреть будет люто неудобно.

Но речь же о файлах, которые создают люди и редактируют люди.

Здравствуйте, Shmj, Вы писали:

S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
Да, пока что JSON обладает оптимальными характеристики по читаемости, скорости парсинга, объему передаваемых данных и удобству обработки в разных ЯП.


S>Вот, ранее очень часто для передачи данных, если нет нужны экономить байты и желательно чтобы человек мог, по нужде, глянуть — использовали XML.
S>Потом все более и более JSON.
S>После начали т.н. YAML, но как-то не особо, т.к. все-таки он не особо лучше, но сложнее. Удобство в читабельности сомнительное, а сам формат намного сложнее.


Тут надо понимать, что есть человек-читаемость, а есть человеко-писаемость. И xml, и JSON легко читать, но довольно неудобно писать. Схемы конечно упрощают, но не до конца. YAML легко писать пользователю.

Здравствуйте, gandjustas, Вы писали:

G>Тут надо понимать, что есть человек-читаемость, а есть человеко-писаемость. И xml, и JSON легко читать, но довольно неудобно писать. Схемы конечно упрощают, но не до конца. YAML легко писать пользователю.

Я боюсь писать YAML. Особенно если нет подсветки. Вдруг где-то пробел не заметишь — и хана.

Здравствуйте, Shmj, Вы писали:

Если нет редактора, который подсвечивает JSON и ошибки в нем, то XML однозначно лучше. Бесят эти запятые, то лишнюю поставишь в конце, то в середине забудешь

Плюс, в XML, даже если ты не знаешь схемы, можно по тэгам примерно понять структуру документа/конфига/итп, под джейсону — хрен там был

Здравствуйте, Shmj, Вы писали:

S>Круглые скобки — это официальный знак препинания в гуманоидном языке, по этому лучше фигурные, тем более они легко доступны на клавиатуре.

Круглые скобки есть в русской и английской раскладках, фигурные только в английской

Здравствуйте, пффф, Вы писали:

П>Круглые скобки есть в русской и английской раскладках, фигурные только в английской

Так вы же названия нод — все-равно на англ. пишите.

Здравствуйте, Shmj, Вы писали:

Самый удобный человеко-читаемый язык данных

plain text

Здравствуйте, Shmj, Вы писали:

S>И почти все данные верхнего уровня (HTML, CSS, JSON, XML) — они передаются в человеко-читаемом виде, хотя могли бы юзать бинарный формат.

Потому что делали ленивые дураки.

S>Но чтобы легче было писать эти инструменты — разработчику лучше человеко-читаемый а не бинарный формат.

Лучше всего сделать взаимо однозначный конвертор текст <-> бинарник. Использовать текст для объемистых данных — просто идиотизм.

Здравствуйте, Codealot, Вы писали:

C>Лучше всего сделать взаимо однозначный конвертор текст <-> бинарник. Использовать текст для объемистых данных — просто идиотизм.

Нет. Парсинг и форматирование (если не совсем уж тупо написаны) занимают копейки по сравнению с манипулированием структурами в памяти, а пользы от текстового представления — вагоны.

PS: Но это текстовое представление, должен заметить, должно быть скорее "полутекстовым". В нём не должно быть "грамматизьмы" ранних подходов IETF, где 100500 форматов представления одного и того же ради возможности отформатировать в ASCII art (ещё этим страдает YAML). Числа желательно представлять в шестнадцатиричном (или хотя бы свободно позволять это), включая float'ы.