[问]文本与二进制文件 [英] [Q] Text vs Binary Files

问题描述

假设磁盘空间不是问题

（文件将小于< 5k一般用于存储

首选项）


假设可能永远不会发生到另一个操作系统的运输。

是否有任何可靠的理由选择文本文件而不是二进制文件

文件？


我能想到的一些原因是：


- 运输到另一个操作系统是否有用或需要，

文本文件将更容易使用


- 容忍基本数据类型大小更改（枚举类型已经

已知会改变大小从一个版本的编译器到下一个版本）


- 如果文件损坏，更容易找到并修复

可能避免的问题只是

扔掉它的烦人的情况


我想开始使用XML来存储应用程序

首选项，但我需要说服其他人确信二进制文件文件是文本文件的最佳方法。


想法？评论？

解决方案

2004年5月27日星期四，Eric写道：

<假设磁盘空间不是问题[...]
假设可能永远不会发生到另一个操作系统的传输。
是否有任何可靠的理由选择文本文件而不是二进制文件？
我能想到的一些原因是：

- 运输到另一个操作系统是否有用或需要，
文本文件将更容易使用


一般来说，我猜这是错的。想想DOS / Win32文本文件，MacOS文本文件和* nix文本

文件（提示：换行和回车）之间的区别

。现在想想相同系统的二进制文件之间的差异（提示：没有）。

确实存在许多免费工具来处理行结束的麻烦，<但是，
，所以这不是一个缺点;只是一个你的

索赔的柜台。

- 容忍基本数据类型大小的变化（已知枚举类型的大小从一个版本变化下一个编译器）


