Самый удобный человеко-читаемый язык данных
От: Shmj Ниоткуда  
Дата: 18.12.24 20:49
Оценка:
Вот, ранее очень часто для передачи данных, если нет нужны экономить байты и желательно чтобы человек мог, по нужде, глянуть — использовали XML.

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

После начали т.н. YAML, но как-то не особо, т.к. все-таки он не особо лучше, но сложнее. Удобство в читабельности сомнительное, а сам формат намного сложнее.

Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
Re: Самый удобный человеко-читаемый язык данных
От: Osaka  
Дата: 18.12.24 23:17
Оценка:
S>человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
Для данных человечество придумало Excel.
Недостаточную человекочитаемость формата нужно компенсировать инструментами.
Сделать как в редакторе xaml, сверху список таблиц в файле + данные выбранной, снизу xml/жсон/хзчто или вообще бинарник, оба вида редактируемые, мгновенная трансляция изменений в обе стороны.
Когда такую элементарнейшую вещь приделают в visual studio? На всякое вредительство типа обезцвечивания иконок у них деньги почему-то есть.
Re: Самый удобный человеко-читаемый язык данных
От: vsb Казахстан  
Дата: 19.12.24 00:04
Оценка: 3 (2)
XML и JSON это два разных подхода к моделированию данных.

XML это по сути дерево.

JSON это отображения (maps) плюс массивы.

XML хорош для моделирования древовидных данных. А вот массивы в него ложатся плохо.

JSON хорош для сериализации и десериализации, т.к. в него напрямую отображаются две самые популярные структуы данных.

YAML это альтернативный синтаксис для JSON.

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

Будет ли что-то ещё? Наверное зависит от развития языков программирования. JSON рождён от JavaScript-а. Когда-то были популярны S-выражения. Уйдёт JavaScript, придёт что-то другое, я так думаю.

В целом у JSON хватает мелких, но противных проблем.

Отсутствие вменяемой общепринятой спецификации. К примеру простые вопросы. Какие числа можно передавать? Что происходит при дублировании ключей? Это отдаётся на откуп конкретной реализации, что вызывает проблемы при взаимодействии, к примеру в JS целые числа ограничечны 2^52.

Нет очевидных фич, к примеру комментарии, возможность использовать массивы сверху. Опять же отдаётся на откуп реализациям и приводит к проблемам при взаимодействии.

Не специфицирована кодировка текста, т.е. нет однозначного отображения объекта в байты, только в строку.

Это всё не к тому, что JSON фатально плох, а к тому, что есть чем его улучшать.
Re[2]: Самый удобный человеко-читаемый язык данных
От: Shmj Ниоткуда  
Дата: 19.12.24 04:40
Оценка:
Здравствуйте, Osaka, Вы писали:

O>Для данных человечество придумало Excel.


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

O>Недостаточную человекочитаемость формата нужно компенсировать инструментами.


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

O>Сделать как в редакторе xaml, сверху список таблиц в файле + данные выбранной, снизу xml/жсон/хзчто или вообще бинарник,


Сейчас вопрос о то что снизу — какой формат там удобнее. XML — банально больше лишних символов, что утомляет.

Вот, для примера, что вам удобнее читать:

<Window x:Class="ExampleApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Example" Height="300" Width="400">
    <Grid Margin="10">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto" />
            <RowDefinition Height="Auto" />
            <RowDefinition Height="Auto" />
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>

        <!-- Заголовок -->
        <TextBlock Text="Введите текст:" Grid.Row="0" Margin="0,0,0,10" />

        <!-- Поле ввода текста -->
        <TextBox Name="InputTextBox" Grid.Row="1" Margin="0,0,0,10" />

        <!-- Кнопка -->
        <Button Content="Показать текст" Grid.Row="2" Click="OnButtonClick" />

        <!-- Вывод текста -->
        <TextBlock Name="OutputTextBlock" Grid.Row="3" Margin="0,10,0,0" Foreground="Blue" />
    </Grid>
</Window>

using System.Windows;

namespace ExampleApp
{
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }

        private void OnButtonClick(object sender, RoutedEventArgs e)
        {
            // Получение текста из TextBox и вывод его в TextBlock
            OutputTextBlock.Text = InputTextBox.Text;
        }
    }
}


import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text("Example")),
        body: const InputWidget(),
      ),
    );
  }
}

class InputWidget extends StatefulWidget {
  const InputWidget({super.key});

  @override
  State<InputWidget> createState() => _InputWidgetState();
}

class _InputWidgetState extends State<InputWidget> {
  final TextEditingController _controller = TextEditingController();
  String _displayText = "";

  @override
  Widget build(BuildContext context) {
    return Padding(
      padding: const EdgeInsets.all(10),
      child: Column(
        mainAxisAlignment: MainAxisAlignment.start,
        crossAxisAlignment: CrossAxisAlignment.start,
        children: [
          // Заголовок
          const Text(
            "Введите текст:",
            style: TextStyle(fontSize: 16),
          ),
          const SizedBox(height: 10),

          // Поле ввода текста
          TextField(
            controller: _controller,
            decoration: const InputDecoration(
              border: OutlineInputBorder(),
              hintText: "Введите что-то",
            ),
          ),
          const SizedBox(height: 10),

          // Кнопка
          ElevatedButton(
            onPressed: () {
              setState(() {
                _displayText = _controller.text;
              });
            },
            child: const Text("Показать текст"),
          ),
          const SizedBox(height: 10),

          // Вывод текста
          Text(
            _displayText,
            style: const TextStyle(fontSize: 16, color: Colors.blue),
          ),
        ],
      ),
    );
  }
}
Отредактировано 19.12.2024 4:43 Shmj . Предыдущая версия .
Re[2]: Самый удобный человеко-читаемый язык данных
От: Shmj Ниоткуда  
Дата: 19.12.24 05:00
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>XML это по сути дерево.

