Je cherche comme une nouvelle spécification de format de fichier et la spécification indique que le fichier peut être basé sur XML ou un fichier zip contenant un fichier XML et d'autres fichiers.
L'extension de fichier est la même dans les deux cas. De quelle manière que je pourrais tester le fichier pour décider s'il a besoin de décompresser ou de lire simplement?
9 Réponses :
Vous pouvez regarder le numéro magique du fichier. Ceux pour les archives ZIP sont répertoriés sur le Format Zip Wikipedia Page : PK \ 003 \ 004 ou PK \ 005 \ 006 .
Oui, mais juste pour que l'op savoir ... Un «numéro magique valide» ne garantit pas que le fichier n'est pas corrompu ou d'un type erroné.
En effet. Toutefois, si leur problème se différencie simplement entre deux formats valides, le nombre magique est la voie à suivre.
Il n'y a pas de numéro magique pour un fichier zip. Souvent, les fichiers zip commencent par ces séquences, mais tous les fichiers zip ne le font.
Vérifiez les premiers octets du fichier pour le numéro magique . Les fichiers zip commencent par PK (50 4b). Comme les fichiers XML ne peuvent pas démarrer avec ces caractères et sont toujours valides, vous pouvez être sûr que le type de fichier.
Il n'y a pas de numéro magique pour les fichiers ZIP. Si Wikipedia dit ou suggère qu'il ya, c'est faux.
@Cheeso oui il y a. Veuillez lire le format pkware.com/documents/casestudes/appnote.txt et Notez la "signature d'en-tête de fichier local" et sa valeur définie.
Je comprends pourquoi vous penseriez que, de lire le texte, mais ce n'est pas correct. Le texte est flou, mais en pratique, il n'y a pas de numéro magique. EN.Wikipedia.org/wiki/zip_(File_Format) ainsi que d'expérience pratique Démontre que vous interprétez de manière incorrecte la spécification, en supposant un numéro magique. Examinez une archive auto-extraite générée par WinZip ou Infozip. C'est à la fois un fichier PE-COFF et un fichier zip. Il utilise le numéro MZ Magic, mais peut être lu sous la forme d'un zipfile par des outils zip conformes.
Vous pouvez essayer de le découvrir - un fichier XML est extrêmement improbable comme un fichier zip valide ou peut vérifier les numéros magiques, car d'autres ont dit.
Pour clarifier, il commence avec 50 4B 03 04.
voir http://www.pkware.com/documents/casestudes/appnote. Txt (de Simon P Stevens)
Oui, il y a un nombre magique: les fichiers zip commencent avec pk (50 4b 03 04)
Vous pouvez utiliser Fichier pour voir s'il s'agit d'un fichier texte (XML) ou un exécutable (zip). Faites défiler vers le bas pour voir un exemple.
Oups, je pensais qu'il y aurait un fichier d'appel système () aussi.
Cela dépend de ce que vous utilisez, mais la bibliothèque ZIP peut avoir une fonction qui testait un fichier ou non est un fichier zip. quelque chose comme is_zip, test_file_zip ou autre ...
ou créer votre propre fonction en utilisant le numéro magique indiqué ci-dessus.
Le format de fichier zip est défini par PKware. Vous pouvez trouver leur spécification de fichier ici .
Proche du haut que vous trouverez La spécification d'en-tête: P>
a. En-tête de fichier local: p>
local file header signature 4 bytes (0x04034b50) version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file name (variable size) extra field (variable size)
+1 super info. Mais idéalement, cela varierait d'un fournisseur au fournisseur, ce qui signifie l'algorithme de compression.
Le format de fichier zip ne varie pas du fournisseur au fournisseur. Il a été défini à l'origine par Pkware, mais de nombreux autres fournisseurs supportent désormais le même format de compression. Le format spécifique le PK dans l'en-tête, de sorte que même les autres fournisseurs incluent toujours cette partie de l'en-tête. Différents formats de fichiers tels que ARC, 7Z, LHz, GZIP, etc. auront des spécifications différentes et des en-têtes différents, mais un fichier zip aura toujours ceci dans l'en-tête.
"L'ordre des octets dans un fichier est l'autre sens" si votre système est petit-Endian.
@Steve: Oui, j'ai clarifié cela. Pkware Spécifiez la petite endiane dans le format.
Les 2 premiers octets d'une fermeture à glissière sont souvent, mais pas nécessairement, pk. L'en-tête indiqué ici est un en-tête pour une ZipENTry, qui peut apparaître n'importe où dans le fichier zip. Le zipfile n'a pas besoin de commencer par une entrée zippée et ne doit pas ne pas commencer par PK. Il n'y a pas de "numéro magique" pour un fichier zip. La première entrée ZIP n'a pas besoin d'être "proche" du haut du fichier. Il n'y a rien dans la spécification qui nécessite cela. Bien que cela ne soit pas nécessaire qu'un fichier zip commence par une entrée zippée, il est typique.
@Cheeso. C'est des informations intéressantes. Merci. Êtes-vous sûr cependant? Le document que j'ai référé spécifiquement stipule que le «format de fichier global .zip» commence par un «[Header local de fichier 1]», qui commence par les octets mentionnés. Avez-vous une référence pour ce que vous dites?
Je suis sûr. La référence est la spécification ZIP: PKWare's Appnote.txt. pkware.com/documents/casestudes/appnote.txt Il n'a jamais dit "tout Les fichiers zip commencent par 'xxxx' ". Sous Windows, un zip auto-extraite est à la fois un zip et un fichier PE-COFF. Le PE-Coff nécessite un nombre magique, le zip ne le fait pas. Un gif ou un JPG, qui ont tous deux des nombres magiques, peuvent également contenir du contenu zip.
@Cheeso Il indique clairement que tous les fichiers Zip devraient commencer par la "signature d'en-tête de fichier local" qui doit avoir une valeur de 0x04034b50. Un fichier zip doit avoir un en-tête de fichier , les 4 premiers octets dont la signature d'en-tête de fichier local qui devrait avoir une valeur de 0x04034b50. Je ne vois pas comment il peut être lu dans une autre manière.
@Yacoby - NON Où dit-il qu'un fichier zip doit commencer par cet en-tête. Il indique que chaque entrée du zip doit commencer par cet en-tête. Les fichiers zip valides n'ont pas besoin de commencer avec cet en-tête. Il n'y a pas de numéro de magie zip.
@Cheeso. Désolé, je pense que la spécification dit que le format de fichier zip commence par 0x04034B50. Oui, il dit que chaque entrée commence avec ce numéro, mais elle dit également que la première chose du fichier est la première entrée zip, donc par nécessité, le nombre est d'abord. Nous ne parlons pas de zips auto-extraites ou de zip Data intégrés dans les fichiers JPEG. Cette question concerne spécifiquement des fichiers zip - c'est-à-dire des fichiers ne contenant que le format zip et rien d'autre. Je comprends qu'il y a beaucoup d'utilisations possibles pour les données zip, et elle peut être intégrée à d'autres formats, mais les fichiers zip autonomes commencent par PK.
Vous et moi l'interpréter différemment Simon. Mon interprétation convient avec celle des outils Winzip, InfoZIP et PKZIP. Auto-extrait des fichiers zip sont les fichiers zip. Ils sont conformes au format zip. Renommez-les de .exe à .zip et ils travaillent comme un fichier zip, dans n'importe quel outil. PK est la première paire d'octets dans une grande majorité de fichiers zip, mais pas tous.
@Cheeso, oui, je pense que nous avons clairement différentes interprétations. Je dirais que les fichiers zip auto-extrayants ne sont pas conformes au format ZIP, ils sont une extension. Bien sûr, Zip Tools peut les traiter de la même manière, mais cela ne leur fait pas de fichiers zip. Photoshop peut ouvrir des fichiers JPEG et JPEG2000, et à un utilisateur final, ils sembleraient être traités de la même manière, mais cela ne signifie pas que les formats sont les mêmes. Quoi qu'il en soit, je ne veux pas entrer dans un débat énorme. Je vois votre point que vous étiez strict tous les fichiers contenant des données zip commencent avec PK. J'ai appris quelque chose de nouveau ici, alors merci.
Techniquement, cette réponse est incorrecte par des commentaires de Cheeso. Pour être conforme à la spécification, vous devez numériser le fichier pour la signature de fin de répertoire central (EOCD). La spécification n'empêche en rien des logiciels d'archivage d'insérer des données arbitraires avant ou après les en-têtes de fichiers locaux. Numérisation du fichier pour les en-têtes de fichier local Comme vous l'avez suggéré est une erreur d'erreur et doit être évitée sauf lors de la tentative de récupération de données à partir d'une archive corrompue. Ceci est en outre compliqué par la présence d'un commentaire de longueur variable à la fin de l'en-tête EOCD. Honnêtement, Zip est un format mal conçu et obsolète.
Pour plus d'informations sur cette conundrum gênant, voir Github.com/thejoshwolfe/yauzl/issues / 48 # Issuecomment-2665875 26
Pas une bonne solution cependant, mais de penser à voix haute ... que diriez-vous:
try
{
LoadXmlFile(theFile);//Exception if not an xml file
}
catch(Exception ex)
{
LoadZipFile(theFile)
}
J'ai voté cela, même si personnellement, je n'aime pas utiliser d'essayer de voir le programme. Je cherche un test plus précis. Merci tout de même pour ta contribution.
Je suis d'accord - la règle de base est que Test / Catch ne devrait jamais être utilisée pendant Normal Flux de programme (il ralentit des choses par plusieurs ordres de grandeur et, philosophiquement, c'est comme des ongles similaires sur un tableau).
Vous pouvez vérifier le fichier pour voir s'il contient un en-tête XML valide. Si ce n'est pas le cas, essayez de le décompresser.