GUID никогда не может быть длинным, потому что,
как я уже сказал, размер GUID составляет 16 байт,
и размер long составляет 8 байт. Вы
Cannoy счастливо сбросить 8 байтов от
GUID, даже если они нули! : -)
Guid - это просто 128-битная структура данных, а long - это 64-битная структура данных ...
Это означает, что до тех пор, пока старшие 64 бита являются нулями, мы можем безопасно отбрасывать их и позже восстанавливать их, так как в этом случае нули не означают полные данные. Так что да, это потеря данных, но при определенных обстоятельствах это потеря данных, которые можно восстановить. (Думаю с точки зрения сжатия)
Это ничем не отличается от того, когда вы говорите:
long x = 5000;
//Converting 64 bit data structure into a 32 bit, discarding the upper 32 bits.
int y = (int)x;
//Converting 32 bit data structure into a 64 bit.
long z = (long)y;
Эти явные преобразования не встроены в систему, поскольку это не так, нужно делать это по-другому.
public static Guid ToGuid(long value)
{
byte[] guidData = new byte[16];
Array.Copy(BitConverter.GetBytes(value), guidData, 8);
return new Guid(guidData);
}
public static long ToLong(Guid guid)
{
if (BitConverter.ToInt64(guid.ToByteArray(), 8) != 0)
throw new OverflowException("Value was either too large or too small for an Int64.");
return BitConverter.ToInt64(guid.ToByteArray(), 0);
}
Очевидно, что это никогда не должно использоваться с GUID в общем, но безопасно использовать до тех пор, пока GUID имеет только 64 бита «фактических данных», лучший способ гарантировать, что никогда не использовать его на направляющих, если они не создан с использованием long.
В качестве меры предосторожности я добавил исключение OverflowException в тех случаях, когда Guid на самом деле хранит что-либо, кроме 0, в последних 64 битах, так как результирующий длинный не сможет быть преобразован обратно в тот же Guid. *
Итак, как таковой ...
Пока созданный гид подходит
чем долго, это возможно? Это
только когда это проходит над
указанный размер. Правильно?
Верно ... Очевидно, что соответствующее длинное значение GUID не легко читаемо, вот несколько примеров (long = guid):
1.340 = 0000053c-0000-0000-0000-000000000000
98.605 = 0001812d-0000-0000-0000-000000000000
149.957 = 000249c5-0000-0000-0000-000000000000
218.125.225 = 0d0053a9-0000-0000-0000-000000000000
4.249.596.910 = fd4bb3ee-0000-0000-0000-000000000000
23.139.913.545 = 633f0f49-0005-0000-0000-000000000000
9.223.372.036.854.775.807 = ffffffff-ffff-7fff-0000-000000000000
-9.223.372.036.854.775.808 = 00000000-0000-8000-0000-000000000000
-1 = ffffffff-ffff-ffff-0000-000000000000
И да, преобразование этих способов работает в обе стороны и для любой длинной ценности, которую вы можете придумать ...
Но потому что вы утверждаете, что:
Создание Guid находится вне моего контроля.
Крайне маловероятно, что вы на самом деле можете сделать это, вместо этого, скорее всего, ваш Guid сгенерирован с использованием любого из распространенных алгоритмов, и это сделает Guid непригодным для использования в этом сценарии.
Теперь, имеет ли это смысл делать? ... Это требует понимания конкретной ситуации, и это совсем другое обсуждение ...