png 中 CRLF CR 块的值答案

【问题标题】：Value of CRLF CR chunk in pngpng 中 CRLF CR 块的值
【发布时间】：2019-11-18 22:40:13
【问题描述】：

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

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

【问题讨论】：

您在链接文档中的什么位置可以找到有关“测试”块的任何信息？
设计文件格式 > 标识字节 > 第四段。
啊那个位。这不是关于测试块或类似的东西。这是一种确保文件处理功能可以被信任来完成它应该做的事情的方法。 \r\n 序列不应该被翻译，\n 也不应该被翻译，它们应该被完全按照那样阅读。
这看起来像是 png 解码器功能检查上游进程没有以 ascii 模式而不是二进制模式打开文件的一种方式。这是一个非常聪明的想法，我以前没有遇到过。它将允许解码器在这种情况下抛出有用的错误消息，而不是神秘地失败。
请记住，如果您使用fopen(name, "r"); 打开文件，Windows 上的二进制文件会发生什么情况，所有\r\ns 都会被\n 默默替换，这可能会破坏二进制内容。我相信这有点像测试模式。如果不是 \r\n\032\n，则可能是之前应用的工具损坏了内容。

标签： c++ data-structures binary newline

【解决方案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 文本文件。

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

在 C 语言中，即使在 DOS 和 Windows 中，行尾总是由 \n 标记。（我没有使用 Mac OS 的经验，但我想知道那里的情况是否不一样。）为了使这项工作顺利进行，MS 决定在“幕后”读写时“修复”文件内容。读取文件时，所有出现的\r\n 都会被\n 静默替换，而文件写入会在每个写入的\n 之前插入\r。

这有一些恼人的缺点：

如果读取某个大小的文件，“接收”的内容可能会小一些字节。（当我尝试在文件加载之前预留空间并立即读取全部内容时，我曾经偶然发现过这个问题。我想知道为什么加载后似乎缺少一些字节。）
这可能会中断二进制文件的加载，其中\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 序列只是一个测试模式。如果这 4 个字节不完全具有这些值，则很有可能

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

引用PeteBlackerThe3rd：

它将允许解码器在这种情况下抛出有用的错误消息，而不是神秘地失败。

【讨论】：