Datenspeicherung ähnlich Base64 mit Fehlerkorrektur

[Frank K. (goom)]

Hallo allerseits :-)

Ich versuche gerade hinter die Logik eines interessanten Formates zu 
kommen, mache aber nur bedingte Fortschritte, vielleicht hat sich aber 
schon mal jemand damit befasst und kann mir ein paar Tips in die 
richtige Richtng geben.
Es geht um die Protokolldaten eines Programmes, diese können als 
Textdatei im CSV-Format exportiert werden, was ich auch bisher nutze um 
sie in eine Datenbank einzupflegen.
Diese Protokolldaten werden aber auch fein säuberlich in einer lokalen 
Datei abgelegt.
Jetzt reizt es mich diese Datei auszulesen und damit den Datenimport zu 
automatisieren.
Leider ist es kein Klartext, sondern jedes Ascii-Zeichen des Protokolls 
ist in einem Word(16Bit) gespeichert.
Somit verdoppelt sich die Dateigröße exakt, unter dieser Maßgabe kann 
man auch die Datensätze gut erkennen.
Da zu jedem Protokoll eine Protokollnummer gehört und diese im Programm 
frei editierbar ist, kann man leere Protokolle mit dieser Nummer als 
einzige Ascii-Ziffernfolge erzeugen und folgendes beobachten:

Ascii-Ziffernfolge | abgelegte Daten

00000 | CD81 CDB2 CEA3 CF94 D085

00001 | CD81 CDB2 CEA3 CF94 D09A

00002 | CD81 CDB2 CEA3 CF94 D0AF

Die ersten vier Ziffern sind alle "0" und erzeugen auch immer in diesem 
Zusammenhang die gleichen vier Doppelbytes --> CD81 CDB2 CEA3 CF94
Nur die Letze Ziffer ist aufsteigend 0,1,2 --> D085,D09A,D0AF...

Wenn ich jetzt neue Protokolle erzeuge mit einstelligen 
Protokollnummern,
dann sieht das ganze so aus:

Ascii-Ziffernfolge | abgelegte Daten

0 | CD81

1 | CD92

2 | CDA3

3 | CDB4

5 | CE85

6 | CE96

Wie komme ich nun auf Base64?
Ganz einfach, das niederwertige Byte vom Word bewegt sich exakt zwischen 
0x80 und 0xBF, das sind genau 64 Zeichen, nur halt mit einem Offset zum 
regulären Index von Base64.
Der höherwertige Teil vom Word beinhaltet offenbar Überträge aus einem 
Fehlerkorrekturverfahren oder anders verknüpfte Werte, welche nach der 
Base64-Codierung aufgerechnet wurden und eine Abhängigkeit zum 
"Vorgänger" haben.
Genau hier liegt der Hase im Pfeffer, ich tüftle schon paar Abende dran, 
aber der Aha-Effekt blieb bisher aus.
Im Anhang hab ich mal die Zeichenanalyse angehangen, auffalend ist eben 
der erste Block wlecher die Zeichen 0x80 bis 0xBF darstellt und der 
zweite Block quasi als Steuerzeichen (höherwertige Teil des Word) gerade 
mal von 0xCC bis 0xE7...

Fragen:
-Warum nimmt man eine Datenverdopplung in Kauf, meines erachtens nur für 
ein sicheres Fehlerkorrekturverfahren?
-Könnte es evtl. auch ein Speicherformat mit irgendwelchen 
eingearbeiteten Index sein?

Vielen Dank fürs lesen :)

[Irgend W. (Firma: egal) (irgendwer)]

Frank K. schrieb:
> Fragen:
> -Warum nimmt man eine Datenverdopplung in Kauf, meines erachtens nur für
> ein sicheres Fehlerkorrekturverfahren?
> -Könnte es evtl. auch ein Speicherformat mit irgendwelchen
> eingearbeiteten Index sein?

Glaube ich beides nicht. Das dürfe ein ganz normales 16Bit "Wide-Char" 
sein. Das ist heutzutage eigentlich ganz normal um die ganzen 
Sonderzeichen in den verschiedenen Sprachen abzubilden.

- https://en.cppreference.com/w/cpp/keyword/wchar_t.html

[Frank D. (Firma: LAPD) (frank_s634)]

춁춲캣쾔킅 ....

[Frank K. (goom)]

hey, erstmal vielen Dank für deine Antwort :)
Wenn es ein normales Wide-Char wäre, dann dürfte sich aber eine Änderung 
eines Zeichens nicht auf den Rest der Bitfolge auswirken?
Sobald ich ein Zeichen ändere, werden auch die darauf folgenden Bytes 
"neu berechnet"...

[Frank K. (goom)]

Schick, was will er mir damit sagen? :)

[Frank K. (goom)]

Frank D. schrieb:
> 춁춲캣쾔킅 ....

Schick, was will er mir damit sagen? :)

[Dieter S. (ds1)]

Lade halt mal eine Beispieldatei hier hoch und verrate vielleicht auch 
welches Programm diese erzeugt.