Eindeutige ID aus einem String berechnen

[FaTaLGuiLLoTiNe]

Kannst du nicht einfach laufende Nummern verwenden und dir irgendwo ein Verzeichnis anlegen, in dem du dir die Zuordnung von String zu Nummer (= Name des Ordners) merkst?

[Bünni]

Jeder Datensatz hat intern einen Index, der sich aber bei jedem Programmstart ändern kann je nachdem, ob die Daten verändert wurden oder nicht. Im Normalfall ist davon auszugehen, dass sich die Daten bei jeder Sitzung mindestens einmal stark ändern. Leider nicht möglich mit einem Index.

Eine GUID wäre eventuell eine Lösung, wenn ich sie auch für jeden Datensatz in der Konfigurationsdatei mit ablege.
Aber wie berechnet man eine korrekt formatierte GUID aus einem String?

[Schokohase]

Ob der MD5 HashWert in der Darstellung zu lang wird, hat doch nur etwas mit der Art der Darstellung zu tun.

Ein MD5-HashWert hat 128-bit. Diesen kann man Hexadezimal darstellen und erhält 32 Zeichen.

Code:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Zu lang? Dann hätten wir da noch eine Base64-Darstellung und erhalten von dem gleichen Wert

Code:

/////////////////////w==

also 24 Zeichen (bzw. 22 denn die letzten beiden sind in diesem Falle immer gleich).

Also, wie lang darf die errechnete ID aus dem String denn nun sein?

PS: Wer jetzt einwenden möchte, dass in dem Base64 Zeichen vorkommen, die in einem Pfad nicht vorkommen dürfen, der hat Recht und ich überlasse es jedem selber dieses mit etwas Fantasie selber zu lösen.

[Bünni]

So gesehen darf die ID so lang sein, bis das Dateisystem damit nicht mehr zurecht kommt. Der besseren Lesbarkeit aber dachte ich, je kürzer desto besser.

Ich glaube CRC32 reicht nachdem ich mir die Antwort von Victor Stoddard durchgelesen habe
https://stackoverflow.com/questions/...for-common-use

Und dann wäre da noch S. Lott
https://stackoverflow.com/questions/...-vs-crc-length

[Dennis07]

Bedenkt, dass Hashes ebenso nicht "eindeutig" sind, da zu jedem Hash auch unbegrenzt viele Strings gehören.
CRC32 ist nur deshalb keine Hashfunktion, weil du aus ihr den eigentlichen String sehr leicht wieder zurückgewinnen kannst. Dennoch hast du das gleiche Problem, wenngleich graduell geringer, auch bei Hashfunktionen (was diese von "Verschlüsselungen" unterscheidet).
Es gibt so gesehen keine wirklich effiziente Möglichkeit, einen String in eine Zahl zu verwandeln, die wirklich eindeutig ist, ohne den vollen String selber zu beinhalten.
Was du machen könntest, wäre noch folgendes (keine sichere Verschlüsselung!):
Jedes ACSII-Zeichen befindet sich im Bereich von 0 bis 127. Solltest du also nur diese Zeichen brauchen, kannst du den zweiten teil des Bytes hinten weg lassen und mit dem nächsten Zeichen füllen. Ist aber auch nicht 100%-ig eindeutig, und vor allem nur für Zeichen des Standardzeichensatzes.

[Nju]

Ich klinke mich mal mit ein:
Der Threadersteller möchte eine eindeutige ID. CRC ist nicht dazu gedacht, eindeutige IDs zu generieren, da eine Kollision zu schnell herbeigeführt werden kann. Wikipedia gibt dazu als Beispiel die Wörter "buckeroo" und "plumless" an, die den gleichen CRC32-Wert besitzen. Die Wahrscheinlichkeit, dass der Threadersteller eine Kollision erhält, ist nicht unwahrscheinlich.

*edit*
Ich habe mir den ganzen Thread nochmal durchgelesen. Der Sinn des Ganzen erstreckt sich mir zwar nicht, aber von CRC würde ich absehen. Eine fortlaufende Nummer reicht da in meinen Augen als eindeutige Identifizierung.

[dummzeuch]

Zitat von Dennis07:

Bedenkt, dass Hashes ebenso nicht "eindeutig" sind, da zu jedem Hash auch unbegrenzt viele Strings gehören.
CRC32 ist nur deshalb keine Hashfunktion, weil du aus ihr den eigentlichen String sehr leicht wieder zurückgewinnen kannst.

Das ist falsch. Was man leicht finden kann, ist eine Eingabe, die denselben CRC32-Wert ergibt, nicht jedoch notwendigerweise die Eingabe, die den CRC32-Wert ergeben hat. Letzteres ist schlicht unmöglich, es sei denn, die möglichen Eingaben sind sehr beschränkt.

[Dennis07]

Zitat von dummzeuch:

Zitat von Dennis07:

Bedenkt, dass Hashes ebenso nicht "eindeutig" sind, da zu jedem Hash auch unbegrenzt viele Strings gehören.
CRC32 ist nur deshalb keine Hashfunktion, weil du aus ihr den eigentlichen String sehr leicht wieder zurückgewinnen kannst.

Das ist falsch. Was man leicht finden kann, ist eine Eingabe, die denselben CRC32-Wert ergibt, nicht jedoch notwendigerweise die Eingabe, die den CRC32-Wert ergeben hat. Letzteres ist schlicht unmöglich, es sei denn, die möglichen Eingaben sind sehr beschränkt.

Der erste von dir zitierte Satz sagt doch genau das. Wenn du aber nur auf den zweiten inhaltlich eingehst, so kann es natürlich durchaus zu so einem Missverständnis kommen, da nur der allein nicht ganz eindeutig ist (genau wie Hashes und CRC32, ha ha).
Und selbst dann ist dein Einwand doch vollkommen irelevant, weil das Problem doch trotzdem da ist: Es gibt mehrere Strings mit dem selben CRC-Wert. Also ist er nicht eindeutig, zumindest nicht in beide Richtungen. Somit für die Fragestellung nicht zu gebrauchen. Meine Aussage war ja nur, dass das bei Hashfunktionen halt eben nur graduell anders ist: Auch diese sind nicht eindeutig.

Zur Sicherheit, und warum CRC für Hashes ungeeignet ist: Ja, natürlich bekommst du in beiden Fällen nicht das originale Word zurück. Ist aber doch vollkommen egal. Ein möglicher Hash reicht ja schon. Und da es bei CRC32 nun mal, wie von mir beschrieben, sehr leicht ist, diesen bzw. eins zu bekommen, ist es ungeeignet. Das heißt aber nicht, dass Hashfunktionen wie SHA128 "eindeutig" sind. Sie sind nur "eineutiger".

[Sherlock]

Verstehe nicht, was gegen "Durchnummerieren" spricht.

Und nur zum Verständnis: eine GUID wird nicht aus einem String errechnet, sondern ist eine zusammengesetzte 128-Bit Zahl mit Zeitanteilen, Versionsangabe und einem großen pseudozufälligen Rest.

Sherlock

[Dennis07]

Zitat von Sherlock:

Verstehe nicht, was gegen "Durchnummerieren" spricht.

Ich denke das ist nicht wirklich, was er will.
Dafür müsstest du ja eine TStringList oder besser noch ein TDictionary<String, Integer> machen, und alles dort nochmal separat abspeichern.