Eindeutige ID aus einem String berechnen

[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.

[TurboMagic]

Schon mal nach alternativen Hash Algorithmen als MD5 geschaut? Es gibt auch welche die nur 64 bit oder 80 bit lange Hashes erzeugen.

DEC beispielsweise enthält die Klasse THash_Sapphire, welche einen Hash Algorithmus umsetzt, der 64 bit Ergebnisse produziert.
DEC ist via Github hier zu finden: https://github.com/winkelsdorf/Delph...tionCompendium

[jfheins]

Zitat von Bünni:

Die einfachste Umsetzung wäre es das Verzeichnis in den jeweiligen MD5 Hash umzubenennen. Die Benutzerfreundlichkeit sinkt dann aber, weil ein Benutzer nicht mehr auf Anhieb sieht, welches Verzeichnis zu welchem Datensatz gehört.

Ich würde mich da an vorhandenen Lösungen orientieren. git zum Beispiel speichert alle Objekcte unter ihren SHA1 Hash-Werten. Das heißt, ein Objekt hat den Hashwert d670460b4b4aece5915caf5c68d12f560a9fe3e4 und wird dann unter dem Dateipfad .git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 abgelegt.

Macht insg. maximal 256 Ordner und darin dann viele Dateien, im Falle von git meistens mit SHA-1 (wird aber umgestellt glaub ich).

Das Argument "Eigentlich hat ein Nutzer in diesen Daten nichts zu suchen, da alles über die Benutzeroberfläche und Business Logik erledigt wird." ist super, wenn eh alle in der Anwendung abrufbar ist, fummeln User in einer zugänglichen Datenstruktur nur zuviel rum.

[Jasocul]

Vielleicht ein wenig OT aber vielleicht doch relevant:

Zitat von Bünni:

Die Benutzerfreundlichkeit sinkt dann aber, weil ein Benutzer nicht mehr auf Anhieb sieht, welches Verzeichnis zu welchem Datensatz gehört.

Der Benutzer kann dirket auf die Verzeichnisse zugreifen?
Das halte ich für nicht ganz ungefährlich. Vielleicht gefällt dem Benutzer ja der Verzeichnisname nicht und er ändert den. Die Konsequenzen für deine Anwendung kannst nur du abschätzen.

Zitat von 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.

Der Index (oder besser die ID) eines Datensatzes sollte man nicht ändern. Der Index in deinem TreeView, wo du möglicherweise deine Daten einliest, hat mit dem Datensatz absolut gar nichts zu tun.

Wenn deine Datensätze eine eindeutige ID haben, dann nutze diese. Wenn nicht, dann erzeuge dir welche. Damit bist du dein Problem sofort los, da du die ID für die Verzeichnisse nutzen kannst.
Ich kenne deine Anwendung nicht, aber die Nutzung dieser Verzeichnisse sollte nur über die Anwendung passieren. Sobald ein Anwender darin rumpfuschen kann, wird das auch passieren. D.h.: Die Verzeichnisnamen müssen (besser dürfen) für den Anwender nicht lesbar sein. Sobald diese lesbar sind, werden diese "verbessert".

EDIT:

Zitat von Bünni:

Anhand des Strings wird ein Verzeichnis angelegt. Der String wird vorher aber bereinigt und unzulässige Zeichen und andere besondere Zeichen entfernt.
Es gibt Konstellationen, da bleibt am Ende das gleiche Ergebnis übrig. Deswegen würde ich gerne eine ID hinten dranhängen

Wenn du es denn wirklich so machen willst, ist es ziemlich egal, welche Mehode du verwendest, da der String selbst ja ein Teil des Verzeichnisnamens ist. Ein angehänges crc, Hash oder sonstwas wird es dir eindeutig machen. Die Gefahr, das zwei verschiedene Strings die selbe "ID" erzeugen macht gar nichts, da der String auch Teil des Names ist.

[AndyDF]

Hier findest du noch Informationen zum Erzeugen eines 32-Bit Integer Hashes eines Strings:

https://stackoverflow.com/questions/...shing-function

Schau dir dort mal die Funktion Murmur2 an.

Kollisionen sind sicher möglich. Ist aber alles eine Frage der Wahrscheinlichkeit.

[Luckie]

Noch eine Anmerkung zu den gebrochenen Hashes. Ich denke, das spielt für ihn keine Rolle. Da das nur unter Laborbedingungen passiert oder bei gezielten Angriffen. Dass sein Programm doppelte Hashes erzeugt, dürfte verschwindet gering sein. Wie viele Jahrzehnte hat man mit ihnen selbst bei sicherheitskritischen Anwendungen gearbeitet?

[Rudy Velthuis]

Zitat von 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?

Genau das war auch mein Gedanke. Einfach die Kollisionen durchnumerieren.