�是三个字符的序列-
0xEF
0xBF
0xBD，并且是Unipre代码点的UTF-8表示形式
0xFFFD。该代码点本身就是非法UTF-8序列的替换字符。
显然，由于某种原因，您的源代码中涉及的例程集（在Linux上）正在错误地处理PNG标头。该PNG头与所述字节开始
0x89（和后跟
0x50，
0x4E，
0x47），这是在视窗（其可能被处理该文件作为CP1252的序列字节）正确处理。在CP1252中，
0x89字符显示为
‰。
但是，在Linux上，此字节已由UTF-8例程（或认为将文件作为UTF-8序列进行处理的库）解码。由于0x89本身不是ASCII-7范围内的有效代码点（请参阅：UTF-8编码方案），因此无法将其映射到0x00-0x7F范围内的有效UTF-8代码点。而且，它不能映射到表示为多字节UTF-8序列的有效代码点，因为所有多字节序列都以至少2位（设置为1（
11....））开头，因为这是文件的开头，也不能是连续字节。结果是，UTF-8解码器现在替换
0x89为UTF-8替换字符
0xEF
0xBF
0xBD（考虑到文件开头不是UTF-8，这太愚蠢了），它将显示在ISO-8859-1为
�。
如果需要解决此问题，则需要确保在Linux中执行以下操作：
- 使用适合该文件的编码（即不是UTF-8）读取PNG文件中的字节；如果您将文件读为一个字符序列*，则这显然是必要的；如果您仅读取字节，则不必这样做。您可能正确执行了此操作，因此也值得验证后续步骤。
- 在查看文件内容时，请使用合适的编辑器/视图，该编辑器/视图不对文件进行任何内部解码为UTF-8字节序列。使用合适的字体也将有所帮助，因为您可能希望防止出现无法显示字形（因为
0xFFFD
它实际上是菱形字符…）的空前情况，并可能导致进一步的更改（不太可能，但是您永远都不知道编辑器如何/ viewer已编写）。 - 最好以合适的编码-ISO-8859-1（而不是UTF-8）将文件写出（如果要这样做）。如果您要处理文件内容并将其作为字节而不是字符存储在内存中，则将它们写入输出流（无需任何String或字符引用）就足够了。
*显然，如果您将字节序列转换为字符或String对象，则Java运行时将字节序列解码为UTF-16代码点。
