1

我正在序列化来自项目的两个不同分支的一些数据。使用 .以文本存档形式输出数据boost::serialization。由于要在两个序列化文件之间进行差异，因此我还在每个序列化部分之间的序列化文件中添加了一些调试消息，以便更好地查看可能出现输出差异的点。

这是我当前使用的代码的广泛概述：

std::ofstream ofs("./SomeFile.txt"); // for brevity's sake, no actual path used
{
  boost::archive::text_oarchive oa(ofs);
  std::string debug_str;

  debug_str = "\n\nPart 1\n";
  oa & debug_str;

  // ... some other serialized parts ...

  debug_str = "\n\nPart 145\n";
  oa << debug_str;
}

您会注意到，我首先认为使用的运算符 ( &vs <<) 对输出产生了影响，但事实并非如此，我得到以下文本文件：

22 serialization::archive 7 9 [CRLF]
[CRLF]
Part 1 [CRLF]
 11 [CRLF]
[CRLF]
Part 145 [CRLF]

该22 serialization::archive 7部分是一个标准的 Boost 序列化标头，用于识别我猜的存档类型。然后是我想删除的部分，即9——经过一番追逐后，我发现这9是"\n\nPart1\n"字符串的长度！

这是预期的行为还是有办法绕过这个输出？在其他实际记录的情况下，没有明显使用其他此类“控制代码”、标记长度等。

添加一些调试输出会很有用，但是由于所述调试字符串的长度可能不同（因为在其中一个分支上发生了大量重构），因此差异会产生一些误报。

任何想法将不胜感激，谢谢！

4

1 回答 1

2

我怀疑这是可能的。

您在这里面临的问题是需要将文本输出解析回以进行反序列化。结构化文本输出的主要方式有两种，因此可以轻松解析：

  • 以长度为前缀的字符串
  • 特殊字符（带有转义码）

例如，在 xml 存档中，标签用<and包围，>您不能自己使用这些字符，而是分别使用转义代码&lt;和&gt;。另一方面，如果您查看 Redis 格式，您会看到13$Hello, World!记录的长度是一串数字，然后是 $，然后是实际记录。

前一种方式（长度前缀字符串）效率更高，但人类可写性要低得多。

从 Boost::Serialization 文档中，我看到了两个不同的“人类可读”档案：

  • boost::text_[i/o]archive使用以长度为前缀的字符串（似乎）
  • boost::xml_[i/o]archive使用 xml 表示

您可能想要切换到boost::xml_oarchive.

于 2013-02-13T08:01:49.717 回答