web-dev-qa-db-fra.com

Meilleur algorithme de compression pour XML?

Je sais à peine quoi que ce soit au sujet de la compression, alors soyez patient (c'est probablement une question stupide et douloureusement évidente).

Disons que j'ai un fichier XML avec quelques balises.

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

Maintenant, disons que j'ai plusieurs de ces très longues balises avec de nombreux attributs dans mes multiples fichiers XML. J'ai besoin de les compresser à la plus petite taille possible. Le meilleur moyen serait d'utiliser un algorithme spécifique à XML qui attribue des pseudonymes à des balises individuelles, telles que vlt1 ou vlt2. Cependant, cela ne serait pas aussi «ouvert» que je l’essayais, et je veux utiliser un algorithme commun comme DEFLATE ou LZ. Cela aide également si l'archive est un fichier .Zip.

Puisque je traite du texte brut (pas de fichiers binaires comme des images), j'aimerais un algorithme qui convient au texte brut. Lequel produit la plus petite taille de fichier (les algorithmes sans perte sont préférés)?

À propos, le scénario est le suivant: je crée un standard pour les documents, tels que les formats ODF ou MS Office XML, qui contiennent des fichiers XML, conditionnés dans un fichier .Zip.

EDIT: Le «cryptage» était une faute de frappe; il faut avoir ben 'compression'.

xmlalgorithmtextcompressionzip
29
Aethex

Il existe un standard W3 (pas encore publié) nommé EXI (Efficient XML Interchange) .

Devrait devenir LE format de données pour la compression future des données XML (prétendument le dernier format binaire nécessaire). Optimisé pour XML, il compresse XML de manière plus efficace que tout algorithme de compression conventionnel.

Avec EXI, vous pouvez utiliser des données XML compressées à la volée (sans avoir besoin de les décompresser ou de les recompresser).

EXI = (XML + XMLSchema) en tant que binaire.

Et voilà avec l'implémentation opensource (je ne sais pas si c'est déjà stable):
Exificient

30
ivan_ivanovich_ivanoff

Oui, * .Zip meilleur dans la pratique. Gory deets contenu dansle présent document USENIXmontre que les compresseurs "optimaux" ne valent pas la peine d'être compilés et que les compresseurs spécifiques à un domaine ne dépassent pas Zip [en moyenne].

Disclaimer: J'ai écrit ce document, cité plus de 60 fois selon Google.

5
sendbits

Une autre alternative pour "compresser" XML serait FI (Fast Infoset).

XML, stocké en tant que FI, contiendrait chaque balise et attribut uniquement une fois , Toutes les autres occurrences font référence à la première, , Économisant ainsi de l'espace.

Voir:

Très bon article sur Java.Sun.com , et bien sûr
l'entrée Wikipedia

La différence avec EXI du point de vue de la compression est que Fast Infoset (Texte clair structuré) est moins efficace.

Une autre différence importante Est la suivante: FI est un standard mature avec de nombreuses implémentations.
L'un d'eux: Fast Infoset Project @ dev.Java.net

4
ivan_ivanovich_ivanoff

Il semble que vous soyez plus intéressé par la compression que par le cryptage. Est-ce le cas? Si c'est le cas, ceci pourrait s'avérer une lecture intéressante même si ce n'est pas une solution exacte.

2
Mizipzor

À propos, le scénario est le suivant: je crée un standard pour des documents, tels que ODF ou MS Office XML, contenant des fichiers XML, conditionnés dans un fichier .Zip .

dans ce cas, je vous suggérerais d’utiliser la compression .Zip, sinon vos utilisateurs s’embrouilleraient.

1
Pete Kirkham

Aucune des valeurs par défaut n'est idéale pour XML, mais vous obtiendrez quand même de bonnes valeurs car il y a beaucoup de répétables. 

Étant donné que XML utilise beaucoup de répétitions (balises.>), Vous souhaitez qu'elles soient moins qu'un peu, donc une forme d'arithmétique plutôt que l'encodage de Huffman. Donc, rar/7Zip devrait être significativement meilleur en théorie. Ces algorithmes offrent une compression élevée, donc ils sont plus lents. Idéalement, vous voudriez une compression simple avec un encodeur arithmétique (qui pour XML serait rapide et donnerait une compression élevée).

0
user1496062

Vos alternatives sont:

  • Utilisez un serveur Web prenant en charge la compression gzip. Il va automatiquement compresser tout le code HTML sortant. Il y a cependant une petite pénalité de processeur.
  • Utilisez quelque chose comme JSON. Cela réduira considérablement la taille du message
  • Il y a aussi un XML binaire mais je ne l'ai pas essayé moi-même.
0
Zepplock

J'espère avoir bien compris ce que vous devez faire ... La première chose que je voudrais dire, c'est qu'il n'y a pas de compression bonne ou mauvaise. Algorithme pour le texte - Zip, bzip, gzip, rar , 7Zip sont suffisants pour compresser Tout ce qui a une entrée basse - c'est-à-dire un fichier volumineux avec un petit jeu de caractères. Si je devais les utiliser, je choisirais 7Zip au premier choix, rar comme Un deuxième et Zip comme troisième. Mais la différence est minime, vous devriez donc essayer Quelque chose de plus facile pour vous. Deuxièmement - Je ne pouvais pas comprendre ce que vous essayez de chiffrer. Supposons que Soit un fichier XML, vous devez d’abord le compresser à l’aide de votre algorithme de compression Préféré, puis le chiffrer à l’aide de votre algorithme de cryptage préféré . Dans la plupart des cas, tout algorithme moderne implémenté, par exemple, dans PGP Sera suffisamment sécurisé pour quoi que ce soit. J'espère que cela vous aidera.

0
Jack David