第(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)頁