c++ - png 中 CRLF CR block 的值

Question

在Desiginin File Formats我从这个网站获得的链接，我注意到 png 有 CRLF\x1A\LF block ，用于“测试”回车和换行符转换。

我正在为某个项目构建自定义二进制结构，我想知道为什么这很有用，在什么情况下我应该考虑添加它？

Answer 1

由于历史原因，不同的操作系统使用不同的序列来标记文本文件中的行结尾:

• Unix 及其伙伴 \n (换行)
• DOS 和 Windows \r\n (回车、换行)
• Mac OS(Mac OS X 之前)\r (回车)(Mac OS X(具有 BSD Unix 内核)可能同时支持:A Line Break Is a Line Break)。

这一切都是一团糟，例如:

• 有时 Windows 文本文件在 Xemacs 中看起来有点奇怪，所有行都用 ^M 修饰。在行尾。
• Windows 记事本(附带的纯文本编辑器)仅在一行中显示 Linux 文本文件。

一旦您定期在不同的操作系统之间切换，您就会开始习惯于必须不时修复行尾。有许多帮助工具，例如unix2dos和 dos2unix在cygwin中，Notepad++中的特殊命令，VisualStudio中的提示等。

在 C 语言中，行尾总是用 \n 标记即使在 DOS 和 Windows 中。 (我没有使用 Mac OS 的经验，但我想知道它是否与那里不一样。)为了使它无缝运行，MS 决定在“底层”读取和写入时“修复”文件内容。读取文件时，所有出现的 \r\n被 \n 默默取代写入文件时插入一个 \r每写之前\n .

这有一些恼人的缺点:

1. 如果读取特定大小的文件，“接收到”的内容可能会小一些字节。 (当我试图在加载文件之前预留空间并一次读取全部内容时，我曾经偶然发现了这个问题。我想知道为什么加载后某些字节似乎丢失了。)

2. 这可能会中断二进制文件的加载，其中 \n简单地表示具有任何含义的二进制值 10(超出换行符)。

为了解决这个问题，C API 为文件 I/O 提供了额外的模式。例如。 fopen()支持超过r , w , 和 a , 一个额外的字符来指示文件类型

• b表示二进制 I/O(不要触摸内容)
• t表示文本 I/O(修复行尾)。

没有它们，默认是文本 I/O。

在 Windows 以及可移植文件 I/O 上，应该始终给出。 (在 Linux 上，它根本没有任何影响，尤其是没有破坏性。)

我曾经写过SO: Copying a bmp in c的答案其中损坏的 BMP 文件的转储很好地说明了错误完成文件输出的影响。

在这个关于文本和二进制文件 I/O 的长篇故事之后，很明显，对于处理图像数据(通常是二进制编码)的开发人员来说，这始终是一个潜在问题。

因此，我可以想象 \r\n\032\n sequence 只是一个测试模式。如果这 4 个字节不完全具有这些值，则很有可能

• 文件以错误模式打开(在相关平台上)或
• 以前的工具损坏了文件的内容。

引用PeteBlackerThe3rd :

It will allow the decoder to throw useful error messages in that case as opposed to failing mysteriously.