十六进制datetime stamp

Question

我有一个在Windows上运行的应用程序，我没有源代码，GUI将日期显示为22/06/2018 08:44，此日期/时间是从文件中写入/读取的。这个文件包含日期的十六进制表示，下面是一些示例(后两个是我自己编辑的-因此出现了奇怪的年份)。

2C 05 0A D4 01 (22/06/2018 08:44)
2C 06 0A D4 01 (22/06/2018 08:51)
2C 08 11 D4 01 (01/07/2018 06:53)
B4 AE 08 D4 01 (06/12/5671 13:13)
B4 AE 11 12 10 (31/07/5270 10:53)

我正在尝试理解从十六进制到GUI日期/时间的转换，这样我就可以直接修改文件中的十六进制，并相应地查看GUI日期/时间

谢谢

Answer 1

编辑：十六进制数字是标准的Windows64位值，表示自1601年1月1日以来100纳秒间隔的数量，省略了三个最低有效字节，并以小端(最低有效字节优先)的形式写入。例如，您的第一个十六进制字符串2C 05 0A D4 01表示十六进制01D4 0A05 2C00 0000单位，自1601UTC 1月1日以来为100纳米(这恰好是22/06/2018年08:44:02.9898752 UTC，但您的图形用户界面省略了秒和秒的分数)。

你可以阅读更多的here: File Times on MSDN。

例如，对于从日期和时间到十六进制的转换，您可以使用http://www.silisoftware.com/tools/date.php?inputdate=2018-06-22T08%3A44%3A00%2B00%3A00&inputformat=text，将日期输入为2018-06-22T08:44:00+00:00，并将十六进制转换为01D40A05:2A37C800。向上舍入，以三个零字节结束: 01D40A05:2B000000。对剩余的字节重新排序: 2B 05 0A D4 01。

原始答案

这不是我以前见过的日期-时间编码方案。从你提供的数据中，我无法推断出整个方案。我相信我已经找到了这个计划的一部分。我不能再往前走了。

假设一些线性对应，我首先通过比较前两个样本注意到，第二组十六进制数字(如果您愿意，第二个字节)的1个单位的差异导致7分钟的差异。或者大约是:我们不知道时间是否有秒，甚至是几分之几的秒没有显示。

我在与第三个样本进行比较时使用了此信息。第三个字节从第一个样本到第三个样本增加了7(十六进制11 -十六进制0A = 7)。考虑到第二个字节的增加，第三个字节的一个单位似乎接近1832分钟，可疑地接近256 *7分钟= 1792分钟。因此，第二个字节和第三个字节似乎具有“小端”关系，其中第三个字节比第二个字节更重要。使用这些信息我们可以获得更多的准确性:时间差是12849分钟，第二个字节和第三个字节的时间差是十六进制1108 - 0A05 =十进制1795，所以每个单位是7.1582分钟(它与之前的7分钟一致，只是更精确)。使用这个值，我从十六进制值2C 06 0A D4 01插入第二个日期-时间，得到2018-06-22T08:51:09。它同意这一点。假设已确认！

到目前为止找到的信息足以满足09/06/2018 14:43 (2C 00 00 D4 01)到01/05/2019 09:17 (2C FF FF D4 01)之间的编码值，精度为7分钟。如果这对你来说足够了，我会很惊讶。

与第四个样本中的值相比，第一个字节上的一个单位似乎对应于14 128 940分钟(26.86年)。它没有像我们希望的那样很好地除以之前的7.1582分钟，所以我不确定我们如何使用这个观察结果。

比较最后两个样本，似乎第四个字节和第五个字节不能有相同的小字节顺序关系，因为第五个字节增加，而日期减少。但是，如果我们假设至少有一年早于普通纪元(“公元前”)，因为纪元没有印刷出来，这仍然是可能的。另一种可能是第五个字节被忽略。这导致对应于1088006分钟的第四字节的单位。同样，它与字节2和字节3的7.15分钟没有很好的关系，而且它与第一个字节的单位非常接近，所以可能是错误的。

要了解更多信息:首先尝试查看在文件中编辑(十六进制) 00 00 00时是否获得了有意义的日期-时间。如果您这样做了，那么接下来一次尝试一个F：

F0 00 00 00 00
0F 00 00 00 00
…
00 00 00 00 0F

如果这不能使模式足够清晰，请尝试一次一位，使用十六进制数字1、2、4和8而不是F。