Question

我们有一个使用Andrew Valums ajax文件上传器的网络应用程序，如果我们一次开始5-10个图像上传，更常见的是不至少2或3将导致相同的gd错误“Corrupt JPEG data”

Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]:
         gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data:
         47 extraneous bytes before marker 0xd9 in ....

然而，我们的旧测试服务器或本地开发盒上没有发生这种情况，只在我们的新生产服务器上发生。

服务器上的文件大小与我本地计算机上的原始大小相同，因此它完成了上传，但我认为数据已被服务器损坏。

我可以通过删除它们并重新上传或通过FTP手动上传来“修复”损坏的文件

我们在Godaddy上有一个共享主机，刚刚开始将这个问题放在一个新的盒子上（我设置了，所以可能解释了很多:) CentOS 5.5 +，Apache 2.2.3，PHP 5.2.10

你可以在这里看到一些好的和坏的例子。 http://174.127.115.220/temp/pics.zip

当我BinDiffed他们时，我看到一致的模式，腐败总是64字节块，虽然损坏的块之间的距离不是恒定的，但是数字4356出现了很多。

我真的认为我们可以排除互联网，因为错误检查和使用TCP的重传非常可靠，浏览器版本之间似乎没有区别，或者我关闭防病毒和防火墙。

所以我选择了Apache / PHP的配置？

Answer 1

某些相机会在文件中附加一些数据，这些数据会被错误地解释（很可能是在标题中进行字符编码）。

我找到的解决方案是以二进制模式读取文件，如此

$fh = fopen('test.jpg', 'rb');
$str = '';
while($fh !== false && !feof($fh)){
    $str .= fread($fh, 1024);
}

$test = @imagecreatefromstring($str);

imagepng($test,'save.png');

Answer 2

嗯，我认为问题是jpeg-header数据，据我所知，PHP与它没有任何关系，我认为问题是你的文件上传器，也许有一些你缺少的配置

Answer 3

嗯 - 64字节损坏？...或者你的意思是64位？

我将建议问题实际上是PHP脚本的结果。这里经常出现的问题是脚本将CRLF插入到正在上传的数据流中，并且是由Window / * nix标准之间的差异引起的。

解决方案是强制php脚本以二进制模式上传（在php上传中使用+ b开关执行所有fopen（）命令）。以二进制模式上传文本文件是安全的，因为至少你仍然可以看到数据。

请阅读此处了解有关此问题的更多信息：

http://us2.php.net/manual/en/function.fopen.php

Answer 4

这可以通过以下方式解决：

ini_set ('gd.jpeg_ignore_warning', 1);

Answer 5

GoDaddy托管我遇到了这个问题。我使用他们的cPanel接口在GoDaddy上创建了数据库。它被创建为“拉丁语校对”（或类似的东西）。开发服务器上的数据库是UTF8。我已尝试过此页面上的所有解决方案，但无济于事。然后我将数据库转换为UTF8，它工作正常。

数据库编码不应该影响BLOB数据（或者我认为）。据我所知，BLOB代表 BINARY 大对象（某事......）！

另外，奇怪的是，当数据库仍处于“拉丁”状态时，数据已从开发人员复制到生产服务器，并且根本没有损坏。只有在插入新图像时才会出现问题。所以我猜想图像数据是作为文本数据提供给MySQL的，我认为有一种方法（当使用SQL时）插入二进制数据，而我没有遵循它。

编辑：刚看了一下MySQL导出脚本，这里是：
INSERT INTO ... VALUES（...， _binary 0xFFD8FF ......

无论如何，希望这会对某人有所帮助。 OP没有说明是什么解决了他的问题......

PHP文件上传损坏的JPEGS

5 个答案: