Dlaczego binarny GUID różni się od zwykłej reprezentacji

Mam następujące GUID:Dlaczego binarny GUID różni się od zwykłej reprezentacji

AAB13E97-449B-4D5B-BDE2-AC479C31B782

Korzystanie System.Guid + DbLinq + SQLite do przechowywania go dodaje pole jest dodawane do bazy danych.

973EB1AA-9B44-5B4D-BDE2-AC479C31B782

(Kreski dodana dla jasności)

widzę, że ostatnie 8 bajtów są w tej samej kolejności, a 3 pierwsze grupy są odwrócone, ale nie rozumiem dlaczego.

Źródło

2011-02-15 Jader Dias

Patrząc na Wikipedia's article on the subject mówi:

Data4 przechowuje bajtów w takiej samej kolejności jak pokazano na kodowanie tekstu GUID (patrz poniżej), ale pozostałe trzy pola są odwrócone w systemach little-endian (dla przykład procesory Intela).

Więc Podsumowując:

Dzieje się tak niezależnie od DBMS lub ramy stosowane
To zależy od architeture procesora
To jest zgodne z projektem

więc pytanie pozostaje:

Dlaczego na e Czy zaprojektowali to w ten sposób?

Źródło

2011-02-15 11:31:36

"Dlaczego, na litość, zaprojektowali to w ten sposób?" - domyślam się, że pierwotnie GUIDy V1 utrzymywały adres MAC w polu Data4. Historycznie big-endian został zdefiniowany jako standardowy bajt sieciowy i był używany w wielu sprawach związanych z siecią, takich jak adresy IP, adresy MAC itp. –

Z Wikipedii: 'Wersja 1 (adres MAC) Koncepcyjnie, oryginał (wersja 1) Schemat generacji dla UUID polegał na połączeniu wersji UUID z adresem MAC komputera, który generuje UUID, oraz z liczbą interwałów 100-nanosekundowych od czasu przyjęcia kalendarza gregoriańskiego na Zachodzie. System ten został skrytykowany, ponieważ nie jest wystarczająco "nieprzejrzysty"; ujawnia zarówno tożsamość komputera, który wygenerował UUID, jak i czas, w którym to zrobił " –

Dlaczego binarny GUID różni się od zwykłej reprezentacji

Odpowiedz

Powiązane problemy