25 replies to this topic

[Johnny R]

Ich habe Bedarf nach einem Tool, das aus ganz, ganz langen Dateinamen in ganz, ganz verschachtelten Verzeichnissen auf der heimischen Festplatte nach Art des goo.gl-Url Shorteners ganz, ganz kurze Strings entwickelt, also z. B.:

C:\Windows\Branding\ShellBrd\shellbrd.dll -> .shortfile.abcde

 

Ich gehe davon aus, daß es solch ein Tool bisher nicht gibt. Ich habe nichts gefunden. Oder wißt Ihr etwas?

 

Ich beabsichtige, das mit einer ini-File zu lösen. Ist das OK? Z.B.:

abcde = C:\Windows\Branding\ShellBrd\shellbrd.dll

Ich beabsichtige, die Kurznamen mit dem Random string generator  zu entwickeln. Ist das auch OK?

Wie lange sollten die Kurznamen sein, um genügend viele lange Dateinamen repräsentieren zu können?

Ein Unterschied in Groß/Kleinschreibung läßt sich mit ini-Files ja wohl nicht verwirklichen, Oder?

...

[nnnik]

 

Ein Unterschied in Groß/Kleinschreibung läßt sich mit ini-Files ja wohl nicht verwirklichen, Oder?

Doch.

 

Wie lange sollten die Kurznamen sein, um genügend viele lange Dateinamen repräsentieren zu können?

Das hängt davon ab:

Wenn du es wiklich Zufällig machen möchtest benutzt du nicht die volle Kapazitäten der Länge es ist also Zufall ob sich Dateinamen überschneiden.

 

Allerdings versteh ich bei deiner Frage 1 noch nicht:

Möchtest du die Namen in einer Ini speichern und dann mit AHK verarbeiten?

Je nachdem wie du es haben willst kann deine Lösung unterschiedlich viele Dateien pro Zeichen bearbeiten:

UChar = 1 Byte = 256 Möglichkeiten:

UChar = 1 Ansi Zeichen (0 Terminated String) = 255 Möglichkeiten (-0 Char)

UChar = 1 lesbares Ansi Zeichen (0 Terminated String) ~  222 Möglichkeiten (-Steuerungs Zeichen, -0Char)

UChar = 1 Dateinamen ~ 200 Möglichkeiten (-Steuerungs Zeichen, -0Char,-\?..)

[Johnny R]

Möchtest du die Namen in einer Ini speichern und dann mit AHK verarbeiten?

Ja. Ich möchte in einem Text einen Shortstring markieren und die dazugehörende Datei per ini-file mit AHK aufrufen.

 

Bist Du wirklich sicher, daß IniRead Upper/Lower/Mixed sicher unterscheidet, also case sensitive ist? Führt also "ABC", "abc" und "aBc" zu jeweils unterschiedlichen Zeilen in der ini-File? Vgl.:

The GetPrivateProfileString function is not case-sensitive; the strings can be a combination of uppercase and lowercase letters.

http://msdn.microsof...3(v=vs.85).aspx

 

Ich möchte mit ANSI-Buchstaben und-Zahlen (also 36 verschiedene Zeichen) arbeiten weil das wohl am unproblematischsten ist. Meine Mathestunden sind leider schon einige Tage her. Wenn ich geshortet 10 Zeichen verwende, für wieviele Dateien reicht das aus? Mit Upper/Lower/Mixed wäre das dann ja noch mal potenziert...

[Alibaba]

Potenziert wird hier so oder so:
Theoretisch handelt es sich hier ja um eine 10 stellige zahl aus dem 36er System, demzufolge gibt es 36 hoch 10 möglichkeiten.
Das entspricht rund 3656158400000000 Dateien. sollte reichen.
Die zahl liest sich übrigens "drei Billiarden sechshundertsechsundfünfzig Billionen einhundertachtundfünfzig Milliarden vierhundert Millionen".

[Johnny R]

Das entspricht rund 3656158400000000 Dateien. sollte reichen.

Das sehe ich auch so, fürs Erste. Größenbeschränkungen für ini-files gibt es ja seit WinXP nicht mehr, soweit ich weiß.

 

Wenn du es wiklich Zufällig machen möchtest benutzt du nicht die volle Kapazitäten der Länge es ist also Zufall ob sich Dateinamen überschneiden.

Solltest Du einen anderen, besseren, Generator kennen als Random, hätte ich keine Einwände. Daß sich keine Datei überschneidet, müßte natürlich durch vorherige Abfrage sichergestellt werden.

[Seidenweber]

...imo reichen 5 Zeichen. 36^5 = 60.466.176 und die Schlüsselnamen in der Ini-Datei sind NICHT case-sensitive. KeYnAmE und kEyNaMe werden gleich behandelt.

[nnnik]

 

