PHP - radikale Komprimierung

B

Benutzer-621

abgemeldet
20 April 2006
744
64
Moin,
Ist es irgendwie möglich Daten, in erster Linie URLs, so zu komprimieren, dass z.B. aus 300 Zeichen nur noch 30 Zeichen werden? Sollte es, welche Möglichkeiten gibt es da?


MfG
 
Es sind deine eigenen URLs? Denn dann nimmt man mod_rewrite.
Oder sind es Fremdadressen? Was bringt das dann wenn ich fragen darf? :mrgreen:
 
Ich hab grade mit WinRAR rumprobiert und da hab ich maximal 40% sparen können.

Wie sollen denn die Infos gespeichert werden ? Überleg mal: Für URLs brauchst du - wenn du extreme Einschränkungen machst - [a-z0-9./?=%&-] sind 43 Zeichen, macht ca. 5,4bit.
5,4 bit * 300 Zeichen ~ 1628 bit ~ 203 Bytes

Je nachdem, wie oft sich was wiederholt (z.B. https://), könnte man dann noch weiter einsparen (s. mein Beispiel mit WinRAR). Aber dass du 90% Komprimierung schaffst, halte ich persönlich für unmöglich.
 
Achsoo, jetzt verstehe ich wie das gemeint ist.

Erzähl trotzdem wo es eingesetzt werden soll, also ob z.B. PHP das wieder einliest, denn da kann man selbst einige Komprimierungen bauen. Prominentestes Beispiel wären https:// und www
 
Im Grunde genommen läuft es ja daraufhin hinaus, bei interner Speicherung die Datenbank vor unerwünschten Einträgen zu schützen, da ich u.a. recht ungerne mit Captchas u.ä. arbeite. Dazu käme dann das Problem, die Datensätze müssten "ewig" gespeichert werden um dann überhaupt vollständige Funktionalität zu haben. Zuletzt ist eben die Wahrscheinlichkeit der Manipulation der Daten viel höher. Vorstellen könnte man sich das indirekt so, man sucht das Netz nach seinen eigenen Schlüsseln/Prüfsummen ab, müsste aber jeden Schlüssel vorher in der Datenbank eingetragen haben, was wiederum bei direkter Schlüsselerkennung nicht der Fall wäre. Bsp:

PHP: 
$KlammID = 'https://www.domain.tld/?key=3ca33452d0ba398506359975e18b2014a884f2c8'; // SHA1-Wert von 'klamm'
$KlammID = 'https://www.domain.tld/?key=a2xhbW0='; // Base64-Wert von 'klamm'

bei der oberen Variante müsste jetzt der Schlüssel mit dem vollständigen Datensatz ausgelesen werden, was hingegen bei der Unteren nicht getan werden muss.
 
für eine einfache prüfsumme genügt natürlich md5 oder sha1.

allerdings ist sha1 ein hash und base64 ein codierung. beides sind keine komprimierungs- oder verschlüsselsungsverfahren.
 
Scar schrieb:
für eine einfache prüfsumme genügt natürlich md5 oder sha1.

allerdings ist sha1 ein hash und base64 ein codierung. beides sind keine komprimierungs- oder verschlüsselsungsverfahren.
Zum Vergrößern anklicken....

Hab ja auch nichts anderes behauptet, bei Variante Base64 kann man alle Daten direkt auslesen, wobei bei Variante SHA1/MD5 erstmal mit DB Datensätze gecheckt werden. Eigentlich soll es ja so sein, dass jeder eingegebene Wert als solcher richtig ist, weil ich sonst eigentlich bei SHA1 40^16 Datensätze haben müsste um unkorrekte Werte als richtig erscheinen zu lassen. Sagen wir mal ich schreibe ne Nachricht. Nachricht ist im Plaintext zu lang, dann evtl. mal mit gzdeflate und base64 laufen lassen, ist immernoch zu lang. Dann bleibt übrig es zu speichern nun gelange ich mit Schlüssel e1744a525099d9a53c0460ef9cb7ab0e4c4fc939 an die Nachricht, und dies ist dann eben der einzige und gültige Schlüssel in der Datenbank. Würde ich aber z.B. einen komprimiert-kodierten String nehmen könnte ich ihn direkt auslesen. Ist schon bissl schwer zu erklären :ugly:, hoffe man hats so wenigsten ein wenig verstanden :).
 
