如果有 imageCreateFromString，为什么还有 imageCreateFrom*？答案

【问题标题】：Why there is imageCreateFrom* if there is imageCreateFromString?如果有 imageCreateFromString，为什么还有 imageCreateFrom*？
【发布时间】：2012-06-13 09:00:18
【问题描述】：

我真的不明白为什么 GD 有不同的加载图像的功能，例如：

imagecreatefromjpeg() 
imagecreatefrompng() 
imagecreatefromgif()

如果图像是字符串则只有一个函数？

imagecreatefromstring()

确实，将图像读入字符串并将其传递给函数要好得多，例如：

$imgBlob = file_get_contents($imagePath);
imagecreatefromstring($imageBlob);
unset($imgBlob);  //> Free memory, but I am not interested in memory consumpation

？或者我错过了什么？这可能会给新用户带来潜在的困惑

也许他们只是忘了创建一个函数imageCreateFromFile()？

Ps.当然我对使用file_get_contents方法的内存消耗不感兴趣

【问题讨论】：

嗯。公平的问题。这就是你的 PHP 核心库......
因为 PHP 在生活中的目标是臃肿充满无用的东西，你可以通过额外的一行轻松完成。

标签： php image gd

【解决方案1】：

imagecreatefromstring() 对传递的图像类型运行一个开关，检查您的系统是否支持该图像类型，然后实际运行正确的imagecreatefrom* 函数。

您可以查看源代码以查看此内容：https://github.com/php/php-src/blob/master/ext/gd/gd.c?source=cc（函数的第 2280 行，它打开图像类型并调用正确函数的第 2301 行）。

所以，imagecreatefromstring() 函数实际上只是一个辅助包装器。如果您调用实际的图像类型函数，您将从不运行 _php_image_type（第 2217 行）中获得非常小的好处。

【讨论】：

【解决方案2】：

imagecreatefromjpeg() 
imagecreatefrompng() 
imagecreatefromgif()

从文件创建图像资源 - 您将文件路径作为参数传递，这是唯一可接受的输入。

imagecreatefromstring()

从字符串而不是文件创建图像资源 - 它几乎可以是任何东西，您甚至可以输入内容。例如，您可以使用

imagecreatefromstring(base64_decode('R0lGODlhAQABAJAAAP8AAAAAACH5BAUQAAAALAAAAAABAAEAAAICBAEAOw=='));

获取 1x1 像素的透明 gif（用于跟踪 gif）

当然，您可以通过 imagecreatefromstring 传递所有内容，但它的内存效率不高 - 处理大图像会占用大量内存，而且内存限制低会产生巨大的差异。

【讨论】：

但这并不能真正回答问题——为什么要做出这个架构决策？为什么没有格式不可知的imagecreatefromfile()？
这可能是他们在 PHP 中添加内容的顺序：imagecreatefrom* 函数自 PHP 4 发布以来就一直存在，imagecreatefromstring 最初不是 - 这是 4.0.4 的添加。我的猜测是他们添加了特定于文件格式的功能，后来又做了一个与格式无关的功能，但是改变已经发布的功能已经太晚了。并且由于 GD 有效，并且没有任何实际的工作围绕此进行，多年来一直没有改变。
@c2h5oh: 我相信即使在内存消耗方面也没有区别，因为在 imagecreatefromjpeg 等将图像转换为原始格式后的 GD 并且内存消耗是相同的，使用这两个功能你仍然会有你的图像内存满载
@yes123 对于生成的图像对象是正确的，但不考虑保存文件内容的变量。当然，您可以在完成后立即取消设置，但这并不会改变峰值内存使用率会更高的事实 - 这可能是成功和内存不足错误之间的区别。
@c2h5oh：正如我在问题中所说，内存消耗不是问题的重点