纯粹在大小方面，最好使用二进制。在 ASCII 表示中，双精度的完全扩展大约是 16+4 个字符 - 取决于您希望如何表示它们，大小会略有变化 - （至少）为 20 个字节，而在二进制格式中则需要 8 个字节。这是超过一半的存储增益。根据二进制格式的不同，I/O 也可能快几个数量级。例如，根据我的经验，当文件大小大于 200-300 MB 时，PETSc 二进制文件的读取速度大约快 15 倍。

问题是文档。每个人都可以查看 ASCII 文件，并且可能可以找出结构并编写程序来读取它。不幸的是，二进制文件并非如此。您必须提前知道格式，即使那样编写程序来读取它也可能并不容易。因此便携性是个大问题。一个鲜为人知的问题是数字的处理。现在是 2020 年，我们喜欢认为一切都是标准化的，但有时并非如此。当我尝试读取自定义二进制文件并认为“long double is long double”时，我遇到了这样的问题。它最终不是那么多，而是依赖于编译器。

正如评论中所要求的，您应该澄清您的目标和问题，以便人们可以提供更好的答案。

一个相关的轶事：多年前，我意识到坐在我旁边的教堂合唱团的成员在定义 SGML 标准方面发挥了作用。在那之后的某个时候，他以一种半严肃的、销售宣传的方式开始了对话，“在你的实验中，你是否将你的数据存储在基于文本的自我记录表示中？”

我想了一会儿。我想到编写工具来读取我们的二进制数据文件是多么麻烦，以及我花了多少小时像电影黑客一样皱着眉头调试我们的数据采集硬件和软件。我想拥有我可以读取的数据文件该有多好。但我对他说的是，“每分钟 200 兆字节，我们将运行一年。”

“哦，”他说，然后用更小声的声音说，“哦，我的。”

关于那个实验的数据分析，我记得瓶颈是磁盘 I/O：主要是 CPU 处于空闲状态，等待数据从驱动器传入。我们尝试存储 gzip 压缩的数据文件，但我们设计的硬件使得数据流中实际上没有太多可压缩的低熵信息。此外，在分析的某些部分，可以方便地以不同于硬件顺序的逻辑顺序查找数据；在具有一堆固定宽度记录的二进制文件中查找是微不足道的，但是在 gzip 管道的输出上查找是昂贵的或不可能的。

我的经验通常是计算中最昂贵的部分是弄清楚如何去做，因此拥有人类可读数据文件的清晰度几乎总是值得等待一些解析器将那些将文本字符转换为数字。但随着人类实际查看的数据比例缩小，这种优势就消失了。

一种对我很有帮助的方法是以最容易编写的方式构建我的数据文件/分析管道的第一个版本，并且只有在问题解决之前延迟变得烦人时才担心修复效率低下。

如果文件大小有问题，您可以使用zlib库函数gzopen、gzwrite、gzread和gzclose直接将文本写入和读取到压缩文件中。

除了可能比以二进制格式写入数字节省更多空间外，它的优点是可以使用gzip从命令行解压缩文件以查看其内容，这避免了答案中提到的文档和编译器依赖性问题阿卜杜拉·阿里·西瓦斯（Abdullah Ali Sivas）。