Чи є правильний спосіб створити формат файлу?

Я будую фірмовий формат файлу для програми, яку я написав у 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 та сканувати знову ...