Это уже проблема недоделанных библиотек. В стандарте JSON ничего не заставляет ограничиваться ASCII. Более того — вообще непонятно, какие могут быть причины это делать: UTF-8 в разы компактней, чем такой escaping.

ini это вообще не формат, как и csv, например. Это скорее набор принципов, по которым каждый ваяет свой формат, несовместимый с другими. Лучше его избегать, чтобы не увеличивать степень бардака в мире и использовать более чётко определённые форматы.

Ini. Самое читаемое. В QSettings как-то ухитрялись иерархию прикрутить, можешь посмотреть на результат, если оно тебе (иерархия, в смысле) надо

Да в том же пыхе, встроенная — сразу гавнякает.

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

Я потому и посматриваю уже в сторону ини, либо расширить стандартный, либо кастрировать томл.

php говнякает json, поэтому я напишу парсер/генератор своей версии INI на всех используемых мною языках. Студента звали Альберт )

У Луа тот недостаток, что он гораздо слабее других форматов защищен от дурака.

Ничто ведь не мешает перед тем как делать loadstring() etc проверить прочитанный конфиг на что угодно средствами самой Lua

Проще написать свой огороженый формат, чем парсить луа-скрипт своими силами

Проще написать свой огороженый формат, чем парсить луа-скрипт своими силами

У Lua все-таки есть строки и с парсингом, особенно если это что-то вроде проверки чтобы в конфиге были только присваивания и никаких вызовов функций, особых проблем быть не должно

JSON

Если ты так любишь это говно, то jsmn можешь статически влинковать в свое приложение.

XML
читается лучше

Если насчет чтения еще можно похоливарить, то вот правки такого добра — это какой-то ад. Имей в виду, что libxml2 — весьма пухлая штуковина, однозначно не рекомендую в условиях ограниченности ресурсов.

Еще варианты?

YAML, но это откровенная параша. Не понимаю, зачем ты ищешь что-то новое, когда уже есть ini?

Еще варианты?

Можно их в реляционной БД хранить (sqlite, например).

Еще скриптики на lua/scheme можно в качестве конфигов юзать.

Ну прям хуман реадабля во все поля ))

Google protobuf / FB thrift. Test format is very readable, fast serialization/deserialziation. Cons: needs protobuf library. Google has one for Python, C++, Java.

конечно найдёт

только не очень большой по объёму.

Ну прям хуман реадабля во все поля ))

Ну а чо, если хранить в виде sql дампа.

С необходимостью вручную эскейпить строковые?

2) хуман реадабля, и чем реадаблее, тем лучше;

Просто их любопытства как будет называться конфиг, который человек может писать?

Не указанны следующие данные: кто пишет конфиг, насколько часто его нужно читать (сиправлять) человеку и т.д.

2) JSON — похуже первого в плане читаемости, зато структуру иначе чем написано не распарсишь, либы есть, но что-то они крупноваты по размеру, написать свою ниасилю по времени, придется зависеть от -lfoobar;

3) XML — читается лучше второго, но, зависимость, хотя, libxml уж точно будет стоять на 99% линуксомашин;

Откуда грибы?

Прочти уж все ответы, ато уже по второму кругу началось.

Ясно, это даже не грибы

вручную

Разумеется. Читаемость и удобство - это разные вещи. Впрочем, я голосую за TOML.

плюсую yaml