vsb>JSON это отображения (maps) плюс массивы.

Ну и там и там же иерархия и уровни вложенности:

<node name="Root">
  <node name="Child1">
    <node name="Grandchild1" value="Grandchild1Value" />
    <node name="Grandchild2" value="Grandchild2Value" />
  </node>
  <node name="Child2">
    <node name="Grandchild3" value="Grandchild3Value" />
  </node>
</node>


{
   "Root":[
      { "Child1":[
            {"Grandchild1": "Grandchild1Value"},
            {"Grandchild2": "Grandchild2Value" }
         ]},
      { Child2":[{"Grandchild3": "Grandchild3Value" }]}
   ]
}


— что вам удобнее?

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


Ну хотя бы меньше лишних символов, которые замыливают глаз.

vsb>Будет ли что-то ещё? Наверное зависит от развития языков программирования. JSON рождён от JavaScript-а. Когда-то были популярны S-выражения. Уйдёт JavaScript, придёт что-то другое, я так думаю.


Сейчас он уже с JS не связан...
Re[3]: Самый удобный человеко-читаемый язык данных
От: so5team https://stiffstream.com
Дата: 19.12.24 06:03
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Ну и там и там же иерархия и уровни вложенности:


S>
S><node name="Root">
S>  <node name="Child1">
S>    <node name="Grandchild1" value="Grandchild1Value" />
S>    <node name="Grandchild2" value="Grandchild2Value" />
S>  </node>
S>  <node name="Child2">
S>    <node name="Grandchild3" value="Grandchild3Value" />
S>  </node>
S></node>
S>


S>
S>{
S>   "Root":[
S>      { "Child1":[
S>            {"Grandchild1": "Grandchild1Value"},
S>            {"Grandchild2": "Grandchild2Value" }
S>         ]},
S>      { Child2":[{"Grandchild3": "Grandchild3Value" }]}
S>   ]
S>}
S>


S>- что вам удобнее?


Что-то типа:

{node {name "Root"}
  {node {name "Child1"}
    {node {name "GrandChild1"} "GrandChild1Value"}
    {node {name "GrandChild2"} "GrandChild2Value"}
  }
  {node {name "Child2"}
    {node {name "GrandChild3"} "GrandChild3Value"}
  }
}

Фигурные скобки можно заменить на круглые (чтобы получились привычные некоторым s-expressions), но смысла это не изменит.

Из собственного опыта -- когда в разметке можно добавлять новые теги/атрибуты для "узла", то это очень удобно.
Например, было
{node {name "GrandChild1"} "GrandChildValue"}}
со временем стало
{node {name "GrandChild1" {alias "Bob Jr"}} "GrandChildValue" {mandatory}}
Причем такая теговая/атрибутная система позволяет поддерживать обратную совместимость с уже имеющимися данными.
Re[4]: Самый удобный человеко-читаемый язык данных
От: Shmj Ниоткуда  
Дата: 19.12.24 06:24
Оценка:
Здравствуйте, so5team, Вы писали:

S>Что-то типа:


S>
S>{node {name "Root"}
S>  {node {name "Child1"}
S>    {node {name "GrandChild1"} "GrandChild1Value"}
S>    {node {name "GrandChild2"} "GrandChild2Value"}
S>  }
S>  {node {name "Child2"}
S>    {node {name "GrandChild3"} "GrandChild3Value"}
S>  }
S>}
S>


А в чем смысловая нагрузка node?

S>Фигурные скобки можно заменить на круглые (чтобы получились привычные некоторым s-expressions), но смысла это не изменит.


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

Возможно вместо кавычек удобнее было бы знак ` — не путать с ' и ’.
Re[5]: Самый удобный человеко-читаемый язык данных
От: so5team https://stiffstream.com
Дата: 19.12.24 06:33
Оценка:
Здравствуйте, Shmj, Вы писали:

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


S>>Что-то типа:


S>>
S>>{node {name "Root"}
S>>  {node {name "Child1"}
S>>    {node {name "GrandChild1"} "GrandChild1Value"}
S>>    {node {name "GrandChild2"} "GrandChild2Value"}
S>>  }
S>>  {node {name "Child2"}
S>>    {node {name "GrandChild3"} "GrandChild3Value"}
S>>  }
S>>}
S>>


S>А в чем смысловая нагрузка node?


В том, что вы можете сочетать node с любыми другими типами "узлов", которые могут быть на одном уровне иерархии.
Грубо говоря:
{node ...}
{page ...}
{topic ...}
{sub-topic ...}
...

Здесь под "узлом" понимается не перевод слова "node", а узел в иерархически-организованной структуре данных. Вроде:
{config {version "1.0"}
  {auth-params
    {user-name "joesmith"}
    {password "..."}
  }
  {log-params
    {path "..."}
    {max-file-size 1024 {mb}}
    {rotation off}
  }
  ...
}


S>>Фигурные скобки можно заменить на круглые (чтобы получились привычные некоторым s-expressions), но смысла это не изменит.


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


Да фиолетово, на самом деле. Доколупываться к {} или () можете разве что вы. Да еще и с аргументами из категории "в гуманоидном языке".
Re: Самый удобный человеко-читаемый язык данных
От: ononim  
Дата: 19.12.24 07:20
Оценка: +1
S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
ini files forever
Как много веселых ребят, и все делают велосипед...
Re: Самый удобный человеко-читаемый язык данных
От: andrey.desman  
Дата: 19.12.24 08:28
Оценка: +2 :)
Здравствуйте, Shmj, Вы писали:

S>После начали т.н. YAML, но как-то не особо, т.к. все-таки он не особо лучше, но сложнее. Удобство в читабельности сомнительное, а сам формат намного сложнее.


Сильно удобнее и проще. Ну то есть, для парсинга может и сложнее, но ты же про человеко-читаемость и удобство редактирования?

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


JSON как раз говно то еще для чтения и правки.
Re[2]: Самый удобный человеко-читаемый язык данных
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.12.24 09:05
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>XML это по сути дерево.


vsb>JSON это отображения (maps) плюс массивы.


vsb>XML хорош для моделирования древовидных данных. А вот массивы в него ложатся плохо.


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

Я не вижу глубокой логической разницы межд XML и JSON. Просто XML сделан "всерьез и навека", от этого в нём столько лишних сложностей, что сдохнуть можно. JSON в этом плане значительно удобнее/проще.

vsb>Отсутствие вменяемой общепринятой спецификации. К примеру простые вопросы. Какие числа можно передавать? Что происходит при дублировании ключей? Это отдаётся на откуп конкретной реализации, что вызывает проблемы при взаимодействии, к примеру в JS целые числа ограничечны 2^52.


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

vsb>Не специфицирована кодировка текста, т.е. нет однозначного отображения объекта в байты, только в строку.


UTF-8 же.

Раздражает, что нет синтаксиса для передачи бинарных данных (массива байт).
Re[2]: Самый удобный человеко-читаемый язык данных
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.12.24 09:07
Оценка:
Здравствуйте, ononim, Вы писали:

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

O>ini files forever

+100500, я тоже их люблю. Как минимум, для конфигов.
Re: Самый удобный человеко-читаемый язык данных
От: Нomunculus Россия  
Дата: 19.12.24 09:10
Оценка:
Здравствуйте, Shmj, Вы писали:

Json не идеален. Но ГОРАЗДО удобнее xml.
В json-e мало визуального мусора, но на один экран мало убирается информации.

Но у json-а еще один плюс — примитивность парсера
Re: Самый удобный человеко-читаемый язык данных
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 19.12.24 09:32
Оценка:
Здравствуйте, Shmj, Вы писали:

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

Сейчас используют gRPC и ProtoBuf

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

Например таблицу проще хранить в Sqlite и смотреть ей в редакторе и отбирать.
и солнце б утром не вставало, когда бы не было меня
Re[3]: Самый удобный человеко-читаемый язык данных
От: Osaka  
Дата: 19.12.24 09:47
Оценка:
O>>Для данных человечество придумало Excel.
S>Это уже через инструмент. А иногда нужно чтобы во прямо текст в чистом виде
Текст, внезапно, тоже не в чистом виде с диска, а через хотя бы notepad. Заменить notepad на 2-оконный редактор, как я выше написал — и степень читаемости формата становится маловажной.
>с помощью простейшего текстового редактора
Зачем? Вы бы пошли к врачу, который лечит "простейшим" лекарством, вместо какого надо, и считает это за достижение?
>И почти все данные верхнего уровня (HTML, CSS, JSON, XML) — они передаются в человеко-читаемом виде, хотя могли бы юзать бинарный формат.
Вы так говорите, как будто это что-то хорошее. А в итоге имеем повсеместное "300 метров жабаскрипта грузят текста 2 строки"
S>Но чтобы легче было писать эти инструменты — разработчику лучше человеко-читаемый а не бинарный формат.
Изначально пишется 1 раз на ассемблере, далее на самом себе.
S>Сейчас вопрос о то что снизу — какой формат там удобнее. XML — банально больше лишних символов, что утомляет.
S>Вот, для примера, что вам удобнее читать:
S><Window x:Class="ExampleApp.MainWindow"
S> children: [
Всё неудобно. Мне бы чтобы в дизайнере открыть форму, ткнуть нужный контрол, редактор бы _не переключая окно_ отпозиционировался в нужное место длинного текста, и я бы там отредактировал несколько символов, не читая всё остальное. (В редакторе xaml такое есть с 2005г.)
Re[2]: Самый удобный человеко-читаемый язык данных
От: rudzuk  
Дата: 19.12.24 10:03
Оценка:
Здравствуйте, Нomunculus, Вы писали:

Н> Но у json-а еще один плюс — примитивность парсера


Примитивность говоришь...
avalon/3.0.2
Re[2]: Самый удобный человеко-читаемый язык данных
От: rudzuk  
Дата: 19.12.24 10:05
Оценка:
Здравствуйте, vsb, Вы писали:

vsb> В целом у JSON хватает мелких, но противных проблем.


vsb> ...


Вообще, эти вопросы так или иначе затронуты в rfc7159. И про числа и про кодировки.
avalon/3.0.2
Re[3]: Самый удобный человеко-читаемый язык данных
От: vsb Казахстан  
Дата: 19.12.24 12:02
Оценка:
Здравствуйте, Shmj, Вы писали:

S>
S><node name="Root">
S>  <node name="Child1">
S>    <node name="Grandchild1" value="Grandchild1Value" />
S>    <node name="Grandchild2" value="Grandchild2Value" />
S>  </node>
S>  <node name="Child2">
S>    <node name="Grandchild3" value="Grandchild3Value" />
S>  </node>
S></node>
S>


S>
S>{
S>   "Root":[
S>      { "Child1":[
S>            {"Grandchild1": "Grandchild1Value"},
S>            {"Grandchild2": "Grandchild2Value" }
S>         ]},
S>      { Child2":[{"Grandchild3": "Grandchild3Value" }]}
S>   ]
S>}
S>


S>- что вам удобнее?


Мне удобней такой XML:

<Root>
  <Child1>
    <Grandchild1 value="Grandchild1Value" />
    <Grandchild2 value="Grandchild2Value" />
  </Child1>
  <Child2>
    <Grandchild3 value="Grandchild3Value" />
  </Child2>
</Root>


А с JSON лукавство. На практике он будет отформатирован автоматически и будет выглядеть как-то так:

{
  "Root": [
    {
      "Child1": [
        {
          "Grandchild1": "Grandchild1Value"
        },
        {
          "Grandchild2": "Grandchild2Value"
        }
      ]
    },
    {
      "Child2": [
        {
          "Grandchild3": "Grandchild3Value"
        }
      ]
    }
  ]
}



S>Ну хотя бы меньше лишних символов, которые замыливают глаз.


У XML лишние символы это закрывающие теги. Остальное плюс-минус такое же. При этом в больших документах эти закрывающие теги на самом деле помогают ориентироваться в структуре. Поэтому я бы не утверждал однозначно, что они такие уж лишние.
Re[3]: Самый удобный человеко-читаемый язык данных
От: vsb Казахстан  
Дата: 19.12.24 12:13
Оценка:
Здравствуйте, Pzz, Вы писали:

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


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

Только вводить тег <array>. Ну так, конечно, можно что угодно во что угодно преобразовать. Но выглядеть это будет страшновато...

Pzz>Я не вижу глубокой логической разницы межд XML и JSON. Просто XML сделан "всерьез и навека", от этого в нём столько лишних сложностей, что сдохнуть можно. JSON в этом плане значительно удобнее/проще.


Попробуй подумать над тем, как сделать преобразователь JSON-XML-JSON или XML-JSON-XML. Чтобы двойное преобразование возвращало идентичный документ/объект для произвольного входа. И при этом промежуточный JSON или XML не вызывал желания выпрыгнуть в окно. Я такого способа не придумал. И это как раз из-за принципиального несовпадения между моделями данных у XML и JSON.

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


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

https://www.json.org/json-en.html вот "спецификация". Про number написан только синтаксис, никаких ограничений.

vsb>>Не специфицирована кодировка текста, т.е. нет однозначного отображения объекта в байты, только в строку.


Pzz>UTF-8 же.


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

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


Обычно в base64 передают.
Отредактировано 19.12.2024 12:17 vsb . Предыдущая версия . Еще …
Отредактировано 19.12.2024 12:16 vsb . Предыдущая версия .
Re[2]: Самый удобный человеко-читаемый язык данных
От: Maniacal Россия  
Дата: 19.12.24 12:18
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Есть визуализаторы

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

Тогда и в ASN.1 можно хранить, для него есть визуализаторы.
Re[4]: Самый удобный человеко-читаемый язык данных
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.12.24 12:29
Оценка: 1 (1)
Здравствуйте, 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 сначала декодировать. Схемы/метаданных-то нету...
Re[3]: Самый удобный человеко-читаемый язык данных
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.12.24 12:38
Оценка:
Здравствуйте, Maniacal, Вы писали:

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


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


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

ASN.1 — это для любителей садо-мазо.
Re[2]: Самый удобный человеко-читаемый язык данных
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 19.12.24 12:47
Оценка: :)
Здравствуйте, vsb, Вы писали:

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


base64?
Re: Самый удобный человеко-читаемый язык данных
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 19.12.24 12:48
Оценка: :)
Здравствуйте, Shmj, Вы писали:

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


Ещё из популярных есть protobuf/flatbuffers. И байты умеют экономить, и в скорость, и умеют сериализовываться в тот же json, если хочется почитать глазами.
Re[3]: Самый удобный человеко-читаемый язык данных
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 19.12.24 12:59
Оценка:
Здравствуйте, Maniacal, Вы писали:

S>>Есть визуализаторы

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

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

В любом формате если есть визуализатор.
Никто же не будет делать БД на JSON. Хотя и поддерживают его для хранения документов и поиска.
Для просмотра JSON тоже нужен визуализатор в виде редактора текста
и солнце б утром не вставало, когда бы не было меня
Re[4]: Самый удобный человеко-читаемый язык данных
От: Maniacal Россия  
Дата: 19.12.24 13:03
Оценка:
Здравствуйте, Pzz, Вы писали:

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


Да, стандарт принятый, как официальный, например, у телекоммуникационных компаний. Столкнулся с ним, когда генератор роуминговых файлов для МТС поддерживал. Там одно неверное движение и придётся человекочитанием человеконечитаемый hex-код парсить на соответствие схеме, искать ошибку. А так там и деревья и массивы и всё что угодно есть.
Re[5]: Самый удобный человеко-читаемый язык данных
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.12.24 13:23
Оценка:
Здравствуйте, Maniacal, Вы писали:

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


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


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

X.509 — даже и название-то такое, телефонистское
Re[4]: Самый удобный человеко-читаемый язык данных
От: Shmj Ниоткуда  
Дата: 19.12.24 20:14
Оценка: +1
Здравствуйте, Pzz, Вы писали:

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

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

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

Далее — тот же GIT — ведь удобно в DIFF-ах смотреть что поменялось.
Re: Самый удобный человеко-читаемый язык данных
От: velkin Удмуртия https://kisa.biz
Дата: 19.12.24 21:20
Оценка:
Здравствуйте, Shmj, Вы писали:

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


Суперобучение с помощью карточек (07.11.2024)
Re: Самый удобный человеко-читаемый язык данных
От: Aquilaware  
Дата: 19.12.24 23:21
Оценка:
Здравствуйте, Shmj, Вы писали:

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


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

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

const myVar = "Top$ecret";

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

export default config;
Re[5]: Самый удобный человеко-читаемый язык данных
От: Pzz Россия https://github.com/alexpevzner
Дата: 20.12.24 00:07
Оценка:
Здравствуйте, Shmj, Вы писали:

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


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

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


Если, к примеру, в миллионе строк кода переименовать какую-нибудь популярную переменную или изменить стиль форматирования, такой diff смотреть будет люто неудобно.
Re[6]: Самый удобный человеко-читаемый язык данных
От: Shmj Ниоткуда  
Дата: 20.12.24 05:48
Оценка:
Здравствуйте, Pzz, Вы писали:

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


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

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

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

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

Но речь же о файлах, которые создают люди и редактируют люди.
Re: Самый удобный человеко-читаемый язык данных
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.12.24 08:32
Оценка:
Здравствуйте, Shmj, Вы писали:

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

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


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

S>Потом все более и более JSON.
S>После начали т.н. YAML, но как-то не особо, т.к. все-таки он не особо лучше, но сложнее. Удобство в читабельности сомнительное, а сам формат намного сложнее.


Тут надо понимать, что есть человек-читаемость, а есть человеко-писаемость. И xml, и JSON легко читать, но довольно неудобно писать. Схемы конечно упрощают, но не до конца. YAML легко писать пользователю.
Re[2]: Самый удобный человеко-читаемый язык данных
От: Shmj Ниоткуда  
Дата: 20.12.24 14:41
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

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


Я боюсь писать YAML. Особенно если нет подсветки. Вдруг где-то пробел не заметишь — и хана.
Re: Самый удобный человеко-читаемый язык данных
От: пффф  
Дата: 20.12.24 16:42
Оценка: +1 -1 :)
Здравствуйте, Shmj, Вы писали:

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

Плюс, в XML, даже если ты не знаешь схемы, можно по тэгам примерно понять структуру документа/конфига/итп, под джейсону — хрен там был
Отредактировано 20.12.2024 16:48 пффф . Предыдущая версия .
Re[5]: Самый удобный человеко-читаемый язык данных
От: пффф  
Дата: 20.12.24 16:43
Оценка: -1 :)
Здравствуйте, Shmj, Вы писали:

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


Круглые скобки есть в русской и английской раскладках, фигурные только в английской
Отредактировано 20.12.2024 16:44 пффф . Предыдущая версия .
Re[6]: Самый удобный человеко-читаемый язык данных
От: Shmj Ниоткуда  
Дата: 20.12.24 18:17
Оценка:
Здравствуйте, пффф, Вы писали:

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


Так вы же названия нод — все-равно на англ. пишите.
Re: Самый удобный человеко-читаемый язык данных
От: kov_serg Россия  
Дата: 20.12.24 20:23
Оценка:
Здравствуйте, Shmj, Вы писали:

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

plain text
Re[3]: Самый удобный человеко-читаемый язык данных
От: Codealot Земля  
Дата: 22.12.24 15:41
Оценка:
Здравствуйте, Shmj, Вы писали:

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


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

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


Лучше всего сделать взаимо однозначный конвертор текст <-> бинарник. Использовать текст для объемистых данных — просто идиотизм.
Ад пуст, все бесы здесь.
Re[4]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 22.12.24 18:11
Оценка: +1
Здравствуйте, Codealot, Вы писали:

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


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

PS: Но это текстовое представление, должен заметить, должно быть скорее "полутекстовым". В нём не должно быть "грамматизьмы" ранних подходов IETF, где 100500 форматов представления одного и того же ради возможности отформатировать в ASCII art (ещё этим страдает YAML). Числа желательно представлять в шестнадцатиричном (или хотя бы свободно позволять это), включая float'ы.
The God is real, unless declared integer.
Отредактировано 22.12.2024 18:37 netch80 . Предыдущая версия .
Re[6]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 22.12.24 18:14
Оценка:
Здравствуйте, Pzz, Вы писали:

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


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


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


TLS сам по себе как раз не ASN.1, там собственный формат сериализации.

Pzz> X.509, SNMP, LDAP...


У этих хоть BER, структура читается без схемы.

А вот в H.323 и 3GPP стандартах PER. Вот это совсем ад и сектор газы.
The God is real, unless declared integer.
Re[7]: Самый удобный человеко-читаемый язык данных
От: Pzz Россия https://github.com/alexpevzner
Дата: 22.12.24 18:16
Оценка:
Здравствуйте, netch80, Вы писали:

N>А вот в H.323 и 3GPP стандартах PER. Вот это совсем ад и сектор газы.


Вопчем, враги, маньяки и диверсанты.
Re[2]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 22.12.24 18:18
Оценка: 1 (1)
Здравствуйте, vsb, Вы писали:

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


Почитайте это
Автор: Слава
Дата: 19.11.15
, например

Или как устроены описания структур данных в Cobol и RPG.

Сразу мифы будут развеяны.

vsb> По этому критерию и XML и JSON и YAML человеко-читаемы.


Да, это поколение уже читаемо.
The God is real, unless declared integer.
Re[3]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 22.12.24 18:26
Оценка: +1
Здравствуйте, Pzz, Вы писали:

vsb>>Отсутствие вменяемой общепринятой спецификации. К примеру простые вопросы. Какие числа можно передавать? Что происходит при дублировании ключей? Это отдаётся на откуп конкретной реализации, что вызывает проблемы при взаимодействии, к примеру в JS целые числа ограничечны 2^52.

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

Но в стандарте JSON этого ограничения нет. Есть пожелание типа "поскольку большинство диверсантов реализует числа через IEEE754 double, выход за его пределы чреват боком". Но это не требование.

А попутно я должен заметить, что поскольку компьютеры хранят числа в двоичке, а JSON требует только десятичных форматов, требуется преобразование, которое дорого как по затратам времени (растёт квадратично от размера числа), так и по сложности кода (обычная процедура точной конверсии double это простыня кода, на понимание которого уйдёт два ящика водки). Ещё и возможная проблема урезания значения. Разрешить представлять в стиле 0x1.921fb54442d18p+1 было бы полезнее.

Поэтому JSON таки диверсия.

vsb>>Не специфицирована кодировка текста, т.е. нет однозначного отображения объекта в байты, только в строку.

Pzz>UTF-8 же.

Ну 8259 на этом настаивает, да, а вот предыдущий 7159 — нет.

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


Да, нужен base64, base32, hex, или любой из них. Увы.

Интересно, что в CBOR сделали наоборот. Он бинарный, но к типу bytestring можно прилепить тег "в текстовом виде это должно быть base64".
The God is real, unless declared integer.
Re[4]: Самый удобный человеко-читаемый язык данных
От: Pzz Россия https://github.com/alexpevzner
Дата: 22.12.24 18:30
Оценка:
Здравствуйте, netch80, Вы писали:

N>А попутно я должен заметить, что поскольку компьютеры хранят числа в двоичке, а JSON требует только десятичных форматов, требуется преобразование, которое дорого как по затратам времени (растёт квадратично от размера числа), так и по сложности кода (обычная процедура точной конверсии double это простыня кода, на понимание которого уйдёт два ящика водки). Ещё и возможная проблема урезания значения. Разрешить представлять в стиле 0x1.921fb54442d18p+1 было бы полезнее.


Но при этом должен заметить, что очень часто бывает так, что большинство передаваемых чисел — маленькие целые. И если JSON тратит на число в диапазоне от 10 до 99 два байта, то наивно спроектированный бинарный формат (т.е., использующий фиксированное количество байтов, 4 или 8, для каждого числа) будет тратить больше.
Re[5]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 22.12.24 18:34
Оценка:
Здравствуйте, Pzz, Вы писали:

N>>А попутно я должен заметить, что поскольку компьютеры хранят числа в двоичке, а JSON требует только десятичных форматов, требуется преобразование, которое дорого как по затратам времени (растёт квадратично от размера числа), так и по сложности кода (обычная процедура точной конверсии double это простыня кода, на понимание которого уйдёт два ящика водки). Ещё и возможная проблема урезания значения. Разрешить представлять в стиле 0x1.921fb54442d18p+1 было бы полезнее.


Pzz>Но при этом должен заметить, что очень часто бывает так, что большинство передаваемых чисел — маленькие целые. И если JSON тратит на число в диапазоне от 10 до 99 два байта, то наивно спроектированный бинарный формат (т.е., использующий фиксированное количество байтов, 4 или 8, для каждого числа) будет тратить больше.


Ну как бинарный формат к JSON — IETF активно продвигает CBOR. А в нём такой проблемы нет. Числа в диапазоне -24..23 минимально (и рекомендованно) представляются одним байтом, -256..255 — двумя. Вообще по сравнению со многими альтернативами он суперкомпактен.
The God is real, unless declared integer.
Re[5]: Самый удобный человеко-читаемый язык данных
От: Codealot Земля  
Дата: 22.12.24 23:41
Оценка:
Здравствуйте, netch80, Вы писали:

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


Расшифруй.

N>пользы от текстового представления — вагоны.


Ноль. В норме, тебе не нужно читать данные в сыром виде.
Ад пуст, все бесы здесь.
Re[6]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 23.12.24 07:27
Оценка:
Здравствуйте, Codealot, Вы писали:

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

C>Расшифруй.

Что непонятного в оценке затрат процессора на какие-то виды работы? Что именно расшифровать?

N>>пользы от текстового представления — вагоны.

C>Ноль. В норме, тебе не нужно читать данные в сыром виде.

Эта "норма" никогда не выполняется даже в обычном продуктине, а тем более в пусконаладочных работах, в отладке и разработке.
The God is real, unless declared integer.
Re[7]: Самый удобный человеко-читаемый язык данных
От: Codealot Земля  
Дата: 23.12.24 16:34
Оценка:
Здравствуйте, netch80, Вы писали:

N>Что непонятного в оценке затрат процессора на какие-то виды работы? Что именно расшифровать?


Непонятно, чем твои оценки обоснованы. Какие конкретно сценарии ты сравнивал? Бенчмарки писал?

N>Эта "норма" никогда не выполняется даже в обычном продуктине, а тем более в пусконаладочных работах, в отладке и разработке.


Прямо-таки никогда? Ты сам проверял все проекты в мире, чтобы в этом удостовериться?
Ад пуст, все бесы здесь.
Отредактировано 23.12.2024 16:55 Codealot . Предыдущая версия .
Re[3]: Самый удобный человеко-читаемый язык данных
От: Pzz Россия https://github.com/alexpevzner
Дата: 23.12.24 17:45
Оценка: :)
Здравствуйте, netch80, Вы писали:

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


N>Почитайте это
Автор: Слава
Дата: 19.11.15
, например


Я как-то в 90-е (или в нулевые?) зашел в маленькую фирмочку по продаже авиабилетов. Это было еще до тех времен, когда эту нишу заняли интернет-агрегаторы.

И там сидел мужичок и с помощью терминала лихо изъяснялся с системой по продаже билетов на каком-то вот примерно таком языке. Руками вводил запросы и свободно понимал ответы.

Видимо, к системе его подключили, а програмки с человеческим интерфейсом не дали. Но это мужика совершенно не смущало.
Re: Самый удобный человеко-читаемый язык данных
От: bobby23  
Дата: 24.12.24 06:55
Оценка:
Здравствуйте, Shmj, Вы писали:

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


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


S>После начали т.н. YAML, но как-то не особо, т.к. все-таки он не особо лучше, но сложнее. Удобство в читабельности сомнительное, а сам формат намного сложнее.


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


может иероглифы, там плотность информации выше

и такой протокол

0.Root
0.0.node=value0.0
0.1.node
0.1.0.node=valuexxx
0.1.1.node=valuexxx
1.Root2
1.0.node=value1.0

Отредактировано 24.12.2024 16:39 bobby23 . Предыдущая версия . Еще …
Отредактировано 24.12.2024 7:03 bobby23 . Предыдущая версия .
Отредактировано 24.12.2024 7:03 bobby23 . Предыдущая версия .
Отредактировано 24.12.2024 7:02 bobby23 . Предыдущая версия .
Re[2]: Самый удобный человеко-читаемый язык данных
От: korvin_  
Дата: 27.12.24 07:59
Оценка: +2
Здравствуйте, vsb, Вы писали:

vsb>YAML это альтернативный синтаксис для JSON.


Лол. Вам не кажется, что для "альтернативного синтаксиса для JSON", у YAML слишком большая спецификация по сравнению с JSON?
Re[3]: Самый удобный человеко-читаемый язык данных
От: rudzuk  
Дата: 27.12.24 09:59
Оценка:
Здравствуйте, korvin_, Вы писали:

k> vsb>YAML это альтернативный синтаксис для JSON.


k> Лол. Вам не кажется, что для "альтернативного синтаксиса для JSON", у YAML слишком большая спецификация по сравнению с JSON?


Тоже при#уел с ямла после чтения спеки
avalon/3.0.2
Re[3]: Самый удобный человеко-читаемый язык данных
От: vsb Казахстан  
Дата: 27.12.24 11:59
Оценка: -1
Здравствуйте, korvin_, Вы писали:

vsb>>YAML это альтернативный синтаксис для JSON.


_>Лол. Вам не кажется, что для "альтернативного синтаксиса для JSON", у YAML слишком большая спецификация по сравнению с JSON?


Это не имеет значения. Во-первых JSON это подмножество YAML, т.е. любой JSON документ автоматически является YAML-документом. Во-вторых любой YAML-документ однозначно преобразуется в JSON-документ. Единственное исключение это YAML Fragments, это когда в одном файле можно задавать несколько объектов, т.е. несколько JSON-документов, по сути тривиальное расширение.
Re[2]: Самый удобный человеко-читаемый язык данных
От: m2user  
Дата: 28.12.24 07:37
Оценка:
A>Еще один хороший вариант — это JavaScript/TypeScript в качестве языка конфигурации. Преимущество в том, что если нужно обьявить, например, переменную, а затем её использовать несколько раз в разных местах конфигурации, то это делается штатными средствами языка:

Кстати на php конфиги тоже неплохие.
(для всяких там веб-приложений, написанных на php)
Re[2]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.12.24 08:24
Оценка:
Здравствуйте, bobby23, Вы писали:

B>может иероглифы, там плотность информации выше


Если пересчитать на биты реального содержания — нет, не выше.

B>и такой протокол

B>

B>0.Root
B> 0.0.node=value0.0
B> 0.1.node
B> 0.1.0.node=valuexxx
B> 0.1.1.node=valuexxx
B>1.Root2
B> 1.0.node=value1.0


А смысл?
The God is real, unless declared integer.
Re[3]: Самый удобный человеко-читаемый язык данных
От: bobby23  
Дата: 28.12.24 08:40
Оценка:
Здравствуйте, netch80, Вы писали:

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


B>>может иероглифы, там плотность информации выше


N>Если пересчитать на биты реального содержания — нет, не выше.


B>>и такой протокол

B>>

B>>0.Root
B>> 0.0.node=value0.0
B>> 0.1.node
B>> 0.1.0.node=valuexxx
B>> 0.1.1.node=valuexxx
B>>1.Root2
B>> 1.0.node=value1.0


N>А смысл?


просто один из вариантов, в разных ситуациях выгоднее разные протоколы
Re[3]: Самый удобный человеко-читаемый язык данных
От: bobby23  
Дата: 28.12.24 08:42
Оценка:
Здравствуйте, netch80, Вы писали:

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


B>>может иероглифы, там плотность информации выше


N>Если пересчитать на биты реального содержания — нет, не выше.


китайская кракозябра короче английской

B>>и такой протокол

B>>

B>>0.Root
B>> 0.0.node=value0.0
B>> 0.1.node
B>> 0.1.0.node=valuexxx
B>> 0.1.1.node=valuexxx
B>>1.Root2
B>> 1.0.node=value1.0


N>А смысл?


думаю плотнее, любая китайская кракозябра короче английской
Отредактировано 28.12.2024 8:43 bobby23 . Предыдущая версия .
Re[4]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.12.24 08:56
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Это не имеет значения. Во-первых JSON это подмножество YAML, т.е. любой JSON документ автоматически является YAML-документом.


Да.

vsb> Во-вторых любой YAML-документ однозначно преобразуется в JSON-документ.


Нет, это прямая неправда. Настолько прямая и тупая, что непонятно, зачем вы это рассказываете — проверить можно в пять минут.

В стандарте (смотрю по последнему, 1.2.2 — это важно) есть:

1. Теги. Теги — это то, что интерпретируется парсером по своему вкусу (обычно, вызывая соответствующий конструктор типа), кроме стандартных. В JSON нет тегов.

2. Двоичные данные, тегом !!binary. В JSON аналога нет. Вложить в него можно только если ввести какое-то дополнительное условие, как именно двоичные данные будут представлены — как правило, строка в base64 или в hex, однозначности тут нет.

3. Ordered mapping, тегом !!omap. Аналога в JSON нет. Даже если основные реализации в основных языках (JS, Python) автоматически используют именно ordered mapping (LinkedHashSet), реального такого требования нет.

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

Вот например смотрим сюда и видим

As it turns out, numbers from 0 to 59 separated by colons are sexagesimal (base 60) number literals. This arcane feature was present in yaml 1.1, but silently removed from yaml 1.2, so the list element will parse as 1342 or "22:22" depending on which version your parser uses. Although yaml 1.2 is more than 10 years old by now, you would be mistaken to think that it is widely supported: the latest version libyaml at the time of writing (which is used among others by PyYAML) implements yaml 1.1 and parses 22:22 as 1342.


Только не надо рассказывать про то, что все обязаны были сразу перейти на последнюю версию — это так не работает. Там же дальше:

The change from yaml 1.2.1 to 1.2.2 on the other hand, was a multi-year effort by a team of experts


И это, да, прямое следствие "слишком большой" спецификации, когда люди не в состоянии оценить все последствия того, что они туда напихали. Стандарты YAML чудовищно переусложнены непонятно зачем и это даёт реальные проблемы.

Вероятно, вы используете одну версию парсера и совместимый с ней генератор, или же намеренно ограничиваете возможности только человекобезопасными синтаксисами. Тогда вы могли проскочить и не заметить ни одной из этих проблем. Но не надо рассказывать, что их нет.
The God is real, unless declared integer.
Re[4]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.12.24 09:00
Оценка:
Здравствуйте, bobby23, Вы писали:

B>китайская кракозябра короче английской


Если вы станете записывать английские слова блоками по 4-6-9 букв в одном "символе", как эквивалент того, что творят в китайской письменности — английский текст будет ещё короче. Ну да, вам потребуется нагенерировать, как в китайском, пару десятков тысяч таких символов на основные допустимые сочетания.

A qui br  fo jum ov t  la do
  ck  own x  ps  er he zy g


N>>А смысл?


B>думаю плотнее, любая китайская кракозябра короче английской


Вопрос был про тот пример, где "0.1.0.node=valuexxx", а не про китайщину. Итак?
The God is real, unless declared integer.
Re[5]: Самый удобный человеко-читаемый язык данных
От: vsb Казахстан  
Дата: 28.12.24 09:07
Оценка:
Можно конкретный YAML-документ, который я не могу через `yq -o json` в JSON преобразовать?
Re[6]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.12.24 09:16
Оценка: 2 (1)
Здравствуйте, vsb, Вы писали:

vsb>Можно конкретный YAML-документ, который я не могу через `yq -o json` в JSON преобразовать?


Постановка вопроса некорректна. Не вообще преобразовать, а преобразовать согласно стандарту, однозначно и без потери данных.

Про теги я уже сказал. Но вот возьмём пример с binary, взятый напрямую из текста стандарта: вход:

picture: !!binary |
 R0lGODlhDAAMAIQAAP//9/X
 17unp5WZmZgAAAOfn515eXv
 Pz7Y6OjuDg4J+fn5OTk6enp
 56enmleECcgggoBADs=


Выхлоп yq:

{
  "picture": "R0lGODlhDAAMAIQAAP//9/X\n17unp5WZmZgAAAOfn515eXv\nPz7Y6OjuDg4J+fn5OTk6enp\n56enmleECcgggoBADs=\n"
}


Признак того, что это должны быть двоичные данные — потерян (но он и не мог быть в JSON).
В свёрнутом base64 присутствуют дополнительные LF, присутствие которых должно быть ещё обосновано — в стандартном base64 их не полагается, должны быть убраны при чтении из внешнего представления. Итого, поведение yq является его авторским произволом и не отражает сути описанного в спеке.

Вот именно так и надо рассматривать возможное поведение, а не просто "во что-то преобразовал, а во что именно — да и хрен с ним".
The God is real, unless declared integer.
Re[6]: Самый удобный человеко-читаемый язык данных
От: korvin_  
Дата: 28.12.24 10:12
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Можно конкретный YAML-документ, который я не могу через `yq -o json` в JSON преобразовать?


Попробуйте файлики отсюда: https://github.com/dubniczky/Yaml-Bomb

Не то, что бы их все совсем невозможно преобразовать, но есть нюансик.
Отредактировано 28.12.2024 10:25 korvin_ . Предыдущая версия .
Re[7]: Самый удобный человеко-читаемый язык данных
От: vsb Казахстан  
Дата: 28.12.24 10:51
Оценка:
Ок, но всё же я считаю, что на практике YAML и JSON полностью идентичны. Все инструменты, с которыми я работал, где применялся YAML, принимали JSON и YAML являлся лишь чуть более удобной формой представления тех же структур. Можно называть это практически применяемым подмножеством YAML. Что в YAML есть какие-то теги, я узнал только сегодня, несмотря на то, что применяю его много лет, и нигде их не видел.
Отредактировано 28.12.2024 10:53 vsb . Предыдущая версия .
Re[8]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.12.24 14:56
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Ок, но всё же я считаю, что на практике YAML и JSON полностью идентичны. Все инструменты, с которыми я работал, где применялся YAML, принимали JSON и YAML являлся лишь чуть более удобной формой представления тех же структур. Можно называть это практически применяемым подмножеством YAML. Что в YAML есть какие-то теги, я узнал только сегодня, несмотря на то, что применяю его много лет, и нигде их не видел.


В таком варианте — да. Такой себе "реальный YAML для реальных применений".

Жаль, на него нет отдельного стандарта. (На практике и то, что называется у YAML "стандартом", не соответствует аж никак правилам написания подобных документов — это просто воспоминания и размышления на тему спецификации. Тут желательно что-то другое увидеть.)
The God is real, unless declared integer.
Re[3]: Самый удобный человеко-читаемый язык данных
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.12.24 14:23
Оценка: :)
Здравствуйте, netch80, Вы писали:
N>А смысл?
Смысл, очевидно, в том, чтобы максимально затруднить копирование фрагмент конфигурации из одного места в другое в обычном текстовом редакторе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Самый удобный человеко-читаемый язык данных
От: bobby23  
Дата: 02.01.25 06:21
Оценка:
Здравствуйте, netch80, Вы писали:

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




N>Вопрос был про тот пример, где "0.1.0.node=valuexxx", а не про китайщину. Итак?


простая навигация по вложенным нодам, ручное редактирование будет сложнее(редактор сам должен нумеровать узлы)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.