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

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

Плюс, в XML, даже если ты не знаешь схемы, можно по тэгам примерно понять структуру документа/конфига/итп, под джейсону — хрен там был
Отредактировано 20.12.2024 16:48 пффф . Предыдущая версия .
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: Самый удобный человеко-читаемый язык данных
От: andrey.desman  
Дата: 19.12.24 08:28
Оценка: +2
Здравствуйте, Shmj, Вы писали:

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


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

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


JSON как раз говно то еще для чтения и правки.
Re[5]: Самый удобный человеко-читаемый язык данных
От: пффф  
Дата: 20.12.24 16:43
Оценка: -1 :)
Здравствуйте, Shmj, Вы писали:

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


Круглые скобки есть в русской и английской раскладках, фигурные только в английской
Отредактировано 20.12.2024 16:44 пффф . Предыдущая версия .
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: Самый удобный человеко-читаемый язык данных
От: ononim  
Дата: 19.12.24 07:20
Оценка: +1
S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
ini files forever
Как много веселых ребят, и все делают велосипед...
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[4]: Самый удобный человеко-читаемый язык данных
От: Shmj Ниоткуда  
Дата: 19.12.24 20:14
Оценка: +1
Здравствуйте, Pzz, Вы писали:

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

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

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

Далее — тот же GIT — ведь удобно в DIFF-ах смотреть что поменялось.
Самый удобный человеко-читаемый язык данных
От: 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[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[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
Оценка:
Здравствуйте, 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[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: Самый удобный человеко-читаемый язык данных
От: 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
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


Я боюсь писать YAML. Особенно если нет подсветки. Вдруг где-то пробел не заметишь — и хана.
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
Оценка:
Здравствуйте, 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[3]: Самый удобный человеко-читаемый язык данных
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 22.12.24 18:26
Оценка:
Здравствуйте, 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>пользы от текстового представления — вагоны.


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