第(2/3)页

    但那段数据，它的时间却是2019-10-31    18:21:22、2019-10-31    18:21:23、2019-10-31    18:21:21、2019-10-31    18:21:22、2019-10-31    18:21:23……

    也就是在秒这个级别存在乱序，更具体点实际上是在毫秒级别存在乱序/跳跃，即时间格式为2019-10-31    18:21:22.456    2019-10-31    18:21:22.567这样，其中某些行组之间存在2、300毫秒的跳跃。

    叶新晨按时间连续性把数据分割，发现它的输出是每几条到十几条为一组，组内顺序正常，组间乱序/跳跃；但把这些组挑选、拼接，可以得到两组数据，组内时间顺序良好、间隔均匀。

    这说明，这些数据可能是两个命令的返回，不知怎么混到了一起。

    就是因为这种混淆使得命令输出格式错乱，这才使得程序把命令返回识别成了report。

    于是叶新晨看了一下对方的测试笔记，果然，他们测线路备份切换之类功能，所以需要同时控制两个网元；命令在程序中是顺序下发的，间隔可能只有若干毫秒。

    看到这里，叶新晨心里有了底，开始观察程序所在目录，果然在里面找到个dat文件；用十六进制编辑器打开，里面果然是网上传来的原始报文信息，二进制格式。

    报文格式是网元编号：信息。

    再检查相关代码，很显然，这是因为网元编号被底层通讯模块丢弃了，只把文本信息返回给了上层；这就使得上层无法区分信息来自哪个网元。

    平常这样做还没有问题；但遇到同时连接多个网元且需要同时检查多个网元返回、且返回信息还比较多时，数据就乱了。

    这个东西太基础。

    因为它和上层关系太过紧密，修改它影响太大；而且底层通讯模块的源码已经丢失……

    于是，叶新晨尝试用字符串分析的办法来恢复它，鉴于不同命令返回格式不同、数据各异，叶新晨也是用程序尝试识别每个字段的数据类型，然后再检测它是否为有序内容。

    叶新晨把这类列叫“索引列”，索引列有三种，一种是1、2、3这样的数字编号，另一种是网元编号这样一整个都是某个固定数字/字符的，还有就是年月日时分秒这样的时间信息；它们可能同时全部出现，但也可能只出现其中一种，甚至全都没有。

    当识别出索引列之后，叶新晨就把顺序不乱、时间不跳变的若干行视为一个整体；然后像分析单词的“编辑距离”一样，寻找一种使得数据整体上“编辑距离”调整最小的方案，把混淆的数据分隔开。
    第(2/3)页