GUID - Warum diese Darstellung als String

[bernau]

Einfach Interessehalber

Warum ist die String-Darstellung einer GUID so wie sie ist?

Also : "{12345678-ABCD-1234-ABCD-1234567890AB}".

Warum die Geschweiften klammern? Warum die Bindestriche? Genau so gut hätte man diese weg lassen können.

Sind 6 Byte in einem String, die eigentlich absolut sinnlos sind. Eine Speicherung ohne diese Zeichen würde doch nichts an der Eindeutigkeit ändern.

Also : "12345678ABCD1234ABCD1234567890AB".


Was hat man sich also dabei gedacht?

[HolgerX]

Hmm..

Das Format mit den Minuszeichen kommt vom Inhalt..

https://en.wikipedia.org/wiki/Univer...que_identifier

Zitat:

The canonical 8-4-4-4-12 format string is based on the record layout for the 16 bytes of the UUID:[2]

Die Klammen scheint sich Microsoft ausgedacht zu haben.

Zitat:

Microsoft GUIDs are sometimes represented with surrounding braces

[ghubi01]

Hallo,

es gibt da schon unterschiedliche Darstellungen: https://www.it-visions.de/glossar/al...dentifier.aspx
Aber warum das so ist, wird dort auch nicht erklärt.
Vielleicht dienen die Bindestriche nur zur besseren Lesbarkeit, ähnlich wie bei der IBAN-Nr (alle 4 Zeichen folgt ein Leerzeichen).

[jaenicke]

Zitat von ghubi01:

Aber warum das so ist, wird dort auch nicht erklärt.

Bei Wikipedia wie von HolgerX verlinkt steht doch die Erklärung. Da gibt es eine Tabelle zum UUID record layout, in der die einzelnen Teile erklärt werden.
Und so wurde diese Darstellung eben auch zum Standard für solche IDs generell, auch wenn sie etwas anderes enthalten.

[bernau]

Die WIKI-Seite habe ich schon gelesen. Ich sehe auch, dass die Bindestriche die fünf Komponenten der GUID trennen.

Aber aus Lesbarkeit wird es kaum sein. Wer kann schon eine GUID "lesen" und dem Computer dürfte es bei vergleichen von zwei GUID Wurst sein, ob Bindestriche und Klammern vorhanden sind, oder nicht.

Der Link von ghubi01 zeigt aber auch, dass es verschiedene Darstellungsweisen gibt und die Art der Darstellung anscheinen Geschmacksache ist.

Ich dachte zuerst, die Darstellungsweise sei irgendwie optimiert um Vergleiche besser durchführen zu können. Ist aber anscheinend nicht so.

[Sherlock]

Es ist Lesbarkeit, und die GUID setzt sich ja aus definierten Dingen zusammen, und folgt dabei einem festgelegten Format, das (wenn man es kennt) es ermöglicht, die einzelnen durch Bindestriche getrennten Blöcke auszuwerten.
Außerdem verwenden manche (zB Microsoft) GUIDs als Registriernummern, die man sich auch mal vorlesen muss.

O'Neill

[Jumpy]

Könnte man sich das nicht auch für 1000 andere Dinge fragen?
MAC-Adressen, IPs, Product-keys, ...

[venice2]

Zitat von Jumpy:

Könnte man sich das nicht auch für 1000 andere Dinge fragen?
MAC-Adressen, IPs, Product-keys, ...

Ich frage mich auch warum 1 + 1 = 2 und nicht 11 oder 1 + 2 = 3 und nicht 12 sind.
Das könnte man so fort führen. Es ist nun mal so festgelegt.

[stahli]

Als Vorteil sehe ich die Lesbarkeit und eine gewisse Validierung, dass es sich vorliegend tatsächlich um eine GUID handelt und nicht einfach um einen String in der zufällig richtigen Länge.

Nachteilig ist natürlich der Speicherverbrauch und ggf. 1/2 ms längere Rechenzeit.

[himitsu]

Zitat:

Das Format mit den Minuszeichen kommt vom Inhalt..

Jupp, denn die Bindestriche, bzw. die Trennzeichen sind extrem wichtig, da die Byteorder zu beachten ist,
weil die Reihenfolge der Bytes im Speicher (Little-Endian > BinToHex) nicht mit den decodierten Werten (IntToHex > Big-Endian) übereinstimmt. (außer im alten MacOS)

Code:

LongWord Word Word Byte-Array
01234567-89AB-CDEF-0123-456789ABCDEF
67452301 AB89 EFCD 0123 456789ABCDEF

zum Selbstausprobieren

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var
  G: TGUID;
  S, B: string;
begin
  S := '01234567-89AB-CDEF-0123-456789ABCDEF';
  G := StringToGUID('{' + S + '}');

  SetLength(B, SizeOf(G) * 2);
  BinToHex(G, PChar(B), SizeOf(G));
  Insert(' ', B, 21);
  Insert(' ', B, 17);
  Insert(' ', B, 13);
  Insert(' ', B, 9);

  ShowMessage(S + sLineBreak + B);
end;

Ich werde wohl nur einfach nie kappieren, warum der vorletzte Block kein Word und somit nicht auch umgedreht wird,
jedenfalls nicht dank der aktuellen Typdefinition, wo ich's einfach beim kurz Hingucken immer überseh.

Delphi-Quellcode:

  TGUID = packed record
    D1: LongWord;
    D2: Word;
    D3: Word;
  //D4: array[0..7] of Byte;  // von Microsoft/Delphi
    D4: array[0..1] of Byte;  // meine Interpretation
    D5: array[0..5] of Byte;  // ...
  end;

Zitat:

Sind 6 Byte in einem String, die eigentlich absolut sinnlos sind. Eine Speicherung ohne diese Zeichen würde doch nichts an der Eindeutigkeit ändern.

Dann speichere es binär und es ist nochmal die Hälfte an Bytes. Bei Unicode sogar nur ein Viertel.
Sogar viele Datenbanken bieten einen GUID-Typ, um es direkt formatunabhängig zu speichern und optimaler zu suchen.

Selbst der Delphi-Compiler bietet diese automatische Konvertierung schon seit Jahrzehnten, zumindestens teilweise bei Interfaces und Konstanten.

Delphi-Quellcode:

const
  C: TGUID = '{01234567-89AB-CDEF-0123-456789ABCDEF}';  // hier ja

procedure TForm1.FormCreate(Sender: TObject);
var
  G: TGUID;
begin
  G := '{01234567-89AB-CDEF-0123-456789ABCDEF}';  // aber hier nicht :roll:
  G := TGUID('{01234567-89AB-CDEF-0123-456789ABCDEF}');  // und so auch nicht
end;