从Windows和Linux读取文件会产生不同的结果（字符编码？）

  • Z时代
  • 2024-01-10
  • 分类：问答

目前，我正在尝试以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”符号。

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

回答：

�是三个字符的序列- 0xEF0xBF

0xBD，并且是Unicode代码点的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代码点。

以上是 从Windows和Linux读取文件会产生不同的结果（字符编码？） 的全部内容， 来源链接： utcz.com/qa/403610.html

回到顶部