Laden...

Datum möglichst kompakt als String darstellen

Erstellt von baer999 vor 10 Jahren Letzter Beitrag vor 10 Jahren 1.451 Views
B
baer999 Themenstarter:in
375 Beiträge seit 2007
vor 10 Jahren
Datum möglichst kompakt als String darstellen

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!

4.221 Beiträge seit 2005
vor 10 Jahren

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

1.815 Beiträge seit 2005
vor 10 Jahren

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 🙁

125 Beiträge seit 2008
vor 10 Jahren

einfach in hex evtl.?

31122014
1f c e

R
212 Beiträge seit 2012
vor 10 Jahren

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

1.361 Beiträge seit 2007
vor 10 Jahren

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

R
212 Beiträge seit 2012
vor 10 Jahren

@Zoomi

Mit einem Datum dem Jahre 1970 würde das gnze nicht funktionieren.
Aber wenn soetwas nicht vorkommt is gut.

16.806 Beiträge seit 2008
vor 10 Jahren

Je nach Übertragungstechnik lohnt sich MTOM sehr bei der Kompression.
Das Risiko Daten im Rohzustand zu sehr zu komprimieren würde ich nicht eingehen.