Toute les archives Phar contiennent de trois à quatre sections: Un conteneur Un manifest décrivant le contenu Le contenu du fichier Une signature (facultative) pour vérifier l'intégrité (uniquement avec le format de fichier phar)

Un conteneur Phar est un simple fichier PHP. Le conteneur minimal contient : Un conteneur doit contenir au moins le jeton __HALT_COMPILER(); en guise de conclusion. Typiquement, un conteneur comportera les fonctionnalités de chargement suivantes : Il n'y a aucune restriction sur le contenu d'un conteneur Phar, si ce n'est le besoin d'être conclu par __HALT_COMPILER();. Le tag fermant PHP ]]> peut être inclus ou omis, mais il ne peut y avoir plus d'un espace entre le ; et le tag fermant ]]> sans quoi l'extension phar ne sera pas capable de lire le manifeste de l'archive. Dans une archive phar basée sur tar ou zip, le conteneur est stocké dans le fichier .phar/stub.php. Le conteneur par défaut des archives Phar basées sur phar contient approximativement 7ko de code pour extraire le contenu du phar et l'exécuter. Regardez la fonction Phar::createDefaultStub pour davantage de détails. L'alias phar est stocké, dans le cas d'une archive phar basée sur tar ou zip, dans le fichier .phar/alias.txt en tant que texte plein.

Quels sont les avantages et les inconvénients de chacun des trois formats supportés par l'extension phar ? Ce tableau tente de répondre à cette question. Fonctionnalité Phar Tar Zip Format de fichier standard Non Oui Oui Peut être exécuté sans l'extension Phar [1] Oui Non Non Compression par fichier Oui Non Oui Compression pour toute l'archive Oui Oui Non Validation par signature de toute l'archive Oui Oui Oui Support d'applications spécifiquement Web Oui Oui Oui Métadonnées par fichier Oui Oui Oui Métadonnées pour toute l'archive Oui Oui Oui Création/modification d'archive [2] Oui Oui Oui Support complet de toutes les fonctions de flux Oui Oui Oui Peut être créée/modifiée même si phar.readonly=1 [3] Non Oui Oui [1] PHP ne peut accéder directement au contenu d'une archive Phar sans que l'extension Phar soit installée si elle utilise un conteneur qui extrait le contenu de l'archive phar. Le conteneur créé par Phar::createDefaultStub extrait l'archive phar et exécute son contenu à partir d'un répertoire temporaire si aucune extension phar n'est trouvée. [2] Tous les accès en écriture nécessitent que phar.readonly soit désactivé dans le php.ini ou directement via la ligne de commande. [3] Seules les archives tar ou zip sans .phar dans leur nom et sans conteneur exécutable .phar/stub.php peuvent être créées si phar.readonly=1.

Les archives basées sur le format de fichier tar sont conformes au format moderne USTAR. Le design des en-têtes du fichier tar le rend plus efficace que le format de fichier zip et aussi efficace que le format de fichier phar quand il s'agit d'accéder aux données. Les noms de fichiers sont limités à 255 octets, y compris le chemin complet au sein de l'archive phar basée sur tar. Ces archives peuvent être intégralement compressées au format gzip ou bzip2 tout en restant exécutables par l'extension Phar. Il y a un support limité pour lire les tarballs dans le format pax interchange, mais tout les en-têtes pax reconnues (actuellement, typeflag x et g) sont silencieusement ignorés. Il y a aussi un support limité pour les GNU Tar Archives; actuellement, les en-têtes ././@LongLink sont résolus. Pour compresser une archive entière, utilisez Phar::compress. Pour décompresser une archive entière, utilisez Phar::decompress.

Les archives basées sur le format de fichier zip supportent de nombreuses fonctionnalités incluses dans le format zip. Les métadonnées par fichier ou sur toute l'archive sont stockées dans les commentaires du fichier zip et de l'archive zip en tant que chaîne de caractères sérialisée. Les commentaires zip déjà existants seront lus sans problème en tant que chaîne. Les lectures/écritures compressées sont supportées par la compression zlib DEFLATE, et uniquement les lectures compressées par la compression bzip2. Il n'y a pas de limite sur le nombre de fichiers au sein d'une archive phar basée sur zip. Les répertoires vides sont stockés dans l'archive zip comme des fichiers avec un slash final, comme mon/repertoire/

