png中CRLF CR块的值 [英] Value of CRLF CR chunk in png

问题描述

我从本网站获得的 Desiginin文件格式链接，我注意到png具有 CRLF\x1A\LF 块，可用于测试回车和换行。

In Desiginin File Formats link that i've gotten from this website, i've noticed that png has CRLF\x1A\LF chunk that is ment for "testing" Carriage return and line feeder conversion.

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

I am building a custom binary structures for some project and i am wondering why is this useful, and in which scenario i should think about adding it ?

推荐答案

从历史上讲，不同的操作系统使用不同的顺序来标记文本文件中的行尾：

Historically caused, different OSes uses distinct sequences to mark line endings in text files:

• Unix和同伴 \n （换行符）


• DOS和Windows \r\n （回车，换行）


• Mac OS（在Mac OS X之前） \r （回车）（Mac OS X（具有BSD Unix内核）可能同时支持以下两者：换行符就是换行符）。

• Unix and companions \n (linefeed)
• DOS and Windows \r\n (carriage-return, linefeed)
• Mac OS (before Mac OS X) \r (carriage-return) (Mac OS X (which got a BSD Unix kernel) might support both: A Line Break Is a Line Break).

这真是一团糟，例如：

• 有时Xemacs中的Windows文本文件看起来有些奇怪，所有行都用<$ c $装饰。 c> ^ M 在行尾。


• Windows记事本（随附的纯文本编辑器）仅在一行中显示Linux文本文件。

• Sometimes Windows text files look a bit strange in Xemacs with all lines decorated with a ^M at line end.
• Windows Notepad (the included plain text editor) shows Linux text files in one line only.

一旦您在不同的操作系统之间定期切换，就会开始使用该行-结尾必须不时固定。为此有许多辅助工具。 cygwin中的 unix2dos 和 dos2unix ，Notepad ++中的特殊命令，VisualStudio中的提示等。

Once, you switch periodically between different OSes, you start to get used that line-endings has to be fixed from time to time. There are numerous helper tools for this e.g. unix2dos and dos2unix in cygwin, special commands in Notepad++, prompts in VisualStudio, etc.

在C中，即使在DOS和Windows中，行尾也总是用 \n 标记。 （我没有使用Mac OS的经验，但我想知道那里是否不一样。）为了使这项工作看起来很顺利，MS决定在后台读写时修复文件内容。读取文件时，在写入文件时所有 \r\n 都被 \n 静默替换在每个写入的 \n 之前插入 \r 。

In C, a line-ending is always remarked by \n even in DOS and Windows. (I have no experience with Mac OS but I would wonder if it isn't the same there.) To make this working seemlessly, MS decided to "fix" file contents in reading and writing "under the hood". While reading a file, all occurrences of \r\n are replaced silently by \n while file writing inserts a \r before each written \n.

这有一些烦人的缺点：

1. 如果读取了某个大小的文件，则接收到的内容可能是小一些字节。 （当我试图在文件加载之前保留空间并一次读取全部内容时，我曾偶然发现这一点。我想知道为什么加载后似乎有些字节丢失了。）

1. If a file of certain size is read, the "received" contents might be some bytes smaller. (I once stumbled over this when I tried to reserve space prior file loading and reading the whole contents at once. I wondered why some bytes seemed to be missing after loading.)

这可能会中断二进制文件的加载，其中 \n 只是表示具有任何含义的二进制值10（在换行符之后）。

This may break loading of binary files where \n simply represents a binary value of 10 with any meaning (beyond line break).

要解决此问题，C API提供了文件I / O的其他模式。例如。 fopen（）支持的范围超过 r ， w 和 a ，表示文件类型的额外字符

To fix this, the C API provides additional modes for file I/O. E.g. fopen() supports beyond r, w, and a, an extra character to indicate file type

• b 表示二进制I / O（不要触摸内容）


• t 表示文本I / O（

• b denotes binary I/O (don't touch contents)
• t denotes text I/O (fix line-endings).

如果没有这些，则默认为文本I / O。

Without any of them, the default is text I/O.

在Windows以及便携式文件I / O上，应始终给出该值。 （在Linux上，它根本没有任何作用，特别是没有损害。）

On Windows as well as for portable file I/O, this should be always given. (On Linux, it simply doesn't have any effect especially no damaging.)

我曾经写过一个 SO：在c 中复制bmp，其中转储损坏的BMP文件可以很好地说明错误的完成文件输出的效果。

I once wrote an answer to SO: Copying a bmp in c where a dump of a broken BMP file illustrated the effect of wrong done file output nicely.

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

After this long story about text and binary file I/O, it might be obvious that it is always a potential issue for developers dealing with image data (which is usually encoded binary).

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

Hence, I can imagine that the \r\n\032\n sequence is simply a test pattern for this. If these 4 bytes don't have exactly these values chances are good that

• 文件以错误的模式打开（在此位置相关）或


• 以前的工具损坏了文件的内容。

引用 PeteBlackerThe3rd ：

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

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

这篇关于png中CRLF CR块的值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！