Разработка формата обмена файлами для java

Question

Я хочу создать двоичный формат для передачи данных между экземплярами приложения в виде POF (Plain Old Files;)).

Предпосылка:

1. должна быть кросс-платформенный
2. информации настаиваться включает в себя один Pojo & произвольных байты [] S (файлы собственно, POJO хранит это имя в строке [])
3. только последовательный доступ требуется
4. должен быть способ, чтобы проверить согласованность
5. данных должен быть маленьким и быстрым
6. должен предотвратить средний пользователь с архиватором + блокнотом от изменения данных

В настоящее время я использую DeflaterOutputStream + OutputStreamWriter вместе с InflaterInputStream + InputStreamReader для сохранения/восстановления объектов сериализовать XStream, один объект на один файл. Читатели/писатели используют UTF8. Теперь необходимо расширить это, чтобы поддерживать описанные выше. Моя идея формата:

{serialized to XML object} 
{delimiter} 
{String file name}{delimiter}{byte[] file data} 
{delimiter} 
{another String file name}{delimiter}{another byte[] file data} 
... 
{delimiter} 
{delimiter} 
{MD5 hash for the entire file} 

1. Это выглядит вменяемым?
2. Что бы вы использовали для разделителя и как бы вы его определили?
3. Правильный способ расчета MD5 в этом случае?
4. Что вы посоветуете, чтобы почитать об этом?

TIA.

Answer 1

Он выглядит INsane.

• зачем изобретать новый формат файла?
• Зачем пытаться не допускать, чтобы только глупые пользователи меняли файл?
• зачем использовать двоичный формат (трудно сжать)?
• Зачем использовать формат, который не может быть проанализирован во время приема? (приемник должен получить весь файл, прежде чем он сможет воздействовать на файл.)
• XML уже является форматом сериализации, который сжимается. Таким образом, вы сериализуете сериализованный формат.

Answer 2

Может ли быть сериализация модели (если вы в MVC) другим способом? Я предпочел бы использовать вещи на языке (или в стандартных библиотеках), а затем, если возможно, перевернуть мои собственные. Единственная проблема, которую я вижу, заключается в том, что размер файла может быть больше, чем вы хотите.

Answer 3

Вы можете использовать библиотеку zip (rar/7z/tar.gz/...). Многие существуют, большинство из них хорошо протестированы, и это, скорее всего, сэкономит вам некоторое время.

Возможно, не так весело.

Answer 4

1) Сознательно ли это?

Это выглядит довольно разумно. Однако, если вы собираетесь изобретать свой собственный формат, а не просто использовать Java serialization, тогда у вас должна быть веская причина. У вас есть веские причины (они существуют в некоторых случаях)? Одна из стандартных причин использования XStream заключается в том, чтобы сделать результат удобочитаемым, который двоичный формат сразу же теряет. У вас есть веская причина для двоичного формата, а не для человека? См. this question, почему человечество читается хорошо (и плохо).

Не было бы проще просто положить все в подписанную банку. Для этого есть standard Java libraries и tools, и вы получаете сжатие и проверку.

2) Что бы вы использовали для разделителя и как его определить?

Вместо разделителя я бы явно сохранил длину каждого блока перед блоком. Это так же просто и не позволяет вам избежать разделителя, если он возникает сам по себе.

3) Правильный способ расчета MD5 в этом случае?

example code here который выглядит разумно.

4) Что вы предложите прочитать по этому вопросу?

О сериализации? Я читал о сериализации Java, JSON и сериализации XStream, поэтому я понял плюсы и минусы каждого, особенно преимущества читаемых человеком файлов. Я также посмотрел бы на классический формат файла, например, из Microsoft, чтобы понять возможные дизайнерские решения еще в те дни, когда каждый байт имел значение, и как они были расширены. Например: The WAV file format.

Answer 5

Bencode может быть путем.

Это excellent implementation от Daniel Spiewak.

К сожалению, спецификация bencode не поддерживает utf8, которая для меня является showstopper.

Возможно, это произойдет позже, но в настоящее время xml кажется лучшим выбором (с блоками, сериализованными как карта).

Answer 6

Возможно, вы могли бы объяснить, как это лучше, чем использование существующего формата файла, такого как JAR.

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

Answer 7

Давайте посмотрим, что это должно быть довольно просто.

Предпосылки:

0. должны быть кросс-платформенный

1. Информация, подлежащая сохранялось включает в себя один Pojo & произвольный байт [] S (файлы собственно, POJO хранит его имена в строке [])

2.только последовательный доступ требуется

3. должен быть способ, чтобы проверить целостность данных

4. должен быть маленьким и быстрым

5. должно препятствовать обычному пользователю с архиватором + блокнот от изменения данных

Хорошо, угадайте, что у вас в значительной степени уже есть, это встроенный в платформу уже: Object Serialization

Если вам нужно уменьшить объем данных, передаваемых в проволоке и предоставить пользовательские сериализации (например, вы можете отправить только 1,2,3 для данного объекта без использования имя атрибута или ничего подобного, и читайте их в той же последовательности), вы можете использовать это как-то "Hidden feature"

Если вам это действительно нужно в «текстовой равнине», вы также можете закодировать его, он занимает почти столько же байтов ,

Например этот компонент:

import java.io.*; 
public class SimpleBean implements Serializable { 
    private String website = "http://stackoverflow.com"; 
    public String toString() { 
     return website; 
    } 
} 

Может быть представлена ​​следующим образом:

rO0ABXNyAApTaW1wbGVCZWFuPB4W2ZRCqRICAAFMAAd3ZWJzaXRldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0ABhodHRwOi8vc3RhY2tvdmVyZmxvdy5jb20= 

See this answer

Кроме того, если вам нужен звучал протокол, который вы также можете проверить Protobuf, Google, внутренний обменный формат.

Answer 8

Я согласен с тем, что на самом деле не похоже, что вам нужен новый формат или двоичный. Если вы действительно хотите двоичный формат, то почему бы не рассмотреть один из этих первых:

• Binary XML (быстрый Infoset, Bnux)
• гессенские
• Google пакетов буферы

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

Так что, возможно, также рассмотреть следующие вопросы:

• Json работает хорошо; двоичная поддержка через base64 (с, скажем, http://jackson.codehaus.org/)
• XML не так уж плохо; эффективные потоковые анализаторы, некоторые с поддержкой base64 (http://woodstox.codehaus.org/, «типизированный API доступа» в разделе «org.codehaus.stax2.typed.TypedXMLStreamReader»).

Так что это звучит так, будто вы просто хотите построить что-то свое. Ничего плохого в этом, как хобби, но если это так, вам нужно считать это таковым. Вероятно, это не является обязательным требованием для системы, которую вы строите.