Le format de fichier phar est composé de conteneur/manifeste/contenu/signature, et stocke les informations cruciales de ce qui est contenu dans l'archive phar dans son manifeste. Le manifeste Phar est un format hautement optimisé qui permet la spécification fichier par fichier de la compression, des permissions et même des métadonnées utilisateur tels que l'utilisateur ou le groupe propriétaire. Toutes les valeurs de plus d'un octet sont stockées sous forme petit-boutiste, A l'exception de la version de l'API qui est stockée pour des raisons historiques en 3 morceaux grand-boutistes. Tous les drapeaux non utilisés sont réservés pour un usage futur et ne doivent pas être utilisés pour stocker des informations personnalisées. Utilisez les métadonnées par fichier pour stocker des métadonnées personnalisées sur des fichiers particuliers. Le format de fichier basique du manifeste d'une archive Phar est le suivant : Taille en octets Description 4 octets Longueur du manifeste en octets (limitée à 1 Mo) 4 octets Nombre de fichiers dans le Phar 2 octets Version de l'API du manifest Phar (à ce jour 1.0.0) 4 octets Drapeaux "bitmappés" globaux du Phar 4 octets Longueur de l'alias Phar ?? L'alias Phar (longueur basée sur la valeur précédente) 4 octets Longueur des métadonnées Phar (0 si aucune) ?? métadonnées Phar sérialisées, stockées dans un format serialize au moins 24 * nombre d'octets des entrées Entrées pour chaque fichier

Voici les drapeaux "bitmappés" actuellement reconnus par l'extension Phar pour le bitmap plein global de Phar : Valeur Description 0x00010000 Si présent, le Phar contient une signature de vérification 0x00001000 Si présent, le Phar contient au moins 1 fichier qui est compressé grâce à zlib DEFLATE 0x00002000 Si présent, le Phar contient au moins 1 fichier qui est compressé grâce à bzip2

Chaque fichier du manifeste contient les informations suivantes : Taille en octets Description 4 octets Longueur du nom de fichier en octets ?? Nom de fichier (longueur basée sur la valeur précédente) 4 octets Taille du fichier décompressé en octets 4 octets Timestamp Unix du fichier 4 octets Taille du fichier compressé en octets 4 octets Somme de contrôle CRC32 du contenu décompressé du fichier 4 octets Drapeaux bitmappés spécifiques au fichier 4 octets Longueur des métadonnées du fichier sérialisées (0 si aucune) ?? métadonnées du fichier sérialisées, stockées dans un format serialize A noter qu'à partir de l'API 1.1.1, les répertoires vides sont stockés comme des noms de fichier avec un slash final comme mon/repertoire/ Les valeurs reconnues de drapeaux bitmappés spécifiques au fichier sont : Valeur Description 0x000001FF Ces bits sont réservés pour définir des permissions spécifiques au fichier. Celles-ci sont utilisées pour fstat et peuvent être utilisées pour recréer les permissions souhaitées en cas d'extraction. 0x00001000 Si présent, le fichier est compressé grâce à zlib DEFLATE 0x00002000 Si présent, le fichier est compressé grâce à bzip2

Les Phar qui contiennent une signature ont toujours la signature ajoutée à la fin du Phar, après le chargeur, le manifeste et le contenu. Les types de signature supportés à ce jour sont MD5, SHA1, SHA256, SHA512, et OPENSSL. Longueur en octets Description variant La signature actuelle, 20 octets pour une SHA1, 16 octets pour une MD5, 32 octets pour une SHA256, et 64 octets pour une SHA512. La longueur d'une signature OPENSSL dépend de la taille de la clé privée. 4 octets Les drapeaux de signature. 0x0001 est utilisé pour définir une signature MD5, 0x0002 pour une SHA1, 0x0003 pour une SHA256 et 0x0004 pour une SHA512. Le support des signatures SHA256 et SHA512 est disponible à partir de la version 1.1.0 de l'API. 0x0010 est utilisé pour définir une signature OPENSSL, qui est disponible à partir de la version 1.1.1 de l'API, si OpenSSL est disponible. 4 octets GBMB magique utilisé pour définir la présence d'une signature.