我目前正在为我的框架试验一种扩展机制。每个模块至少包含一个 PHP 文件(定义一个类)和一个 XSL 样式表,但可能还涉及多个其他文件,因此我立即想到使用 Phars。
一切都很好地结合在一起,但我注意到如果我不使用 createDefaultStub()
而是按照以下代码片段构建 Phar,那么结果是大小的四分之一——并且小于压缩版。
$phar = new Phar('Example.phar', 0, 'Example.phar');
$phar->buildFromDirectory(__DIR__ . '/src');
$phar->setStub('<?php __HALT_COMPILER();');
$phar->setSignatureAlgorithm(Phar::SHA256);
$phar->compress(Phar::GZ);
示例文件大小:
8799 14 Dec 09:37 ExampleCog.phar (using createDefaultStub())
2143 14 Dec 10:08 ExampleCog.phar (using __HALT_COMPILER())
3373 14 Dec 10:08 ExampleCog.phar.gz (consistent with either method)
Phar 将简单地用于将特定于模块的文件捆绑在一起,并将包含在一个框架中——在这种情况下独立运行没有任何意义。我想我的问题是,我错过了什么——如果有的话——使用最小 stub 代码?为什么压缩后的版本总是一样大?
最佳答案
I guess my question is, what am I missing out on — if anything — with using the minimal stub code?
在file format documentation ,默认 stub 描述为:
The default stub for phar-based Phar archives contains approximately 7k of code to extract the contents of the phar and execute them.
然后指向Phar::createDefaultStub ,它说:
This method provides a simple and easy method to create a stub that will run a startup file from the phar archive. In addition, different files can be specified for running the phar archive from the command line versus through a web server. The loader stub also calls Phar::interceptFileFuncs() to allow easy bundling of a PHP application that accesses the file system. If the phar extension is not present, the loader stub will extract the phar archive to a temporary directory and then operate on the files. A shutdown function erases the temporary files on exit.
添加了重点,因为这就是默认 stub 如此之大的原因。如果您可以假设您将始终在 PHP 5.3 或更高版本下运行,您可能不需要默认 stub 并且可以坚持使用最小的 __HALT_COMPILER
And why is the compressed version always the same size?
再次深入文件格式文档,有一个 comparison between archive formats ,这解释了 Phar 执行每个文件和整个存档压缩。您可能会看到类似的压缩大小,因为 gzip 无法进一步压缩数据。这是猜测。
关于php - 最小的 PHP Phar stub ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13876791/