小编典典

从Windows和Linux读取文件会产生不同的结果(字符编码?)

linux

目前,我正在尝试以mime格式读取文件,该文件具有png的一些二进制字符串数据。

在Windows中,读取文件会为我提供正确的二进制字符串,这意味着我只需将字符串复制过来并将扩展名更改为png即可看到图片。


在Windows中读取文件后的示例如下:

    --fh-mms-multipart-next-part-1308191573195-0-53229
     Content-Type: image/png;name=app_icon.png
     Content-ID: "<app_icon>"
     content-location: app_icon.png

    ‰PNG

等…等…

在Linux中读取文件后的示例如下:

    --fh-mms-multipart-next-part-1308191573195-0-53229
     Content-Type: image/png;name=app_icon.png
     Content-ID: "<app_icon>"
     content-location: app_icon.png

     �PNG

等…等…


我无法将Linux版本转换为图片,因为这一切都变成了一些带有许多颠倒的“?”的时髦符号。和“ 1/2”符号。

谁能启发我发生的事情并可能提供解决方案?玩了一个星期甚至更多的代码。


阅读 455

收藏
2020-06-07

共1个答案

小编典典

�是三个字符的序列- 0xEF 0xBF
0xBD,并且是Unicode代码点的UTF-8表示形式0xFFFD。该代码点本身就是非法UTF-8序列的替换字符

显然,由于某种原因,您的源代码中涉及的例程集(在Linux上)正在错误地处理PNG标头。该PNG头与所述字节开始0x89(和后跟0x500x4E0x47),这是在视窗(其可能被处理该文件作为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代码点。

2020-06-07