PNG格式的图像不会在Mac Safari上显示 [英] PNG format images do not display on Mac Safari

问题描述

对于某些Mac用户，我们网站上的图像未在Safari中显示，他们报告看到没有图像或黑色图像.这是一个示例:

Images from our website do not display in Safari for some Mac users and they report seeing either no image or a black image. Here is an example:

http://s3-eu-west -2.amazonaws.com/bp18.boxcleverpress.com/Boxclever_logo_chartreuse.png

我发现的是:

• 图像在PC上显示
• 在某些Mac上显示图像(我可以使用较旧的版本)
• 图像在iPhone和iPad上显示
• 图片为PNG
• 我用pngtastic优化了图像
• 将图像复制到Mac并使用Adobe Photoshop打开时，会出现错误:文件格式模块无法解析文件
• 当我尝试在Windows上的Photoshop Elements中打开pngtastic优化文件时，也会出现该错误
• 当我尝试在Windows上的Photoshop中打开优化的文件时，出现错误IDAT:不正确的数据检查

我将用未优化的图像替换优化的图像，但是我不确定这个问题是否是pngtastic或Adobe图像库或其他问题.

I will replace the optimised images with unoptimised ones but I am not sure if this problem is with pngtastic or Adobe image libraries or something else.

推荐答案

问题出在pngtastic包含的Zopfli.java中.

The problem lies in Zopfli.java, included by pngtastic.

它使用以下Java代码计算Adler-32校验和:

It uses this Java code to calculate the Adler-32 checksum:

/**
 * Calculates the adler32 checksum of the data
 */
private static int adler32(byte[] data) {
    int s1 = 1;
    int s2 = 1 >> 16;
    int i = 0;
    while (i < data.length) {
        int tick = Math.min(data.length, i + 1024);
        while (i < tick) {
            s1 += data[i++];
            s2 += s1;
        }
        s1 %= 65521;
        s2 %= 65521;
    }

    return (s2 << 16) | s1;
}

但是，Java中的byte是始终已签名，因此对于某些内容，它可能会返回错误的校验和值数据输入.另外，s1和s2的裸int声明会引起进一步的复杂性.

However, bytes in Java are always signed, and so it may return a wrong checksum value for some data inputs. Also, the bare int declarations for s1 and s2 cause further complications.

(我的C版本)使用相同的代码，并且data显式声明为signed char，而s1和s2都声明为signed int，我得到了错误的校验和FFFF9180 –恰好是其中的一个您已损坏的PNG.

With (my C version of) the same code and data explicitly declared as signed char and both s1 and s2 as signed int, I get a wrong checksum FFFF9180 – exactly the one in your damaged PNG.

如果我更改声明以使用unsigned char和unsigned int，它将再次返回正确的校验和1BCD6EB2.

If I change the declaration to use unsigned char and unsigned int, it returns the correct checksum 1BCD6EB2 again.

Adler的原始C代码 zopfli中的-32校验和始终使用unsigned类型，因此受此影响的只是Java实现.

The original C code for the Adler-32 checksum in zopfli uses unsigned types throughout, so it's just the Java implementation that suffers from this.

这篇关于PNG格式的图像不会在Mac Safari上显示的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！