Ищу формат данных/файлов

JSON или я просто неправильно 3 пункт понял?

Либо

2) Редактирование с помощью простых текстовых редакторов не будет вызывать адской боли

либо

3) Поддержка бинарных данных. Без тупости типа «превращаем ЛЮБОЙ байт в escape последовательность типа \x05, \blablabla, или даже 0YsNCg==»

Из 2 и 3 однозначно следует тот факт что бинарные данные тебе тем или иным способом нужно будет преобразовать в текст. А уж как их преобразовывать ты, выбрав любой подходящий текстовый формат, можешь решить сам - hex, base64, entity, escape, whatever. А насчёт текстового формата могу посоветовать только YAML. Собственно, вариантов-то и нет: JSON, например, крайне неудобен для ручного редактирования.

JSON или я просто неправильно 3 пункт понял?

JSON не поддерживает бинарные данные, их нужно вручную преобразовывать. Есть еще BSON, но он никаким образом не попадает под п. 2

кроме того, если забить на п.3, то всё равно, json не имеет стандарта форматирования, из-за чего сжатые данные в jsone редактировать невозможно без предварительного автоформатирования

и чё это? не отвечает ни одному пункту

Либо

либо

почему? мне нужно и то и другое

Из 2 и 3 однозначно следует тот факт что бинарные данные тебе тем или иным способом нужно будет преобразовать в текст. А уж как их преобразовывать ты, выбрав любой подходящий текстовый формат, можешь решить сам - hex, base64, entity, escape, whatever. А насчёт текстового формата могу посоветовать только YAML. Собственно, вариантов-то и нет: JSON, например, крайне неудобен для ручного редактирования.

можно примеры на
1) entity
2) escape
?
hex и base64 превращают данные в кашу и вообще занимают много места. И cpu time тоже.

Потому что бинарные данные в общем случае ни разу не текст и 1) сломают тебе текстовое представление файла 2) плохо поддаются вводу с клавиатуры. Таким образом тебе надо либо отказаться от первого, либо преобразовывать бинарные данные в текст, что в любом случае будет выглядеть примерно как base64 или hex, то есть отказаться от второго.

можно примеры на

1) Как в HTML: foo�bar�baz�

2) Как в C: foo\x00bar\x00baz\x00 или foo\0bar\0baz\0

hex и base64 превращают данные в кашу

base64 я правда зря вспомнил ибо он нередактируем, но если у тебя действительно бинарные-бинарные данные, то каша как раз получится при других способах, а лучше hex не придумать. Например:

FF 01 00 00  FF EF 01 00   42 A7 CF 01  FF 1F FF 1F

Тут даже не зная структуры данных я вижу скорее всего 3 32-битных и 2 16-битных little endian числа и могу их без проблем поправить если знаю что мне нужно. Да, я разбил их на тетрады пробелами как делают hex редакторы, но даже со смещением границы полей видно по нулям. Говорю как человек расковырявших много бинарных форматов руками.

и вообще занимают много места. И cpu time тоже.

Если тебя волнует место и cpu time, то тебе уже в бинарные форматы. Если данные такого объёма что место и время (де)сереализации ощутимо, редактировать их точно будет невозможно.

2) Как в C: foo\x00bar\x00baz\x00 или foo\0bar\0baz\0

о! вроде то, что надо! очень удобно когда читаемые символы представляют себя же, а НЕтекстовые заменяются последовательностями. Их всё еще можно редактировать!

Хочу спросить:

Ты не знаешь какие байты считаются неприемлимыми с точки зрения текстовых редакторов (или текстового представления данных)? Я точно знаю что 0. Однако, если я, например, вырву кусок данных из /dev/urandom, заменю нули на \0, то эти данные равно будут невалидными для вставки между кавычками printf...

base64 я правда зря вспомнил ибо он нередактируем, но если у тебя действительно бинарные-бинарные данные, то каша как раз получится при других способах, а лучше hex не придумать.

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

something\0somethingelse

key; length=10
��y聱���

read(fd, mem , 10);

Если тебя волнует место и cpu time, то тебе уже в бинарные форматы. Если данные такого объёма что место и время (де)сереализации ощутимо, редактировать их точно будет невозможно.

видимо, гиперуниверсального решения нет

ну что ж. Видимо, пойду имплементить новый велосипед на досуге =)

Ты не знаешь какие байты считаются неприемлимыми с точки зрения текстовых редакторов (или текстового представления данных)? Я точно знаю что 0. Однако, если я, например, вырву кусок данных из /dev/urandom, заменю нули на \0, то эти данные равно будут невалидными для вставки между кавычками printf...

Непечатные 0-31 и 127 (wikipedia://Ascii), и не-ASCII 128-255 которые зависят от кодировки и тоже местами непечатные.

какие байты считаются неприемлимыми с точки зрения текстовых редакторов

Зависит от самого редактора. Нормальные редакторы сами переводят непечатные символы в печатное представление, например 0 в \000, или ^@ и обрабатывают их как 1 символ (диграф).

Правильно сказали, что либо простой текст, либо бинарные данные. Бинарные данные вручную всё равно не введёшь, и при машинном сохранении никто не мешает их преобразовать в текст.

…

YAML или, в частности, JSON.