Accès aléatoire au fichier gzip en plusieurs parties (en Java)

Question

Cela peut tomber dans le domaine des "pas vraiment réalisables" ou "cela ne vaut pas vraiment la peine" mais voilà.

J'essaie d'accéder de manière aléatoire aux enregistrements stockés dans un fichier gzip en plusieurs parties. Plus précisément, les fichiers qui m'intéressent sont des fichiers Heretrix compressés. (Si vous n'êtes pas familiarisé avec les fichiers gzip en plusieurs parties, la spécification gzip permet de concaténer plusieurs flux gzip dans un seul fichier gzip. Ils ne partagent aucune information de dictionnaire, il s'agit simplement d'ajouter des binaires.)

Je pense qu’il devrait être possible de le faire en recherchant un certain décalage dans le fichier, puis en recherchant les octets de l’entête magique gzip (c.-à-d. 0x1f8b, comme indiqué dans RFC ) et tentez de lire le flux gzip à partir des octets suivants. Le problème avec cette approche est que ces mêmes octets peuvent également apparaître dans les données réelles. Par conséquent, la recherche de ces octets peut conduire à une position non valide pour commencer à lire un flux gzip. Existe-t-il un meilleur moyen de gérer l’accès aléatoire, étant donné que les décalages d’enregistrement ne sont pas connus à priori?

Answer 1

Comme vous vous en êtes rendu compte, la conception de GZIP n’est pas conviviale.

Vous pouvez faire ce que vous décrivez, puis si vous rencontrez une erreur dans le décompresseur, concluez que la signature trouvée est en réalité une donnée compressée.
Si vous avez terminé la décompression, il est facile de vérifier la validité du flux qui vient d'être décompressé, via le CRC32.

Si les fichiers ne sont pas si volumineux, vous pouvez envisager de simplement décompresser toutes les entrées en série et de conserver les décalages des signatures afin de créer un répertoire. Pendant que vous décompressez, videz les octets dans un compartiment. À ce stade, vous aurez généré un répertoire et vous pourrez alors prendre en charge un accès aléatoire basé sur le nom du fichier, la date ou d'autres métadonnées.

Cela sera relativement rapide pour les fichiers de moins de 100 Ko. Juste comme une supposition, si vous aviez 10 fichiers d'environ 100k chacun, cela se ferait probablement en 2 sur un processeur moderne. C’est ce que je veux dire par "assez vite". Mais vous seul connaissez les exigences de votre application.

Avez-vous une classe GZipInputStream? Si oui, vous êtes à mi-chemin.

Answer 2

Le format de fichier BGZF , compatible avec GZIP, a été développé par les biologistes.

  

(...) L'avantage de   BGZF par rapport au gzip conventionnel est que   BGZF permet de chercher sans avoir   pour parcourir tout le fichier jusqu'à   le poste recherché.

Dans http: / /picard.svn.sourceforge.net/viewvc/picard/trunk/src/java/net/sf/samtools/util/ , consultez BlockCompressedOutputStream et BlockCompressedInputStream.java