Eindeutige ID aus einem String berechnen

[Uwe Raabe]

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.

In dem Fall könnte der CRC-Wert des originalen Strings tatsächlich funktionieren. Die Wahrscheinlichkeit, daß der CRC-Wert unterschiedlicher Strings gleich ist und das auch die bereinigten Strings dasselbe Ergebnis bringen ist ziemlich unwahrscheinlich.

Kannst du den Originalstring nicht in einer kleinen Textdatei in dem jeweiligen Verzeichnis speichern? Dann könnte man solche Kollisionen zumindest erkennen und man hätte auch noch Zugriff auf den Originalstring.

[Bünni]

Die Originalstrings werden bereits gespeichert und etwaige Duplikate schon behandelt.
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.

[Uwe Raabe]

Hast du mal probiert, ob es tatsächlich noch zu Kollisionen kommt, wenn du den CRC an den bereinigten String anhängst?

[Bünni]

Zitat von Uwe Raabe:

Hast du mal probiert, ob es tatsächlich noch zu Kollisionen kommt, wenn du den CRC an den bereinigten String anhängst?

Das kann ich leider später erst testen. Ich bin mir aber sehr sicher, dass es nicht mehr zu Kollisionen kommt.

Zitat:

Wenn in den Strings nur die Großbuchstaben A-Z und die Ziffern 0-9 vorkommen, muss pro Zeichen eigentlich nur ein Wert von 0-35 abgespeichert werden, nicht von 0-255 (AnsiChar) oder gar mehr.

Der Zeichenbereich dürfte wegen Kompatibilitätsgründen eigentlich immer gleich bleiben. Aber es sind dann leider doch ein paar Zeichen mehr die erlaubt sind.

[dummzeuch]

Welche Zeichen können in den Strings denn vorkommen? Ggf. kann durch eine geschickte Kodierung daraus immernoch eindeutige aber deutlich kürzere Binärcodes erzeugen.

Beispiel:

Wenn in den Strings nur die Großbuchstaben A-Z und die Ziffern 0-9 vorkommen, muss pro Zeichen eigentlich nur ein Wert von 0-35 abgespeichert werden, nicht von 0-255 (AnsiChar) oder gar mehr. Damit könnte man 256/36 = > 7 Zeichen in einem Byte abspeichern.

Das ist natürlich nicht ganz ungefährlich, wenn Du nicht sicherstellen kannst, dass sich dieser Zeichenbereich nicht irgendwann ändert. Irgendwann kommt der Chef und sagt, "Wir lassen jetzt auch Kleinbuchstaben und Sonderzeichen zu.", und schon fliegt Dir der Algorithmus um die Ohren. Und erfahrungsgemäß wird der Programmierer bei solchen Entscheidungen nicht vorher gefragt.

EDIT: Ich sehe gerade, dass es im Ergebnis um Verzeichisnamen geht. Damit kann man meine Idee nicht mehr so einfach umsetzen.

[Redeemer]

Zitat von dummzeuch:

Welche Zeichen können in den Strings denn vorkommen? Ggf. kann durch eine geschickte Kodierung daraus immernoch eindeutige aber deutlich kürzere Binärcodes erzeugen.

Beispiel:

Wenn in den Strings nur die Großbuchstaben A-Z und die Ziffern 0-9 vorkommen, muss pro Zeichen eigentlich nur ein Wert von 0-35 abgespeichert werden, nicht von 0-255 (AnsiChar) oder gar mehr. Damit könnte man 256/36 = > 7 Zeichen in einem Byte abspeichern.

Das ist auf so viele Arten und Weisen einfach nur falsch:

• Der Zeichenvorrat beträgt nicht 256. Wenn man von ANSI ausgeht, liegt die Anzahl der Zeichen bei etwa 215 (unter Abzug von neun sichtbaren nicht erlaubten Zeichen und 32 Steuerzeichen).
• Der Zeichensatz von NTFS ist aber UTF-16. Da man UTF-16-Codepunkte nicht beliebig aneinanderreihen kann, muss man stattdessen UCS-2 verwenden. Von dessen 63.488 Zeichen zieht man dann wieder die 41 ab. Ich würde mal vermuten, dass man auch hier nicht alle Zeichen verwenden kann, aber es geht um die Größenordnung.
• Und das schlimmste: Man kann nicht einfach dividieren. Korrekt wären also für ANSI lb(215)/lb(36), was nur ganz knapp unter 1,5 ergibt. Für UCS-2 ergibt sich mit lb(63447)/lb(36) erwartungsgemäßg gut das Doppelte (ca. 3,09). Von deiner 7 ist man sehr sehr weit entfernt.

(Edit: Natürlich kann man statt lb auch ln oder lg rechnen. lb ergibt aber am meisten Sinn, da man so sofort erkennt, dass es hier um die Entropie (in Bit) geht, die sich damit ergibt. Und das Verhältnis der Entropien ist ja anschaulich das, worum es dummzeuch ging.)

[peterbelow]

Zitat von Bünni:

Die Originalstrings werden bereits gespeichert und etwaige Duplikate schon behandelt.
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.

Mal eine Bemerkung dazu, die vielleicht etwas off -topic ist. Für einen Benutzer ist das Ablegen von Datensätzen in Dateien mit langen Namen ein usability-Alptraum, egal ob Du nun noch eine ID anhängst oder nicht. Hast Du mal versucht, in einem Verzeichnis mit mehreren Hundert Dateien mit langen Namen etwas zu finden? Das geht eigentlich (im Explorer) nur mit der Suchfunktion, alles andere ist eine Strafe, besonders, wenn die Namen auch noch so lang sind, dass sie im Explorerfenster abgeschnitten werden.

Häng die ID an, das macht es auch nicht viel schlimmer als es eh schon ist.

[Bünni]

Die Verzeichnisse werden jetzt nach einem MD5 Hash benannt. Das war die einfachste Umsetzung, ohne dass man noch an anderen Stellen Anpassungen machen muss die bei jeder kleinen Änderung hinfällig sind. Eigentlich hat ein Nutzer in diesen Daten nichts zu suchen, da alles über die Benutzeroberfläche und Business Logik erledigt wird.

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