Лучший алгоритм сжатия для XML?

Я почти ничего не знаю о сжатии, так что несите меня (это, наверное, глупый и болезненно очевидный вопрос).

Так что скажем, у меня есть XML файл с несколькими тегами.

<verylongtagnumberone>
  <verylongtagnumbertwo>
    text
  </verylongtagnumbertwo>
</verylongtagnumberone>

Теперь скажем, что у меня есть куча этих очень длинных тегов со многими атрибутами в моих многочисленных файлах XML. Мне нужно сжать их до минимального размера. Лучшим способом было бы использовать XML-специфический алгоритм, который присваивает псевдонимы отдельных тегов, такие как vlt1 или vlt2. Однако это не было бы "открытым" способом, как я пытаюсь использовать, и я хочу использовать общий алгоритм, такой как DEFLATE или LZ. Это также помогает, если архив был .zip файлом.

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

Кстати, сценарий таков: я создаю стандарт для документов, таких как ODF или MS Office XML, которые содержат файлы XML, упакованные в .zip.

EDIT: "шифрование" было опечаткой; это должно быть сжато ".

Ответы

Ответ 1

Существует W3 (еще не выпущенный) стандарт с именем EXI (Эффективный обмен XML).

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

С помощью EXI вы можете работать с сжатыми данными XML "на лету" (без необходимости распаковывать или повторно сжимать его).

EXI = (XML + XMLSchema) как двоичный.

И здесь вы идете с реализацией с открытым исходным кодом (не знаете, если он уже стабилен):
Эксклюзивный

Ответ 2

Другой альтернативой "сжимать" XML будет FI (Fast Infoset).

XML, хранящийся как FI, будет содержать каждый тег и атрибут только один раз, все другие вхождения ссылаются на первый, экономя пространство.

См:

Очень хорошая статья на java.sun.com, и, конечно же, запись в Википедии

Разница с EXI с точки зрения сжатия заключается в том, что Fast Infoset (являющийся структурированным открытым текстом) менее эффективен.

Другое важное различие is: FI - зрелый стандарт со многими реализациями.
Один из них: Fast Infoset Project @dev.java.net

Ответ 3

Да, *.zip лучше всего на практике. Gory deets, содержащиеся в в этой статье USENIX, показывающей, что "оптимальные" компрессоры не стоят затрат на вычисление и не зависят от доменных компрессоров, t beat zip [в среднем].

Отказ от ответственности: я написал эту статью, которая была указана в 60 раз в соответствии с Google.

Ответ 4

Кажется, что вас больше интересует сжатие, а не шифрование. Это так? Если это так, this может оказаться интересным для чтения, хотя это не точное решение.

Ответ 5

Кстати, сценарий таков: я создаю стандарт для документов, таких как ODF или MS Office XML, которые содержат файлы XML, упакованные в .zip.

то я предлагаю вам использовать сжатие .zip, или ваши пользователи будут запутаны.

Ответ 6

Надеюсь, я правильно понял, что вам нужно сделать... Первое, что я хотел бы сказать, это отсутствие хорошего или плохого сжатия алгоритмы для текста - zip, bzip, gzip, rar, 7zip - достаточно хороши для сжатия все, что имеет низкую емкость, то есть большой файл с небольшим набором символов. Если бы мне пришлось их использовать, я бы выбрал 7zip при моем первом выборе, rar as второй и zip как третий. Но разница очень мала, поэтому вы должны попробовать что бы ни было легче для вас. Во-вторых - я не мог понять, что вы пытаетесь зашифровать. Предположим, что это файл XML, тогда вы должны сначала сжать его, используя ваш любимый алгоритм сжатия, а затем зашифровать его с помощью вашего любимого шифрования алгоритм. В большинстве случаев любой современный алгоритм, реализованный, например, в PGP будет достаточно безопасным для чего угодно. Надеюсь, что это поможет.

Ответ 7

Ваши альтернативы:

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

Ответ 8

Ни один из стандартных по умолчанию не идеален для XML, но вы все равно получите хорошие значения, так как существует много повторяемости.

Поскольку XML использует много повторов (теги. > ), вы хотите, чтобы они были меньше, чем какая-то форма арифметики, а не кодировка Хаффмана. Поэтому rar/7zip должен быть значительно лучше в теории. Эти алгоритмы предлагают высокое сжатие, поэтому они медленнее. В идеале вам нужно простое сжатие с арифметическим кодировщиком (который для XML будет быстрым и даст высокое сжатие).