Вот, ранее очень часто для передачи данных, если нет нужны экономить байты и желательно чтобы человек мог, по нужде, глянуть — использовали XML.
Потом все более и более JSON.
После начали т.н. YAML, но как-то не особо, т.к. все-таки он не особо лучше, но сложнее. Удобство в читабельности сомнительное, а сам формат намного сложнее.
Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
S>человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
Для данных человечество придумало Excel.
Недостаточную человекочитаемость формата нужно компенсировать инструментами.
Сделать как в редакторе xaml, сверху список таблиц в файле + данные выбранной, снизу xml/жсон/хзчто или вообще бинарник, оба вида редактируемые, мгновенная трансляция изменений в обе стороны.
Когда такую элементарнейшую вещь приделают в visual studio? На всякое вредительство типа обезцвечивания иконок у них деньги почему-то есть.
XML и JSON это два разных подхода к моделированию данных.
XML это по сути дерево.
JSON это отображения (maps) плюс массивы.
XML хорош для моделирования древовидных данных. А вот массивы в него ложатся плохо.
JSON хорош для сериализации и десериализации, т.к. в него напрямую отображаются две самые популярные структуы данных.
YAML это альтернативный синтаксис для JSON.
Что значит "человеко-читаемый" я не очень понимаю. По-мне всё, что ASCII — одинаково человеко-читаемо. По этому критерию и XML и JSON и YAML человеко-читаемы.
Будет ли что-то ещё? Наверное зависит от развития языков программирования. JSON рождён от JavaScript-а. Когда-то были популярны S-выражения. Уйдёт JavaScript, придёт что-то другое, я так думаю.
В целом у JSON хватает мелких, но противных проблем.
Отсутствие вменяемой общепринятой спецификации. К примеру простые вопросы. Какие числа можно передавать? Что происходит при дублировании ключей? Это отдаётся на откуп конкретной реализации, что вызывает проблемы при взаимодействии, к примеру в JS целые числа ограничечны 2^52.
Нет очевидных фич, к примеру комментарии, возможность использовать массивы сверху. Опять же отдаётся на откуп реализациям и приводит к проблемам при взаимодействии.
Не специфицирована кодировка текста, т.е. нет однозначного отображения объекта в байты, только в строку.
Это всё не к тому, что JSON фатально плох, а к тому, что есть чем его улучшать.
Re[2]: Самый удобный человеко-читаемый язык данных
Здравствуйте, 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;
}
}
}
— что вам удобнее?
vsb>Что значит "человеко-читаемый" я не очень понимаю. По-мне всё, что ASCII — одинаково человеко-читаемо. По этому критерию и XML и JSON и YAML человеко-читаемы.
Ну хотя бы меньше лишних символов, которые замыливают глаз.
vsb>Будет ли что-то ещё? Наверное зависит от развития языков программирования. JSON рождён от JavaScript-а. Когда-то были популярны S-выражения. Уйдёт JavaScript, придёт что-то другое, я так думаю.
Сейчас он уже с JS не связан...
Re[3]: Самый удобный человеко-читаемый язык данных
Фигурные скобки можно заменить на круглые (чтобы получились привычные некоторым s-expressions), но смысла это не изменит.
Из собственного опыта -- когда в разметке можно добавлять новые теги/атрибуты для "узла", то это очень удобно.
Например, было {node {name "GrandChild1"} "GrandChildValue"}}
со временем стало {node {name "GrandChild1" {alias "Bob Jr"}} "GrandChildValue" {mandatory}}
Причем такая теговая/атрибутная система позволяет поддерживать обратную совместимость с уже имеющимися данными.
Re[4]: Самый удобный человеко-читаемый язык данных
А в чем смысловая нагрузка node?
S>Фигурные скобки можно заменить на круглые (чтобы получились привычные некоторым s-expressions), но смысла это не изменит.
Круглые скобки — это официальный знак препинания в гуманоидном языке, по этому лучше фигурные, тем более они легко доступны на клавиатуре.
Возможно вместо кавычек удобнее было бы знак ` — не путать с ' и ’.
Re[5]: Самый удобный человеко-читаемый язык данных
S>>Фигурные скобки можно заменить на круглые (чтобы получились привычные некоторым s-expressions), но смысла это не изменит.
S>Круглые скобки — это официальный знак препинания в гуманоидном языке, по этому лучше фигурные, тем более они легко доступны на клавиатуре.
Да фиолетово, на самом деле. Доколупываться к {} или () можете разве что вы. Да еще и с аргументами из категории "в гуманоидном языке".
Здравствуйте, Shmj, Вы писали:
S>После начали т.н. YAML, но как-то не особо, т.к. все-таки он не особо лучше, но сложнее. Удобство в читабельности сомнительное, а сам формат намного сложнее.
Сильно удобнее и проще. Ну то есть, для парсинга может и сложнее, но ты же про человеко-читаемость и удобство редактирования?
S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
JSON как раз говно то еще для чтения и правки.
Re[2]: Самый удобный человеко-читаемый язык данных
Здравствуйте, 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]: Самый удобный человеко-читаемый язык данных
Здравствуйте, ononim, Вы писали:
S>>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет? O>ini files forever
+100500, я тоже их люблю. Как минимум, для конфигов.
Здравствуйте, Shmj, Вы писали:
S>Вот, ранее очень часто для передачи данных, если нет нужны экономить байты и желательно чтобы человек мог, по нужде, глянуть — использовали XML.
Сейчас используют gRPC и ProtoBuf
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]: Самый удобный человеко-читаемый язык данных
S>Ну хотя бы меньше лишних символов, которые замыливают глаз.
У XML лишние символы это закрывающие теги. Остальное плюс-минус такое же. При этом в больших документах эти закрывающие теги на самом деле помогают ориентироваться в структуре. Поэтому я бы не утверждал однозначно, что они такие уж лишние.
Re[3]: Самый удобный человеко-читаемый язык данных
Здравствуйте, 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>Раздражает, что нет синтаксиса для передачи бинарных данных (массива байт).