Mejor algoritmo de compresión para XML?

algorithm text (8)

Por cierto, el escenario es el siguiente: estoy creando un estándar para documentos, como ODF o MS Office XML, que contiene archivos XML, empaquetados en formato .zip .

entonces te sugiero que uses la compresión .zip, o tus usuarios se confundirán.

Apenas sé algo sobre la compresión, así que tengan paciencia conmigo (esta es probablemente una pregunta estúpida y dolorosamente obvia).

Digamos que tengo un archivo XML con algunas etiquetas.

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

Ahora digamos que tengo un montón de estas etiquetas muy largas con muchos atributos en mis múltiples archivos XML. Necesito comprimirlos al menor tamaño posible. La mejor forma sería usar un algoritmo específico de XML que asigna pseudónimos de etiquetas individuales como vlt1 o vlt2. Sin embargo, esto no sería tan "abierto" como trato de hacer, y quiero usar un algoritmo común como DEFLATE o LZ. También ayuda si el archivo fue un archivo .zip.

Ya que estoy tratando con texto sin formato (sin archivos binarios como imágenes), me gustaría un algoritmo que se adapte al texto sin formato. ¿Cuál produce el tamaño de archivo más pequeño (se prefieren los algoritmos sin pérdida)?

Por cierto, el escenario es el siguiente: estoy creando un estándar para documentos, como ODF o MS Office XML, que contiene archivos XML, empaquetados en formato .zip.

EDITAR: La cosa de "cifrado" era un error tipográfico; debería haber sido ben ''compresión''.

Espero haber entendido correctamente lo que debes hacer ... Lo primero que quiero decir es que no hay algoritmos de compresión buenos o malos para el texto: zip, bzip, gzip, rar, 7zip son lo suficientemente buenos para comprimir cualquier cosa que tenga un entrpy bajo - es decir, un archivo grande con un pequeño conjunto de caracteres. Si tuviera que usarlos, elegiría 7zip en mi primera elección, rar como segundo y zip como tercero. Pero la diferencia es muy pequeña, por lo que debes probar lo que sea más fácil para ti. Segundo: no pude entender lo que intentas encriptar. Supongamos que se trata de un archivo XML, primero debe comprimirlo utilizando su algoritmo de compresión favorito y luego cifrarlo utilizando su algoritmo de cifrado favorito. En la mayoría de los casos, cualquier algoritmo moderno implementado, por ejemplo, en PGP será lo suficientemente seguro para cualquier cosa. Espero que ayude.

Existe un estándar W3 (aún no lanzado) llamado EXI (Intercambio Eficiente de XML) .

Debería convertirse en el formato de datos para comprimir datos XML en el futuro (se dice que es el último formato binario necesario). Al estar optimizado para XML, comprime XML de maneras más eficientes que cualquier algoritmo de compresión convencional.

Con EXI, puede operar sobre datos XML comprimidos sobre la marcha (sin la necesidad de descomprimirlo o volver a comprimirlo).

EXI = (XML + XMLSchema) como binario.

Y aquí tienes la implementación de código abierto (no sé si ya es estable):
Exificient

Ninguno de los predeterminados es ideal para XML, pero aún obtendrá buenos valores ya que hay muchos repetibles.

Debido a que XML usa muchas repeticiones (etiquetas.), Quiere que estas sean menos que algunas, por lo que se debe usar alguna forma de codificación aritmética en lugar de Huffman. Entonces rar / 7zip debería ser significativamente mejor en teoría ... estos algoritmos ofrecen una alta compresión, por lo que son más lentos. Lo ideal sería una compresión simple con un codificador aritmético (que para XML sería rápido y daría alta compresión).

Otra alternativa para "comprimir" XML sería FI (Fast Infoset).

XML, almacenado como FI, contendría cada etiqueta y atributo solo una vez , todas las demás ocurrencias hacen referencia a la primera, ahorrando espacio.

Ver:

Muy buen artículo en java.sun.com , y por supuesto
la entrada de Wikipedia

La diferencia con EXI desde el punto de vista de compresión es que Fast Infoset (siendo texto plano estructurado) es menos eficiente.

Otra diferencia importante es que FI es un estándar maduro con muchas implementaciones.
Uno de ellos: Fast Infoset Project @ dev.java.net

Parece que está más interesado en la compresión que en el cifrado. Es ese el caso? Si es así, this podría ser una lectura interesante, aunque no sea una solución exacta.

Sí, * .zip mejor en la práctica. Los deets Gory contenidos en este documento de USENIX muestran que los compresores "óptimos" que no valen la pena el costo computacional y los compresores específicos del dominio no superan el zip [en promedio].

Descargo de responsabilidad: escribí ese documento, que ha sido citado más de 60 veces según Google.

Sus alternativas son:

Use un servidor web que admita la compresión gzip. Comprimirá automáticamente todo el html saliente. Sin embargo, hay una pequeña penalización por CPU.
Usa algo como JSON. Reduce drásticamente el tamaño del mensaje
También hay un XML binario pero no lo he probado yo mismo.