...imo reichen 5 Zeichen. 36^5 = 60.466.176 und die Schlüsselnamen in der Ini-Datei sind NICHT case-sensitive. KeYnAmE und kEyNaMe werden gleich behandelt.

0.0 Es ist schon gut,dass ich inis nie benutzt habe.

@Topic

Ich würde Hashs verwenden die dann die Namen geben, da diese viel zuverlässiger sind.

http://www.autohotke...yption-hashing/

Es wäre dann viel sinnvoller Hex oder Base64 als "Namensgeber" zu verwenden.

Dann könntest du die Hashes die beim Hashen entstehen direkt benutzen.

GetHash(Filename){
Global Crypt
shortfilename:=Crypt.Hash.FileHash(Filename)
shortfilename2:=Crypt.Hash.StrHash(Filename)
If !(shortfilename|&shortfilename2)
 return "Ziel Datei existiert nicht"
Loop, Parse, shortfilename
shortfilenamefinal:=chr(asc(substr(shortfilename2,A_Index-1,1))^asc(A_LoopField)) ;Xoring (Verrechung Zweier Zahlen mit dem Informationsverlust von einer Zahl)
return shortfilenamefinal
}

[Johnny R]

Ich würde Hashs verwenden die dann die Namen geben, da diese viel zuverlässiger sind.

Ist es wirklich sichergestellt, daß jeder Hash wirklich nur einmal verwendet wird und nicht ggf. zwei oder mehr Dateien den gleichen Hash bekommen? Wodurch ist das ggf. sichergestellt?

[jNizM]

Auch verschiedene Dateien können im ungünstigsten Fall den selben Hash bekommen.
Die Wahrscheinlichkeit ist aber gering.
Verwende am besten SHA-2 512 (bietet zzt den sichersten Hash-Wert, bis SHA-3 (Keccak) offiziell ist)

zb mit Bentschi's Hash-Funktion

[Seidenweber]

Ist es wirklich sichergestellt, daß jeder Hash wirklich nur einmal verwendet wird und nicht ggf. zwei oder mehr Dateien den gleichen Hash bekommen? Wodurch ist das ggf. sichergestellt?

nö.

Und außerdem das ist sowieso alles pimpe, weil die Anzahl der gültigen Möglichkeiten für die Zeichenfolge eines kompletten Pfades astronomisch hoch ist.

Die Länge der sich daraus ergebenden Hashes lässt sich in der von dir vorgesehenen Form überhaupt nicht vernünftig handhaben.

 

Das ganze lässt sich eigentlich nur sinnvoll über einen einmal festgelegten Index lösen, wie URL-Shortener das auch machen.

[Alibaba]

nö.

Und außerdem das ist sowieso alles pimpe, weil die Anzahl der gültigen Möglichkeiten für die Zeichenfolge eines kompletten Pfades astronomisch hoch ist.

Die Länge der sich daraus ergebenden Hashes lässt sich in der von dir vorgesehenen Form überhaupt nicht vernünftig handhaben.

 

 

Vielleicht hab ich dich falsch verstanden, aber die Länge des Hashes kann eigentlich kein Problem sein, denn der Hash ist ja immer gleich lang, unabhängig von der Größe der Ausgangsdaten.

Trotzdem würde ich ebenfalls die Lösung mit dem Index vorschlagen. Die Wahrscheinlichkeit, dass Random bei mehr als drei Billiarden sechshundertsechsundfünfzig Billionen einhundertachtundfünfzig Milliarden vierhundert Millionen Möglichkeiten, 2 mal den selben Name liefert ist verschwindend gering. Die Wahrscheinlichkeit steigt zwar mit jedem weiteren vergebenem Name, aber problematisch dürfte das erst bei mehreren Milliarden Zuweisungen werden. Und falls es doch mal zur Kollision kommt, dann kann man das über eine einfache If-Abfrage und das erneute generieren eines Namens klären.

[jNizM]

Hier ist eine gute Erklärung wie das in PHP realisiert wird Eigenes URL Shortener / Kürzer Script mit PHP

[Seidenweber]

Vielleicht hab ich dich falsch verstanden, aber die Länge des Hashes kann eigentlich kein Problem sein, denn der Hash ist ja immer gleich lang, unabhängig von der Größe der Ausgangsdaten.

 

Die Frage ist aber, WIE lang. NTFS erlaubt Dateinamen bis zu 255 Zeichen Länge, bestehend aus beinahe dem gesamten Unicode-Zeichensatz. Mit was für einem "kurzen" Hash willst du das denn eindeutig abbilden?

[jNizM]

MD2    -->  32 Stellig
MD4    -->  32 Stellig
MD5    -->  32 Stellig
SHA1   -->  40 Stellig
SHA256 -->  64 Stellig
SHA384 -->  96 Stellig
SHA512 --> 128 Stellig 

Nochmaliger Verweis --> PHP-Fuction

[Seidenweber]

ja. Klingt für mich nach mehr als 5 oder vielleicht auch 10.