Eindeutige ID aus einem String berechnen

[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

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

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

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

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

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