Самый удобный человеко-читаемый язык данных
От: 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 можно хранить, для него есть визуализаторы.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.