Редактировать : шестнадцатеричные числа являются стандартными 64-разрядными значениями Windows, представляющими число интервалов в 100 наносекунд с 1 января 1601 года, при этом три младших байта опущены и записаны как младший (младший значащий) байт первый). Например, ваша первая шестнадцатеричная строка, 2C 05 0A D4 01, означает шестнадцатеричное 01D4 0A05 2C00 0000 единиц на 100 нано с 1 января 1601 UTC (это точно 22/06/2018 08: 44: 02.9898752 UTC, но ваш GUI не указан секунды и доли секунды).
Вы можете узнать больше здесь: File Times на 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 минутам. Таким образом, может показаться, что 2-й и 3-й байты имеют отношение «little-endian», где 3-й байт более значим, чем 2-й. Используя эту информацию, мы можем получить немного больше точности: разница во времени составляет 12849 минут, а разница во 2-м и 3-м байтах равна шестнадцатеричной 1108 - 0A05 = десятичная 1795, поэтому каждая единица составляет 7,1582 минуты (она соответствует минут до того, только точнее). Используя это значение, я интерполировал вторую дату-время из шестнадцатеричного значения 2C 06 0A D4 01 и получил 2018-06-22T08: 51: 09. Согласен Гипотеза подтвердилась!
Полученной информации достаточно для кодирования значений в период с 06.09.2008 14:43 (2C 00 00 D4 01) и 05.01.2009 09:17 (2C FF FF D4 01) с точностью до 7 минут , Я был бы удивлен, если бы этого было достаточно для вас.
По сравнению со значением в 4-м примере кажется, что одна единица в первом байте соответствует 14 128 940 минутам (26,86 года). Он не делится хорошо на 7,1582 минуты, как мы могли бы надеяться, поэтому я не уверен, как мы можем использовать это наблюдение.
При сравнении двух последних выборок кажется, что 4-й и 5-й байты не могут иметь одинаковые младшие порядковые номера, поскольку 5-й байт увеличивается, а дата уменьшается. Это все еще возможно, хотя, если мы предположим, что по крайней мере один из лет до общей эры («до н.э.»), так как эра не напечатана. Другая возможность может заключаться в том, что пятый байт игнорируется. Это приводит к единице четвертого байта, соответствующей 1 088 006 минут. Опять же, он не имеет хорошего отношения к 7.15 минутам из байтов 2 и 3, и он подозрительно близок к единице первого байта, поэтому, вероятно, неверен.
Чтобы узнать больше: Сначала попытайтесь выяснить, получаете ли вы значимую дату-время от редактирования (hex) 00 00 00 00 00 в вашем файле. Если вы это сделаете, то попробуйте по одному F за раз:
F0 00 00 00 00
0F 00 00 00 00
…
00 00 00 00 0F
Если это не дает достаточно четкого шаблона, попробуйте один бит за раз, используя шестнадцатеричные цифры 1, 2, 4 и 8 вместо F.