Hallo,
ich stehe vor einem Problem - und zwar möchte ich ein 8 Zeichen Langes Datum in möglichst wenigen Zeichen darstellen können, um wenig Daten übertragen zu müssen (nein ich will kein DateTime Format, sondern übertrage rein auf String Ebene).
Heißt:
31.12.2014 => "31122014" [8-stellig]
soll jetzt wenn möglich per 3 oder 4 Zeichen repräsentiert, übertragen und wieder dechiffriert werden können.
Hat jemand da eine Idee, wie ich das (durch Hinzunahme von Buchstaben) kompakt packen und entpacken kann?
Danke!
Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...
Hallo,
nimm noch Gross- und Kleinbuchstaben mit dazu sowie Binde- und Unterstrich, dann hast du pro Zeichen 64 mögliche Werte (=6 bit). Dann kodierst du das Datum binär und schlüsselst alle 6 bit auf den Zeichenvorrat um.
Nobody is perfect. I'm sad, i'm not nobody 🙁
Ein bisschen kürzer bekommst du das Datum wenn du:
mit
DateTime.Now.Ticks / TimeSpan.TicksPerDay;
rechnest und beim ziel wider mit TimeSpan.TicksPerDay multiplizierst.
Wenn das Datum am ende angelangt ist 31.12.9999 hast du höchstens 8 ziffern.
Das Ganze kannst du noch komprimieren indem du ein anderes zahlenformat nimmst.
z.B Hexadezimal wie "gnc" sagte
Hi baer,
Tipp 1:
Verwende eine Kompression auf dem gesamten Datenkanal. Dein Protokoll selbst sollte verständlich, klar, möglichst wenig kryptisch sein.
Wenn du sooo viele Daten transferierst, dass du dir um Datums-Kompression sorgen machst, dann ist es eh viel effektiver, wenn du die Gesamtheit komprimierst. So wird auch gleich die Redundanz zwischen den einzelnen Datums-Angaben ausgenutzt.
Ich vermute einfach mal, dass deine Datumsangaben nicht absolut zufällig sind, sondern eher geringerer Entropie sind. Und dann holst du noch viel mehr raus und behälst ein schönes Protokoll.
Einige Protokolle unterstützen ja von sich aus Kompression (SSH, HTTP, ...) oder du nutzt eben einen GZip/DeflateStream.
Alternativer Tipp:
Tage seit 01.01.1970 als UInt16 (a la Unix Timestamp-Sekunden) per base64.
Ergibt 133% * 2bytes = 3 Bytes zur Übertragung.
beste Grüße
zommi
@Zoomi
Mit einem Datum dem Jahre 1970 würde das gnze nicht funktionieren.
Aber wenn soetwas nicht vorkommt is gut.
Je nach Übertragungstechnik lohnt sich MTOM sehr bei der Kompression.
Das Risiko Daten im Rohzustand zu sehr zu komprimieren würde ich nicht eingehen.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code