Есть ли правильный способ создать формат файла?

Я создаю собственный формат файла для приложения, написанного на C # .NET, для хранения сохраненной информации и, возможно, ресурсов линейного проекта. Есть ли стандарт, как это сделать каким-либо образом? Я просто собирал Serializeсвои объекты в двоичный файл и создавал заголовок, который говорил бы мне, как анализировать файл. Это плохой подход?

Наиболее простой способ - это, вероятно, сериализовать вашу структуру в XML с использованием XMLSerializerкласса. Возможно, вам не нужно будет создавать отдельный заголовок и структуру тела - но сериализуйте все активы в XML. Это позволяет вам легко просматривать / редактировать файловую структуру вне вашей собственной программы и легко управляется.

Однако, если ваша файловая структура действительно сложна и содержит много разных ресурсов разных типов, так что сериализация всей структуры в XML слишком обременительна, вы можете посмотреть на сериализацию каждого актива в отдельности и сборку их в один пакет с использованием Packagingбиблиотеки в C # , По сути, именно так создаются .docx, .xslx, .pptx и другие форматы офисных файлов.

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

• Сделайте магическое число очень уникальным, чтобы детекторы формата файлов других людей не идентифицировали его как ваше. Если вы используете двоичный файл, выделите 8 или 16 случайно сгенерированных байтов в начале двоичного формата для магического числа. Если вы используете XML, выделите правильное пространство имен в своем домене, чтобы оно не могло конфликтовать с другими людьми. Если вы используете JSON, Бог поможет вам. Может быть, кто-то уже решил решение этой мерзости формата.

• План обратной совместимости. Сохраните номер версии формата так, чтобы более поздние версии вашего программного обеспечения могли иметь дело с различиями.

• Если файл может быть большим или в нем есть разделы, которые по какой-то причине могут захотеть пропустить, убедитесь, что есть хороший способ сделать это. XML, JSON и большинство других текстовых форматов особенно страшны для этого, потому что они заставляют читателя анализировать все данные между начальным и конечным элементом, даже если им это не важно. EBML несколько лучше, потому что он хранит длину элементов, позволяя вам пропустить весь путь до конца. Если вы создаете пользовательский двоичный формат, существует довольно распространенный дизайн, в котором вы сохраняете идентификатор фрагмента и длину в качестве первого элемента в заголовке, а затем читатель может пропустить весь фрагмент.

• Сохраните все строки в UTF-8.

• Если вы заботитесь о долгосрочной расширяемости, сохраните все целые числа в форме переменной длины.

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

Ну, иногда то, что вы описываете, может быть очень плохим подходом. Это предполагает, что когда вы говорите «сериализация», вы говорите об использовании способности языка / фреймворка просто брать объект и выводить его напрямую в некоторый двоичный поток. Проблема в том, что классовые структуры меняются с годами. Сможете ли вы перезагрузить файл, созданный в предыдущей версии вашего приложения, если все ваши классы изменятся на более новый?

Для долгосрочной стабильности формата файла, я считаю, что лучше немного закатать рукава и специально написать свои собственные методы «сериализации» / «потоковой передачи» в ваших классах. т.е. вручную обрабатывать запись значений в поток. Напишите заголовок, который вы указали, который описывает версию формата, а затем данные, которые вы хотите сохранить, в том порядке, в котором вы хотите. Что касается чтения, обработка различных версий формата файла становится намного проще.

Другой вариант, конечно, XML или JSON. Не обязательно лучший для бинарного тяжелого контента, но простой и понятный человеку ... большой плюс для долгосрочной жизнеспособности.

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

Я лично реализовал несколько форматов файлов для своей работы и перешел на использование формата файлов XML. Мои требования и аппаратное обеспечение, с которым я постоянно взаимодействую, меняются, и я не могу сказать, что мне нужно будет добавить в формат в будущем. Одним из основных преимуществ XML является то, что он полуструктурирован . По этой причине я обычно избегаю автоматической сериализации XML, предоставляемой .NET, потому что считаю, что она заставляет ожидать точный формат.

Моя цель состояла в том, чтобы создать формат XML, который позволял бы добавлять новые элементы и атрибуты в будущем и чтобы порядок тегов не имел значения, когда это возможно. Если вы уверены, что можете загрузить весь файл в память, XPATH , вероятно, является хорошим выбором.

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