PNG格式的图像不会在Mac Safari上显示

本文介绍了PNG格式的图像不会在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:

s3-eu-west -2.amazonaws/bp18.boxcleverpress/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.