TinyURL.com nachprogrammieren

[Truncate]

Hallo,

weiß jemand welches System hinter TinyURL.com steckt?

Die verwandeln eine URL in einen gerade mal 6-stelligen Code, also eher nichts mit md5() sondern eine andere ID-Generierung.

[Blackgreetz]

Warum nicht md5?...

substr(0,6,md5()) und fertig..
das ganze speichern die in der datenbank und ja...

<<< denk ich mir jetzt alles so...ka genau^^

[Truncate]

Das würde doch aber zu Überschneidungen führen... kann mir nicht vorstellen, dass es ein gekürzter MD5()-Link sein soll...

[MelloPie]

wo is das Problem?
die basteln sich irgendwas zusammen und speichern das in ner DB ab...
6 Zeichen lang und unique halten fertig
bei nur Buchstaben ohne auf gross/klein zu achten und ziffern hat man 36^6 (2176782336) möglichkeiten

[MelloPie]

ach und wenn die paar Möglichkeiten aufgebraucht sind kann man sicher auf 7 stellen gehen :-)

[prego]

http://de.php.net/uniqid

[frankburian]

;O)

das ist eine eindeutige zufällig generierte ID die dann mit der org. URL in der Datenbank gespeichert wird.

ist doch gnz simple!

Mit MD5 werden die mir sicherheit nicht handtieren!

[ArSeN]

Hm... Ich hab neulich ein Gutschein-Generierungs-System geschrieben, dafür sollten die Codes natürlich auch nicht 32 Zeichen lang sein, MD5 war also außer Frage.

Irgendwann kam ich dann aber darauf, das Attribut in der Datenbank, in der der Schlüssel gespeichert wird einfach Unique zu halten, und eine Schleife zu bauen, die falls die Einfügung einer neuen ID nicht gemeistert werden konnt (weil sie nämlich schon existiert) einfach ein weiteres Mal durchlaufen wird. So hab ich mit Sicherheit immer die Anzahl an Gutscheinen die ich haben will, und sie sind garantiert einzigartik. Mit 15 Stellen gibt es glücklicherweise immernoch 1.152.921.504.606.846.976 mögliche Kombinationen, ich weiß nichmal wie die Zahl heißt

äh.. PS: Ich hab die ersten 15 Zeichen von nem zufallsgenerierten MD5 genommen.

[ghostgambler]

TinyURL verwendet wohl [a-z0-9] zur Generierung der Codes, das leistet weder md5 noch sha1 noch uniquid, das wird ein eigener Algorithmus sein.

Alle anderen vorgeschlagene Varianten sind hier mehr oder minder gleichwertig. Die Datenbank freut sich natürlich eher über integer-Werte~

[frankburian]

genau!

die werden einfach mit z.B. so einer simplen Funktion

        function getrandvalue($length)
        {
            $result = '';
            srand((double)microtime()*1000000);
            for ($i=0; $i<$length; $i++)
            {
                $range = rand(48,120);
                while (($range >= 58 && $range <= 64) || ($range >= 91 && $range <= 96)) $range = rand(48,120);
                $result.= chr($range);
            }
            return $result;
        } 

erstellen und dann in der db auf vorhandenheit prüfen, und ggf. mit der URL reinschreiben!

[prego]

Ich würde es versuchen so zu bauen, das du die DB vorhandenheit nicht mehr prüfen musst. Sprich, einen Wert erstellen der auf jeden Fall eindeutig ist...

Queries sparen

Weil, wenn du einen Wert generierst, danach in der DB fragst ob der schon vorhanden ist. Was machst du dann? Erneut DB-Fragen? Und was wenn der auch vorhanden ist?

Deswegen: Von Anfang an einen Wert definieren der nicht doppelt sein kann.

//edit:
Folgende Idee: dechex(rand() + microtime());

lol - da kommt ja fast wieder auf uniqid() raus
"Hierdurch wird eine 32-Zeichen-ID (128 Bit-Hex-Wert) erzeugt, die nur sehr schwer vorhersehbar ist."

[Truncate]

Original geschrieben von prego
[B]Ich würde es versuchen so zu bauen, das du die DB vorhandenheit nicht mehr prüfen musst. Sprich, einen Wert erstellen der auf jeden Fall eindeutig ist...

Queries sparen

TinyURL prüft aber auch erst immer in der DB ob eine URL schon vorhanden ist - wie sonst würden dann bei einer URL immer der gleiche Hash rauskommen?

[ghostgambler]

Man kann auch einfach eine bigint-Spalte in mysql erstellen und da dann das Ergebnis eines microtime(true)-Aufrufes rein schreiben.
Da gehen einem die Möglichkeiten auch nicht sonderlich schnell aus. Ist natürlich mehr Platzverbrauch (bigint ist größer, demnach langsamer, als int)~

[frankburian]

naja, aber mal ehrlich gesagt, querys sparen muss man bei so einem projekt nicht! Sei denn der Webserver ist ein 386er

[ghostgambler]

Original geschrieben von frankburian
naja, aber mal ehrlich gesagt, querys sparen muss man bei so einem projekt nicht! Sei denn der Webserver ist ein 386er

Naja, aber mal ehrlich, ein fullscan auf eine Tabelle bei jedem Seitenaufruf zwingt auch einen Intel Xeon irgendwann in die Knie.