Вот, ранее очень часто для передачи данных, если нет нужны экономить байты и желательно чтобы человек мог, по нужде, глянуть — использовали 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>Раздражает, что нет синтаксиса для передачи бинарных данных (массива байт).
Здравствуйте, vsb, Вы писали:
Pzz>>Не понимаю. В XML можно изобразить массив, просто повторяя элемент (с одинаковым именем) несколько раз. Некоторые протоколы так и делают.
vsb>Без дополнительной информации вроде XML Schema — нельзя. Т.к. нельзя отличить 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 это нормально. Есть "священное писание" — сами RFC, а есть "священное предание" — то, что все, кому надо, знают, но оно нигде не написано.
Например, то, как в TCP передаётся urgent pointer, в RFC 793 было написано неправильно, а в ядре BSD UNIX — правильно, и все это знали (кроме Microsoft, они сделали, как в RFC, хе-хе).
Pzz>>Раздражает, что нет синтаксиса для передачи бинарных данных (массива байт).
vsb>Обычно в base64 передают.
Непонятно, получив такое, это надо буквально применять или из base64 сначала декодировать. Схемы/метаданных-то нету...
Re[3]: Самый удобный человеко-читаемый язык данных
Здравствуйте, vsb, Вы писали:
vsb>Что значит "человеко-читаемый" я не очень понимаю. По-мне всё, что ASCII — одинаково человеко-читаемо. По этому критерию и XML и JSON и YAML человеко-читаемы.
Здравствуйте, Shmj, Вы писали:
S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
Ещё из популярных есть protobuf/flatbuffers. И байты умеют экономить, и в скорость, и умеют сериализовываться в тот же json, если хочется почитать глазами.
Re[3]: Самый удобный человеко-читаемый язык данных
Здравствуйте, Maniacal, Вы писали:
S>>Есть визуализаторы S>>https://stackoverflow.com/questions/6032137/how-to-visualize-data-from-google-protocol-buffer
M>Тогда и в ASN.1 можно хранить, для него есть визуализаторы.
В любом формате если есть визуализатор.
Никто же не будет делать БД на JSON. Хотя и поддерживают его для хранения документов и поиска.
Для просмотра JSON тоже нужен визуализатор в виде редактора текста
и солнце б утром не вставало, когда бы не было меня
Re[4]: Самый удобный человеко-читаемый язык данных
Здравствуйте, Pzz, Вы писали:
Pzz>ASN.1 — это для любителей садо-мазо.
Да, стандарт принятый, как официальный, например, у телекоммуникационных компаний. Столкнулся с ним, когда генератор роуминговых файлов для МТС поддерживал. Там одно неверное движение и придётся человекочитанием человеконечитаемый hex-код парсить на соответствие схеме, искать ошибку. А так там и деревья и массивы и всё что угодно есть.
Re[5]: Самый удобный человеко-читаемый язык данных
Здравствуйте, Maniacal, Вы писали:
Pzz>>ASN.1 — это для любителей садо-мазо.
M>Да, стандарт принятый, как официальный, например, у телекоммуникационных компаний. Столкнулся с ним, когда генератор роуминговых файлов для МТС поддерживал. Там одно неверное движение и придётся человекочитанием человеконечитаемый hex-код парсить на соответствие схеме, искать ошибку. А так там и деревья и массивы и всё что угодно есть.
Я знаю. Телефонисты немного этого ASN-а в интернет принесли. Это TLS (SSL), X.509, SNMP, LDAP...
X.509 — даже и название-то такое, телефонистское
Re[4]: Самый удобный человеко-читаемый язык данных
Здравствуйте, Pzz, Вы писали:
Pzz>sqlite3 — неплохой вариант, кстати. Это, вроде, портабельный формат, при этом довольно удобный и компактный, и открыть его можно везде. Pzz>ASN.1 — это для любителей садо-мазо.
Слишком много инструментов заточено на человеко-читаемый текст. Вот даже сетевой трафик смотрите — передается XML или JSON. Сразу видно и сразу можно что-то поиском найти. А sqlite3 как будете копировать и потом смотреть? Каждый раз копировать?
Далее — тот же GIT — ведь удобно в DIFF-ах смотреть что поменялось.
Здравствуйте, Shmj, Вы писали:
S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
Здравствуйте, Shmj, Вы писали:
S>Потом все более и более JSON.
Из всех мною испробованных, самый человеко-ориентированный это TOML. На втором месте — XML. JSON это вообще формат сериализации, руками его править можно, но это неудобно.
Еще один хороший вариант — это JavaScript/TypeScript в качестве языка конфигурации. Преимущество в том, что если нужно обьявить, например, переменную, а затем её использовать несколько раз в разных местах конфигурации, то это делается штатными средствами языка:
Здравствуйте, Shmj, Вы писали:
S>Слишком много инструментов заточено на человеко-читаемый текст. Вот даже сетевой трафик смотрите — передается XML или JSON. Сразу видно и сразу можно что-то поиском найти. А sqlite3 как будете копировать и потом смотреть? Каждый раз копировать?
В сетевом трафике чего только не передаётся. И я, заметим, нигде не утверждал, что sqlite3 — удобный формат для сетевого протокола. Скорее, он удобен для хранения/передачи достаточно большого объема структурированных данных.
S>Далее — тот же GIT — ведь удобно в DIFF-ах смотреть что поменялось.
Если, к примеру, в миллионе строк кода переименовать какую-нибудь популярную переменную или изменить стиль форматирования, такой diff смотреть будет люто неудобно.
Re[6]: Самый удобный человеко-читаемый язык данных
Здравствуйте, Pzz, Вы писали:
Pzz>В сетевом трафике чего только не передаётся. И я, заметим, нигде не утверждал, что sqlite3 — удобный формат для сетевого протокола. Скорее, он удобен для хранения/передачи достаточно большого объема структурированных данных.
А мы речь ведем о человек-читаемости, когда нужно мало.
Вот взять Excel тот же. Внутри там XML. Почему? Потому что разработчикам проще искать баги.
S>>Далее — тот же GIT — ведь удобно в DIFF-ах смотреть что поменялось. Pzz>Если, к примеру, в миллионе строк кода переименовать какую-нибудь популярную переменную или изменить стиль форматирования, такой diff смотреть будет люто неудобно.
Но речь же о файлах, которые создают люди и редактируют люди.
Здравствуйте, Shmj, Вы писали:
S>Получается JSON Forever? И человечество ничего не придумало и уже никогда и не сможет придумать, т.к. особо вариантов просто нет?
Да, пока что JSON обладает оптимальными характеристики по читаемости, скорости парсинга, объему передаваемых данных и удобству обработки в разных ЯП.
S>Вот, ранее очень часто для передачи данных, если нет нужны экономить байты и желательно чтобы человек мог, по нужде, глянуть — использовали XML. S>Потом все более и более JSON. S>После начали т.н. YAML, но как-то не особо, т.к. все-таки он не особо лучше, но сложнее. Удобство в читабельности сомнительное, а сам формат намного сложнее.
Тут надо понимать, что есть человек-читаемость, а есть человеко-писаемость. И xml, и JSON легко читать, но довольно неудобно писать. Схемы конечно упрощают, но не до конца. YAML легко писать пользователю.
Re[2]: Самый удобный человеко-читаемый язык данных
Здравствуйте, gandjustas, Вы писали:
G>Тут надо понимать, что есть человек-читаемость, а есть человеко-писаемость. И xml, и JSON легко читать, но довольно неудобно писать. Схемы конечно упрощают, но не до конца. YAML легко писать пользователю.
Я боюсь писать YAML. Особенно если нет подсветки. Вдруг где-то пробел не заметишь — и хана.
Если нет редактора, который подсвечивает JSON и ошибки в нем, то XML однозначно лучше. Бесят эти запятые, то лишнюю поставишь в конце, то в середине забудешь
Плюс, в XML, даже если ты не знаешь схемы, можно по тэгам примерно понять структуру документа/конфига/итп, под джейсону — хрен там был
Здравствуйте, Shmj, Вы писали:
S>Круглые скобки — это официальный знак препинания в гуманоидном языке, по этому лучше фигурные, тем более они легко доступны на клавиатуре.
Круглые скобки есть в русской и английской раскладках, фигурные только в английской
Здравствуйте, Shmj, Вы писали:
S>И почти все данные верхнего уровня (HTML, CSS, JSON, XML) — они передаются в человеко-читаемом виде, хотя могли бы юзать бинарный формат.
Потому что делали ленивые дураки.
S>Но чтобы легче было писать эти инструменты — разработчику лучше человеко-читаемый а не бинарный формат.
Лучше всего сделать взаимо однозначный конвертор текст <-> бинарник. Использовать текст для объемистых данных — просто идиотизм.
Ад пуст, все бесы здесь.
Re[4]: Самый удобный человеко-читаемый язык данных
Здравствуйте, Codealot, Вы писали:
C>Лучше всего сделать взаимо однозначный конвертор текст <-> бинарник. Использовать текст для объемистых данных — просто идиотизм.
Нет. Парсинг и форматирование (если не совсем уж тупо написаны) занимают копейки по сравнению с манипулированием структурами в памяти, а пользы от текстового представления — вагоны.
PS: Но это текстовое представление, должен заметить, должно быть скорее "полутекстовым". В нём не должно быть "грамматизьмы" ранних подходов IETF, где 100500 форматов представления одного и того же ради возможности отформатировать в ASCII art (ещё этим страдает YAML). Числа желательно представлять в шестнадцатиричном (или хотя бы свободно позволять это), включая float'ы.
Здравствуйте, 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, Вы писали:
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]: Самый удобный человеко-читаемый язык данных
Здравствуйте, netch80, Вы писали:
N>А попутно я должен заметить, что поскольку компьютеры хранят числа в двоичке, а JSON требует только десятичных форматов, требуется преобразование, которое дорого как по затратам времени (растёт квадратично от размера числа), так и по сложности кода (обычная процедура точной конверсии double это простыня кода, на понимание которого уйдёт два ящика водки). Ещё и возможная проблема урезания значения. Разрешить представлять в стиле 0x1.921fb54442d18p+1 было бы полезнее.
Но при этом должен заметить, что очень часто бывает так, что большинство передаваемых чисел — маленькие целые. И если JSON тратит на число в диапазоне от 10 до 99 два байта, то наивно спроектированный бинарный формат (т.е., использующий фиксированное количество байтов, 4 или 8, для каждого числа) будет тратить больше.
Re[5]: Самый удобный человеко-читаемый язык данных
Здравствуйте, 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]: Самый удобный человеко-читаемый язык данных
Здравствуйте, netch80, Вы писали:
N>Нет. Парсинг и форматирование (если не совсем уж тупо написаны) занимают копейки по сравнению с манипулированием структурами в памяти
Расшифруй.
N>пользы от текстового представления — вагоны.
Ноль. В норме, тебе не нужно читать данные в сыром виде.