tester schrieb:
Hab ja auch nichts anderes behauptet, bei Variante Base64 kann man alle Daten direkt auslesen, wobei bei Variante SHA1/MD5 erstmal mit DB Datensätze gecheckt werden. Eigentlich soll es ja so sein, dass jeder eingegebene Wert als solcher richtig ist, weil ich sonst eigentlich bei SHA1 40^16 Datensätze haben müsste um unkorrekte Werte als richtig erscheinen zu lassen. Sagen wir mal ich schreibe ne Nachricht. Nachricht ist im Plaintext zu lang, dann evtl. mal mit gzdeflate und base64 laufen lassen, ist immernoch zu lang. Dann bleibt übrig es zu speichern nun gelange ich mit Schlüssel e1744a525099d9a53c0460ef9cb7ab0e4c4fc939 an die Nachricht, und dies ist dann eben der einzige und gültige Schlüssel in der Datenbank. Würde ich aber z.B. einen komprimiert-kodierten String nehmen könnte ich ihn direkt auslesen. Ist schon bissl schwer zu erklären :ugly:, hoffe man hats so wenigsten ein wenig verstanden :).
Zum Vergrößern anklicken....

:ugly: entweder speicherst du ein schlüssel der die eigentlichen Daten in eine Datenbank zuordnet, oder du packst die Daten in die Url. Jedoch wirst du die Daten niemals sinnvoll schrumpfen können... selbst wenn du sie komprimierst hollst du vielleicht 30% raus, aber die 30% gehen mindestens wieder drauf für base64 oder derartiges.
 
ZeroCCC schrieb:
:ugly: entweder speicherst du ein schlüssel der die eigentlichen Daten in eine Datenbank zuordnet, oder du packst die Daten in die Url. Jedoch wirst du die Daten niemals sinnvoll schrumpfen können... selbst wenn du sie komprimierst hollst du vielleicht 30% raus, aber die 30% gehen mindestens wieder drauf für base64 oder derartiges.
Zum Vergrößern anklicken....

Mhhh muss man dann eben einsehen das es net geht. Habe mir nun überlegt den Datensatz mit einem maximalen Gültigkeitszeitpunkt zu versehen umso die Anzahl der Datensätze so gering wie möglich zu halten, noch dazu den Status des Schlüssels ob dieser verarbeitet wurde oder nicht. Aber nun taucht aber ein kleineres Problemchen von +- einer Stunde auf, der Sommer/Winterzeit, wie sollte man es am elegeantesten lösen können, hab ich mir schon öfters überlegt gehabt, vorallem bei Reloadsperren?!
 
tester schrieb:
Mhhh muss man dann eben einsehen das es net geht. Habe mir nun überlegt den Datensatz mit einem maximalen Gültigkeitszeitpunkt zu versehen umso die Anzahl der Datensätze so gering wie möglich zu halten, noch dazu den Status des Schlüssels ob dieser verarbeitet wurde oder nicht. Aber nun taucht aber ein kleineres Problemchen von +- einer Stunde auf, der Sommer/Winterzeit, wie sollte man es am elegeantesten lösen können, hab ich mir schon öfters überlegt gehabt, vorallem bei Reloadsperren?!
Zum Vergrößern anklicken....

Wieso willst du die Datensätze so gering wie möglich halten? Wenn du eine Datenbank wie MySql verwendest dann kommst du nicht mal annähernd an die grenzen von der Datenbank. Ausser jeder Mensch auf der Erde braucht plötzlich 1000 kurze Urls. Ausserdem ist eine zeitliche begenzung absolut unschön... das Internet ist nen großes Archiv. Wenn ich jetzt nen Link poste dann ist der vielleicht noch in 10 Jahren richtig, wieso sollt ich denn mit so einen Dienst wie du vorhast die haltbarkeit künstlich begrenzen?!
 
ZeroCCC schrieb:
Wieso willst du die Datensätze so gering wie möglich halten? Wenn du eine Datenbank wie MySql verwendest dann kommst du nicht mal annähernd an die grenzen von der Datenbank. Ausser jeder Mensch auf der Erde braucht plötzlich 1000 kurze Urls. Ausserdem ist eine zeitliche begenzung absolut unschön... das Internet ist nen großes Archiv. Wenn ich jetzt nen Link poste dann ist der vielleicht noch in 10 Jahren richtig, wieso sollt ich denn mit so einen Dienst wie du vorhast die haltbarkeit künstlich begrenzen?!
Zum Vergrößern anklicken....

Es geht ja nicht um die URLs/Redirects sondern einfach um die Daten, die eigentlich nur solange bis ein bestimmtes Ereignis eintritt gespeichert werden sollten. Da es ja so gut wie sicher ist das nicht alle die Voraussetzungen zum Ereignis schaffen, z.B. Einträge über Bots sollten se schon gelöscht werden :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben