Лучший формат файла для стандартных строковых и целочисленных данных?

Для моего проекта мне нужно хранить информацию о протоколах (отправленные данные (скорее всего, целые числа) и в порядке их отправки) и информацию, которая может быть отформатирована примерно так:
'ID' 'STRING' «ДОПОЛНИТЕЛЬНЫЕ ЦЕЛОЕ ДАННЫЕ»
Эта информация будет считана программой Java и сохранена в памяти для обработки, но я не знаю, в каком формате лучше всего хранить эти данные?

РЕДАКТИРОВАТЬ: Вот дополнительная информация:
1) Я буду использовать эти данные на игровом сервере.
2) Поскольку это игровой сервер, скорость не является основной проблемой, поскольку эти данные будут первичными. читаются и используются во время запуска, что не должно происходить очень часто.
3) Потребление памяти, однако, я хотел бы свести к минимуму.
4) Второй «пример» данных будет использоваться как «словарь» для поиска названий конкретных игровых предметов, их статистика и другие целочисленные данные (и, следовательно, могут стать очень большими, в отличие от первых данных, содержащих информацию о протоколе, где каждый файл будет отмечать только небольшие фрагменты протокола, например, протокол входа в систему).
5) И да, Я хочу, чтобы данные были доступны для редактирования человеком.

РЕДАКТИРОВАТЬ 2: Вот варианты, которые я сделал:
JSON - для описаний протоколов
CSV - для словарей


person Benjamin    schedule 20.06.2011    source источник
comment
Вы можете привести пример «дополнительных целочисленных данных»? Это одно целое число, список целых чисел, определенный формат целых чисел или что-то в этом роде?   -  person Kathy Van Stone    schedule 21.06.2011


Ответы (4)


Есть много факторов, которые могут иметь значение - вот вещи, которые могут помочь вам в этом разобраться:

1) Скорость / использование памяти: если данные должны загружаться очень быстро или они очень большие, вы, вероятно, захотите рассмотреть возможность использования собственного двоичного формата.

2) Переносимость / совместимость: против # 1 стоит соображение, что вы можете захотеть использовать данные в другом месте, с программами, которые не будут читать пользовательский двоичный формат. В этом случае вашими сильными нападающими, вероятно, будут CSV, dBase, XML и мой личный фаворит JSON.

3) Простота: форматы с разделителями, такие как CSV, легко читать, писать и редактировать вручную. Либо используйте двойные кавычки с правильным экранированием, либо выберите разделитель, который не будет отображаться в данных.

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

person Justin W    schedule 20.06.2011
comment
Еще два соображения: являются ли данные наследственными (похоже, не в этом случае) и должны ли они быть доступны для чтения / записи человеком? Если последнее, вы можете добавить в список YAML (jyaml.sourceforge.net). - person Kathy Van Stone; 21.06.2011

Как насчет XML, JSON или CSV?

person jmj    schedule 20.06.2011

Я написал аналогичную спецификацию протокола с использованием XML. (Доступно здесь.)

Я думаю, что это хорошее совпадение, поскольку оно отражает иерархический характер указания сообщений / сетевых пакетов / полей и т. Д. Порядок полей четко определен и так далее.

Я даже написал генератор кода, который генерировал классы отправки / получения сообщений с методами для каждого типа сообщения в XSLT.

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

person aioobe    schedule 20.06.2011

В дополнение к форматам, предлагаемым другими здесь (CSV, XML, JSON и т. Д.), Вы можете рассмотреть возможность сохранения информации в файле свойств Java. (См. java.util.Properties class.) Код уже готов, поэтому все, что вам нужно выяснить, - это имена свойств (или префиксы имен), которые вы хотите использовать.

Класс Properties также обеспечивает хранение / загрузку свойств в простом формате XML.

person David R Tribble    schedule 20.06.2011