Paritätsverfahren herausfinden

Frank J. (Gast)

>wird. Einzig folgende 4 Beispiele sind gegeben

>00110001  01001111  01001111  01001111
>00110011  01001110  01000110  01010110
>00111000  01011111  01000110  01000101
>00110111  01010100  01011111  01010010

>00111101  00111010  01100000  00111110

>Aus dieser Tabelle kann ich aber leider kein gängiges Verfahren
>erkennen. Es handelt sich weder um eine XOR-Verknüpfung noch um eine
>Längsparitätsprüfung.

Naja, wenn da keine Tipfehler drin sind, ist es meistens gerade Parität, 
d.h. es gibt eine gerade Anzahl 1er Bits in jeder Spalte. Klappt aber 
nicht in der 3. und 4. Spalte.
Vielleicht eine "Geheimkodierung", welche die 3. und 4. Spalte mit 
ungerader Parität betreibt? Dann klappt es mit allen Spalten!
Sprich, erst normale Parität bilden und dann mit 00110000 nochmal 
XOR-verknüpfen.
Ist informationstechnisch zwar Nonsense, hat aber möglicherweise einen 
persönlichen Touch?

Falk B. schrieb:
> Vielleicht eine "Geheimkodierung", welche die 3. und 4. Spalte mit
> ungerader Parität betreibt? Dann klappt es mit allen Spalten!

Die Parität der Spalte 2 im 3. Datensatz ist aber ebenfalls ungerade.

@Frank:

Hast du noch ein paar mehr Beispiele?

Frank J. schrieb:
> Aber das Rätsel ist mittlerweile gelöst. Die Bytes sind ASCII Zeichen.
> Um das Paritätsbyte zu errechen zieht man von jedem Byte 48 (also '0')
> ab, verknüpft alles mit XOR und addiert 48 wieder auf.

Mist, und ich war so kurz davor ... :)

Einer meiner ersten Gedanken war, dass die Prüfsumme irgendwie so
umgerechnet wird, dass (passend zum Rest) ein druckbares Zeichen
herauskommt. Erst probierte ich die Subtraktion von 32, XOR-Verknüpfung
der 4 Bytes und anschließende Addition von 32. 32 deswegen, weil das der
niedrigste ASCII-Code eines druckbaren Zeichens ist. Das passte aber
nicht. Als ich die zweite 32 auf 48 erhöht habe, stimmten immerhin schon
3 der 4 Prüfsummen. Irgendwie habe ich es verpennt, die erste 32 auch
noch auf 48 zu erhöhen, was ja nur logisch gewesen wäre :-/