编写便携式二进制I / O函数大约需要5分钟工作
大多数语言的b $ b，如果你'''''''''''''''''''''''''''''''''''''''''''''''''''''查看

创意的任何文件格式标准，以及Google网络字节顺序。如果你来自C $ / $
背景，那么当我告诉你''fwrite''应该

永远不会应用于除了unsigned char的缓冲区之外的任何东西！ :)

- 如果一个文件被破坏了，它会更容易找到并修复这个问题，可能会避免这个问题，因为它可以把它扔出来


是的，绝对。此外，更容易判断文本是否已经在传输中损坏了
- 它看起来不再像文本了！

Binary总是看起来像二进制;你需要明确的校验和和

防止腐败。 （再次，请参阅文件格式标准，

特别是我最喜欢的PNG图像标准。）

我想开始使用XML来存储应用程序
偏好，但我需要说服那些确信二进制文件是文本文件真正可行的优越方法的人。

一个纯文本的主要优点是它可以通过HTTP

和其他Web协议发送而无需装甲。您可以在POST请求的正文中放置纯文本

，例如，我怀疑任意

字节将被接受。 （不过我不知道。）

沿着同样的路线，你可以在电子邮件正文中来回发送你的数据文件

，而不是捣乱

附件。


缺点是尺寸;但你似乎并不担心这一点。

另一个可能的缺点是，如果你担心的话，文字很容易被阅读和反向工程（例如，专有的

配置文件或游戏的保存文件）---但随后您可以随时加密
加密您不想立即阅读的内容。 [无论你是什么

不想读*永远*，你根本就没有给你的用户，因为

他们会在给定足够时间的情况下破解任何东西。]


HTH，

-Arthur

Arthur J. O''Dwyer< aj*@nospam.andrew.cmu.edu>写道：

- 运输到另一个操作系统是否有用或需要，
文本文件将更容易使用

这就是为什么我最后提到使用一个可靠的XML解析器透明地处理

这样的问题。我可能不会考虑使用文本

文件，如果像XML和固定解析器这样的东西不可用且免费。

现在想想
相同系统的二进制文件之间的差异（提示：没有）。


好​​吧，你说''相同的系统''...所以，是的，一般来说，阅读&写一个永远不会被移动到另一个操作系统的
二进制文件不应该出现任何严重的问题。 （或者我错在这里？）


然而，关键是它可以被移动，在这种情况下处理

有大/小端的问题会变得很重要。

- 容忍基本数据类型的大小变化（已知枚举类型的大小从一个版本变化下一个编译器

大多数语言编写便携式二进制I / O函数大约需要五分钟时间

啊，但这是我不想花费的五分钟，特别是因为每次需要花费

的时间改变了一些事我相信

一次解决问题。


加上，花时间试图找出原因为什么

@ ＃

％@

Assume that disk space is not an issue
(the files will be small < 5k in general for the purpose of storing
preferences)

Assume that transportation to another OS may never occur.
Are there any solid reasons to prefer text files over binary files
files?

Some of the reasons I can think of are:

-- should transportation to another OS become useful or needed,
the text files would be far easier to work with

-- tolerant of basic data type size changes (enumerated types have been
known to change in size from one version of a compiler to the next)

-- if a file becomes corrupted, it would be easier to find and repair
the problem potentially avoiding the annoying case of just
throwing it out

I would like to begin using XML for the storage of application
preferences, but I need to convince others who are convinced that binary
files are the superior method that text files really are the way to go.

Thoughts? Comments?

解决方案

On Thu, 27 May 2004, Eric wrote:

Assume that disk space is not an issue [...]
Assume that transportation to another OS may never occur.
Are there any solid reasons to prefer text files over binary files?

Some of the reasons I can think of are:

-- should transportation to another OS become useful or needed,
the text files would be far easier to work with
I would guess this is wrong, in general. Think of the difference
between a DOS/Win32 text file, a MacOS text file, and a *nix text
file (hint: linefeeds and carriage returns). Now think of the
difference between the same systems'' binary files (hint: nothing).
There do exist many free tools to deal with line-ending troubles,
though, so this isn''t really a disadvantage; just a counter to your
claim.
-- tolerant of basic data type size changes (enumerated types have been
known to change in size from one version of a compiler to the next)
It''s about five minutes'' work to write portable binary I/O functions
in most languages, if you''re worried about the size of ''int'' on your
next computer or something. Check out any file-format standard for
ideas, and Google "network byte order." If you''re coming from a C
background, then you''ll understand when I tell you that ''fwrite'' should
never, ever be applied to anything but buffers of ''unsigned char''! :)
-- if a file becomes corrupted, it would be easier to find and repair
the problem potentially avoiding the annoying case of just
throwing it out
Yes, definitely. Also, it''s much easier to tell if text has been
corrupted in transmission --- it won''t look like text anymore!
Binary always looks like binary; you need explicit checksums and
guards against corruption there. (Again, see file-format standards,
especially my favorite, the PNG image standard.)
I would like to begin using XML for the storage of application
preferences, but I need to convince others who are convinced that binary
files are the superior method that text files really are the way to go.

One major advantage of plain text is that it can be sent over HTTP
and other Web protocols without "armoring." You can put plain text
in the body of a POST request, for example, where I doubt arbitrary
bytes would be accepted. (I dunno, though.)
Along the same lines, you can email your data files back and forth
in the body of an email message, rather than mucking about with
attachments.

The disadvantage is size; but you don''t seem worried about that.
Another possible disadvantage would be that text is easily read and
reverse-engineered, if you''re worried about that (e.g., proprietary
config files or savefiles for a game) --- but then you can always
encrypt whatever you don''t want read immediately. [Whatever you
don''t want read *ever*, you simply don''t give to your users, because
they''ll crack anything given enough time.]

HTH,
-Arthur

Arthur J. O''Dwyer <aj*@nospam.andrew.cmu.edu> wrote:

-- should transportation to another OS become useful or needed,
the text files would be far easier to work with
I would guess this is wrong, in general. Think of the difference
between a DOS/Win32 text file, a MacOS text file, and a *nix text
file (hint: linefeeds and carriage returns).

Which is why I mentioned at the end using a solid XML parser to deal
with such issues transparently. I likely wouldn''t consider using a text
file if something like XML and solid parsers weren''t available and free.
Now think of the
difference between the same systems'' binary files (hint: nothing).
Well, you say ''same systems''...so, yes, in general, reading & writing a
binary file that will never be moved to another OS shouldn''t present any
serious issues. (or am I wrong here?)

However, the point was that it could be moved, in which case dealing
with big/little endian issues would become important.

-- tolerant of basic data type size changes (enumerated types have
been known to change in size from one version of a compiler to
the next)

It''s about five minutes'' work to write portable binary I/O functions
in most languages

Ah, but it''s five minutes I don''t want to spend, especially since the
time would need to be spent every time something changed. I believe in
fixing a problem once.

Plus, the potental for spending time attempting to figure out why the
@#

%@

这篇关于[问]文本与二进制文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！