J'essaie de trouver la position du premier en-tête de fichier Central Directory dans un fichier ZIP.
Je lis cela: http://fr.wikipedia.org/wiki/zip_(File_Format ) http://www.pkware.com/documents/casestudes/appnote.txt
Comme je le vois, je ne peux que rechercher les données zip, identifier par l'en-tête quel type de section je suis, puis le faire jusqu'à ce que je frappe l'en-tête de la répertoire central. Je voudrais évidemment lire les en-têtes de fichier avant cela et utiliser la "taille comprimée" pour sauter les données réelles et ne pas boucler à travers tous les octets du fichier ...
Si je le fais comme ça, alors je connais déjà tous les fichiers et dossiers à l'intérieur du fichier zip auquel cas je ne vois plus beaucoup d'utilisation pour le répertoire central.
à ma compréhension Le but du répertoire central est de répertorier les métadonnées de fichiers et de la position des données réelles dans le fichier zip afin de ne pas avoir besoin de numériser l'ensemble du fichier?
Après avoir lu sur la fin de l'enregistrement Central Directory, Wikipedia dit:
Cette commande permet de créer un fichier zip en une seule passe, mais c'est généralement décompressé en lisant d'abord le répertoire central à la fin.
Comment trouver facilement la fin de l'enregistrement de répertoire central? Nous devons nous rappeler que cela peut avoir un commentaire de taille arbitraire là-bas, donc je ne sais peut-être pas combien d'octets à partir de la fin du flux de données. Est-ce que je viens de le scanner?
P.s. J'écris un lecteur de fichier zip.
3 Réponses :
J'ai fini par boucle à travers les octets à partir de la fin. La boucle s'arrête s'il trouve une séquence d'octets correspondante, l'index est inférieur à zéro ou s'il est déjà passé par 64k octets.
Avez-vous trouvé une solution? Comment ressemble le répertoire central? J'ai un fichier codé de base64.
Commencez à la fin et numérisez-le vers le début, à la recherche de la fin de la signature du répertoire et de compter le nombre d'octets que vous avez numérisés. Lorsque vous trouvez un candidat, obtenez le décalage de l'octet 20 pour la longueur de commentaire (L). Vérifiez si L + 20 correspond à votre compte courant. Ensuite, vérifiez que le démarrage du répertoire central (pointé sur le décalage de l'octet 12) a une signature appropriée.
Si vous avez supposé que les bits étaient assez aléatoires lorsque la vérification de la signature était une supposition sauvage (par exemple, une suppression de devinette dans un segment de données), la probabilité d'obtenir toutes les bits de signature correct est assez faible. Vous pouvez affiner cela et déterminer les chances d'atterrissage dans un segment de données et la possibilité de frapper un en-tête légitime (en fonction du nombre de tels en-têtes), mais cela ressemblait déjà à une faible vraisemblance pour moi. Vous pouvez augmenter votre niveau de confiance avant de vérifier la signature du premier enregistrement de fichier répertorié, mais assurez-vous de gérer le boîtier de limite d'un fichier zip vide.
Merci pour cette réponse Derek, apprécie vraiment ça
Il convient également de mentionner qu'il est préférable de commencer à endoffile - 22 position, car la fin réelle de la signature du répertoire central ne peut pas se produire après cette position. Pour les archives avec des commentaires vides, cela trouvera la signature sur la première itération.
J'ai vérifié à Endoffile -22, si cela échoue, essayez ensuite EndOffile - 64K - 22 et boucle jusqu'à l'application de cette vérification heuristique à tout moment, je vois la signature. Code ici pour le curieux: Github.com/paulsapps/ msgi / blob / ...
Croisez simplement vos doigts et espérons qu'il n'y a pas d'entrée avec le CRC, l'horodatage ou le Datestamp comme 06054B50 ou toute autre séquence de quatre octets qui se produisent 06054B50.
Je ne pense vraiment pas que cela ait ajouté quelque chose terriblement constructif à cette question. Aurait été mieux ajouté comme un commentaire.
Vous ne pouvez pas commencer à numériser à l'arrière de la fin (le répertoire ZIP est situé à la fin du fichier)?
Oui, je peux, mais est-ce vraiment comme vous êtes censé faire cela? La numérisation à l'envers pour trouver la fin du répertoire central est une possibilité, mais compte tenu du fait qu'il possède un champ de commentaire de la taille variable de la taille 16 bits, vous pouvez avoir environ 65 000 commentaires que vous devez lire / analyser, et si Le commentaire contient le numéro magique Votre balayage échouera.
Les commentaires sont le plus toujours vides et ce que 64k est aujourd'hui?
J'ai fini par faire de cette façon. 64k et le fait que personne ne soit susceptible d'introduire de tels octets dans les commentaires ne signifie pas que c'est bien de le faire de cette façon.
FAIT FUN - L'Explorateur Windows n'ouvre pas les fichiers Zip s'ils contiennent la fin de la signature du répertoire dans le commentaire du fichier zip. WinRar et 7z n'ont pas ce problème.